● SaaS Product Roadmap · v1.0

RetailOS — Know Every Product. Know Every Customer.

শুধু একটা POS নয় — এটি একটি সম্পূর্ণ Retail Operating System। এই ডকুমেন্টে পুরো প্রজেক্টের build order, ৭৮টি পেজের ইনভেন্টরি, টেক স্ট্যাক এবং প্রথম sprint-এর deliverable একসাথে সাজানো আছে, যাতে ধাপে ধাপে production-quality আকারে তৈরি করা যায়।

78
Total HTML Pages
06
Build Phases
13
Core Modules
04
SaaS Plans
// vision
সফলতার ৩টি স্তম্ভ

RetailOS-কে সাধারণ POS সফটওয়্যার থেকে আলাদা করে তুলবে এই তিনটি বিষয় — প্রতিটি design ও দেcision এই তিনটির উপর ভিত্তি করে নেওয়া উচিত।

01 / SPEED

দ্রুত POS

বিক্রি সম্পূর্ণ করতে ৫–১০ সেকেন্ডের বেশি না লাগে — barcode scan থেকে invoice print পর্যন্ত পুরো flow অপ্টিমাইজড হতে হবে।

02 / INTELLIGENCE

Smart CRM

কাস্টমার কী কিনছে, কখন আবার লাগবে — Smart Consumption Engine স্বয়ংক্রিয়ভাবে হিসাব করে reminder পাঠাবে (Call / WhatsApp / Delivery)।

03 / SCALE

Multi-tenant SaaS

হাজার হাজার দোকান একই কোডবেস ব্যবহার করবে, কিন্তু প্রত্যেকের ডেটা সম্পূর্ণ isolated ও secure থাকবে।

// build order
৬টি ধাপে সম্পূর্ণ রোডম্যাপ

প্রতিটি ধাপ আগেরটির উপর নির্ভরশীল — আগে architecture ও business rules ঠিক হলে, তারপর UI Kit শক্ত হলে বাকি সব module সহজে বসে যাবে। নিচের প্রতিটি ধাপের পাশে যে সপ্তাহ-সংখ্যা দেওয়া আছে, সেটা মূলত UI prototype / বেসিক flow বসানোর ধারণাগত সময় — পুরো production-ready SaaS বানাতে এর চেয়ে অনেক বেশি সময় লাগবে, যেটা নিচের বাস্তবসম্মত টেবিলে ভাঙা হলো।

⏱️ বাস্তবসম্মত সময়সীমা — ১১ সপ্তাহের হিসাবটা শুধু prototype-এর জন্য, পুরো প্রোডাক্টের জন্য না
TargetEstimated time
UI prototype8–12 weeks
Functional MVP4–6 months
Production SaaS8–12 months

নিচের ৬টি ধাপ ও সপ্তাহ-সংখ্যা মূলত UI prototype ধাপের ব্রেকডাউন — প্রতিটি ফিচার পুরোপুরি কাজ করা, টেস্ট করা, বাগ-ফ্রি ও প্রোডাকশনে ডিপ্লয় করার মতো অবস্থায় আনতে সময় স্বাভাবিকভাবেই আরও বাড়বে।

00
Product & System Architecture
সপ্তাহ ১ · Draft — sign-off pending
কোনো কোড লেখার আগে পুরো সিস্টেমের ভিত্তি কাগজে-কলমে চূড়ান্ত করা — যাতে পরের প্রতিটি ধাপে বারবার ফিরে গিয়ে ডিজাইন বদলাতে না হয়। User Roles, Permission Matrix, Tenant Model, ERD, POS Flow, Inventory Rules, Invoice Numbering, Subscription Rules, API Conventions ও Error-handling Standards — সবগুলোর প্রথম ড্রাফট লেখা হয়ে গেছে, চূড়ান্ত sign-off বাকি।
User RolesPermission MatrixTenant Model Database ERDPOS Transaction FlowInventory Rules Invoice NumberingSubscription RulesAPI Conventions Error-handling Standards
Deliverable Approved database schema + business rules + architecture document
01
Complete UI Kit
সপ্তাহ ২–৩ · Draft — sign-off pending
Foundation layer — এখানেই theme, spacing, component-এর মান ঠিক হবে যা বাকি ৭৮টা পেজে reuse হবে।
LoginRegisterForgot / Reset Password Verify OTPLock ScreenDashboard Shell SidebarHeaderFooter Light / Dark ThemeResponsive Grid
02
Shop Owner Panel
সপ্তাহ ৪–৬ · Draft — sign-off pending
মূল ব্যবসায়িক ইঞ্জিন — Inventory, Sales(POS), Purchase, Expense, Reports। এই ধাপ শেষ হলে সফটওয়্যার একটি দোকানে দৈনন্দিন ব্যবহারের জন্য প্রস্তুত হবে।
Dashboard (KPIs, Business Health Score)Product / Category / Brand / Unit Barcode & Batch / ExpiryPOS (Sale, Split Payment, Return) Purchase & Supplier LedgerExpensesReports
03
CRM — পণ্যের বাইরে গিয়ে সম্পর্ক তৈরি
সপ্তাহ ৭–৮ · Draft — sign-off pending
RetailOS-কে সাধারণ POS থেকে আলাদা করে এই মডিউল — Smart Consumption Engine ও Lead Flow (New → Contacted → Interested → Confirmed → Delivered → Repeat Customer)।
Lead ManagementFollow-up CalendarNotifications Engine Customer Purchase HistorySmart Consumption PredictionLoyalty Program
04
Online Shop
সপ্তাহ ৯–১০ · Draft — sign-off pending
প্রতিটি দোকানের নিজস্ব storefront — নতুন কাস্টমারের অর্ডার এলে Lead তৈরি হবে, পুরনো কাস্টমারের অর্ডার সরাসরি Order-এ যোগ হবে।
Store HomeProductsCartCheckout OrdersDelivery Tracking
05
Super Admin (SaaS Layer)
সপ্তাহ ১১–১২ · Draft — sign-off pending
পুরো SaaS ব্যবস্থাপনা — Shop approval, Subscription billing, Analytics ও Global settings। এই ধাপ শেষ হলে RetailOS প্রকৃত multi-tenant প্রোডাক্টে পরিণত হবে।
Shop ManagementSubscription PlansPayments Support TicketsSystem SettingsGlobal Analytics
// inventory
৭৮টি পেজের সম্পূর্ণ ইনভেন্টরি

প্রতিটি module কার্ডে ক্লিক করলে সেই module-এর সব পেজের তালিকা দেখা যাবে।

Inventory
12
Customers & CRM
12
Sales
10
Purchase
7
Authentication
6
Expenses & Accounts
6
Reports
6
Online Shop
6
SaaS Admin
5
Dashboard
4
Employees
4
Authentication6
  1. Login
  2. Register
  3. Forgot Password
  4. Reset Password
  5. Verify OTP
  6. Lock Screen
Dashboard4
  1. Dashboard Overview
  2. Sales Dashboard
  3. CRM Dashboard
  4. Analytics Dashboard
Inventory12
  1. Products
  2. Add Product
  3. Edit Product
  4. Categories
  5. Brands
  6. Units
  7. Stock List
  8. Low Stock
  9. Expired Products
  10. Stock Adjustment
  11. Barcode Print
  12. Product Details
Sales10
  1. POS
  2. Sales List
  3. New Sale
  4. Invoice
  5. Returns
  6. Discounts
  7. Draft Orders
  8. Quotations
  9. Delivery Orders
  10. Payment History
Purchase7
  1. Purchase List
  2. New Purchase
  3. Suppliers
  4. Supplier Ledger
  5. Purchase Return
  6. Supplier Payments
  7. Purchase Reports
Customers & CRM12
  1. Customer List
  2. Customer Profile
  3. Customer Ledger
  4. Customer Due
  5. Leads
  6. Lead Details
  7. Follow-up Calendar
  8. Call History
  9. WhatsApp Campaign
  10. Customer Segments
  11. Loyalty Program
  12. Smart Consumption Prediction
Expenses & Accounts6
  1. Expenses
  2. Expense Categories
  3. Cash Book
  4. Bank Accounts
  5. Profit & Loss
  6. Balance Sheet
Reports6
  1. Daily Report
  2. Weekly Report
  3. Monthly Report
  4. Sales Report
  5. Purchase Report
  6. Inventory Report
Online Shop6
  1. Store Settings
  2. Store Home
  3. Products
  4. Cart
  5. Checkout
  6. Orders
Employees4
  1. Employees
  2. Roles
  3. Attendance
  4. Payroll
SaaS Admin5
  1. Shop Management
  2. Subscription Plans
  3. Payments
  4. Support Tickets
  5. System Settings
// specification
গুরুত্বপূর্ণ ফিচারের Spec

প্রতিটি core feature-এর জন্য User, Actions, Business Rules, Permissions ও Acceptance Criteria — যাতে Laravel port করার সময় প্রতিটি behavior স্পষ্টভাবে define করা থাকে এবং কোনো edge-case বাদ না যায়।

FeatureProduct Management
Shop OwnerManager
Actions
  • Product add
  • Product edit
  • Product deactivate
  • Barcode generate
Business Rules
  • SKU একই tenant-এর মধ্যে unique
  • Selling price শূন্য হতে পারবে না
  • Product delete করা যাবে না যদি sale history থাকে
  • Inactive product POS-এ দেখা যাবে না
Permissions
Ownerসব permission
ManagerAdd / Edit
CashierView only
Acceptance Criteria
  • Product save হলে product list-এ দেখা যাবে
  • Duplicate SKU হলে error দেখাবে
  • অন্য দোকানের product দেখা যাবে না
FeaturePOS — Sale
Shop OwnerManagerCashier
Actions
  • Barcode scan / product search
  • Cart-এ product add / remove
  • Discount apply
  • Split payment (Cash / Card / UPI / Due)
  • Invoice print / SMS পাঠানো
  • Sale return
Business Rules
  • Available stock-এর বেশি quantity sale করা যাবে না
  • Sale complete হলে stock স্বয়ংক্রিয়ভাবে কমবে
  • Due sale-এর জন্য customer profile আবশ্যক
  • Return শুধুমাত্র original invoice-এর বিপরীতে করা যাবে
Permissions
Ownerসব permission
ManagerSale, Return, Discount (limit পর্যন্ত)
Cashierশুধু Sale (discount limit ছাড়া)
Acceptance Criteria
  • Sale complete হলে stock ও ledger আপডেট হবে
  • Insufficient stock হলে sale block হবে
  • Invoice-এ সঠিক tenant branding দেখাবে
FeaturePurchase Management
Shop OwnerManager
Actions
  • New purchase entry
  • Supplier select / add
  • Purchase return
  • Supplier payment record
Business Rules
  • Purchase confirm হলে stock বাড়বে
  • Supplier ledger স্বয়ংক্রিয়ভাবে আপডেট হবে
  • Purchase return হলে stock কমবে এবং supplier due adjust হবে
Permissions
Ownerসব permission
ManagerAdd / Edit purchase
Cashierকোনো access নেই
Acceptance Criteria
  • Purchase save হলে stock ও ledger sync হবে
  • Supplier ledger balance সঠিকভাবে দেখাবে
  • অন্য tenant-এর supplier দেখা যাবে না
FeatureCustomer Management (CRM)
Shop OwnerManagerCashier
Actions
  • Customer add / edit
  • Customer ledger দেখা
  • Due collection entry
  • Customer segment assign
Business Rules
  • একই tenant-এর মধ্যে একই phone number দিয়ে duplicate customer তৈরি করা যাবে না
  • Due amount নেগেটিভ হতে পারবে না
  • Transaction history থাকলে customer delete করা যাবে না
Permissions
Ownerসব permission
ManagerAdd / Edit / View
CashierView only + Due collection entry
Acceptance Criteria
  • Duplicate phone number হলে error দেখাবে
  • Due collection হলে ledger ও dashboard আপডেট হবে
  • অন্য দোকানের customer দেখা যাবে না
FeatureLead Management
Shop OwnerManager
Actions
  • Lead create (Online Shop / manual)
  • Lead status update (New → Contacted → Interested → Confirmed → Delivered)
  • Follow-up schedule
  • Lead-কে Customer-এ convert
Business Rules
  • Lead Confirmed/Delivered হলে স্বয়ংক্রিয়ভাবে Customer profile তৈরি হবে
  • Follow-up date পার হয়ে গেলে reminder trigger হবে
  • Status backward-এ পরিবর্তন করা যাবে, কিন্তু history log-এ থাকবে
Permissions
Ownerসব permission
ManagerAdd / Edit / Status update
CashierView only
Acceptance Criteria
  • Status change হলে timeline-এ log হবে
  • Confirmed lead থেকে Customer profile auto-create হবে
  • Overdue follow-up dashboard-এ highlight হবে
FeatureStock / Inventory Adjustment
Shop OwnerManager
Actions
  • Stock adjustment (reason সহ add / remove)
  • Low stock alert configure
  • Batch / Expiry entry
  • Stock transfer (multi-branch)
Business Rules
  • Adjustment-এ reason mandatory
  • Expired batch POS-এ sale করা যাবে না
  • Multi-branch transfer হলে উভয় branch-এর stock আপডেট হবে
Permissions
Ownerসব permission
ManagerAdjustment request (plan অনুযায়ী approval লাগতে পারে)
CashierView only
Acceptance Criteria
  • Adjustment save হলে stock log-এ entry হবে
  • Expired product POS search-এ block হবে
  • Low stock threshold cross হলে alert যাবে
FeatureExpense Management
Shop OwnerManager
Actions
  • Expense add / edit
  • Expense category manage
  • Cash book entry
Business Rules
  • Expense amount শূন্য বা নেগেটিভ হতে পারবে না
  • Cash book balance real-time reconcile হবে
  • Approved expense delete করা যাবে না, শুধু void করা যাবে
Permissions
Ownerসব permission
ManagerAdd / Edit (approval limit পর্যন্ত)
Cashierকোনো access নেই
Acceptance Criteria
  • Expense save হলে Cash Book ও P&L রিপোর্টে reflect হবে
  • নেগেটিভ amount দিলে error দেখাবে
  • Void হওয়া expense audit log-এ থাকবে
FeatureEmployee & Role Management
Shop Owner
Actions
  • Employee add / edit / deactivate
  • Role assign (Owner / Manager / Cashier + custom)
  • Attendance mark
  • Payroll generate
Business Rules
  • Plan-এর employee limit-এর বেশি add করা যাবে না
  • Deactivated employee login করতে পারবে না
  • Payroll generate হলে ঐ মাসের attendance lock হয়ে যাবে
Permissions
Ownerসব permission
ManagerAttendance mark only
Cashierকোনো access নেই
Acceptance Criteria
  • Employee limit exceed হলে upgrade prompt দেখাবে
  • Deactivate করলে সাথে সাথে session বাতিল হবে
  • Payroll lock হওয়ার পর attendance edit করা যাবে না
FeatureOnline Shop / Order Management
Shop OwnerManagerCustomer
Actions
  • Store settings configure
  • Product publish / unpublish
  • Order confirm / reject
  • Delivery status update
Business Rules
  • নতুন customer order দিলে Lead তৈরি হবে; পুরনো customer-এর order সরাসরি Order-এ যাবে
  • Out-of-stock product storefront-এ hide হবে
  • Order cancel হলে reserved stock ফেরত যাবে
Permissions
Ownerসব permission
ManagerOrder confirm / status update
Customerশুধু নিজের order দেখা ও place করা
Acceptance Criteria
  • Order place হলে stock reserve হবে
  • Order cancel হলে stock release হবে
  • Out-of-stock product checkout-এ block হবে
FeatureSubscription & Billing (SaaS Admin)
Super Admin
Actions
  • Shop approve / suspend
  • Plan upgrade / downgrade
  • Payment / invoice track
  • Support ticket resolve
Business Rules
  • Payment fail হলে ৭ দিনের grace period শেষে shop suspend হবে
  • Plan downgrade হলে limit-বহির্ভূত extra data (users/branch) access-only mode-এ যাবে, delete হবে না
  • Suspend হওয়া shop-এর data মুছে যাবে না, শুধু access বন্ধ হবে
Permissions
Super Adminসব permission
Shop Ownerনিজের billing history / invoice দেখা
Acceptance Criteria
  • Payment success হলে subscription auto-renew হবে
  • Grace period শেষে suspend trigger হবে
  • Downgrade-এ কোনো data loss হবে না
FeatureBarcode & Batch / Expiry
Shop OwnerManager
Actions
  • Barcode generate / print (single & bulk)
  • Batch add (purchase-এর সময়)
  • Expiry date set
  • Expired / near-expiry list দেখা
Business Rules
  • একই tenant-এ একই barcode value duplicate হতে পারবে না
  • Batch quantity, product-এর total stock-এর যোগফলের সমান হতে হবে
  • Expiry date পার হলে ঐ batch স্বয়ংক্রিয়ভাবে "Expired" status-এ যাবে
  • একই product-এর একাধিক batch থাকলে FIFO (আগে expire হওয়া batch আগে) অনুযায়ী sale হবে
Permissions
Ownerসব permission
ManagerBatch add / Barcode print
CashierBarcode print only
Acceptance Criteria
  • Duplicate barcode হলে error দেখাবে
  • Near-expiry (৭ দিনের মধ্যে) product dashboard-এ alert দেখাবে
  • Expired batch POS search/scan-এ block হবে
FeatureLoyalty Program & Smart Consumption Engine
Shop OwnerManagerCustomer
Actions
  • Loyalty point rule configure (₹ প্রতি point)
  • Point redeem করা
  • Consumption cycle prediction দেখা (কোন customer-এর কোন product কবে শেষ হবে)
  • Reminder পাঠানো (Call / WhatsApp / SMS)
Business Rules
  • শুধুমাত্র Premium ও তদূর্ধ্ব plan-এ এই feature enable থাকবে
  • Point redeem, বর্তমান balance-এর বেশি হতে পারবে না
  • Prediction, customer-এর গত ৩+ purchase cycle-এর average interval থেকে হিসাব হবে
  • Return/refund হলে সংশ্লিষ্ট point স্বয়ংক্রিয়ভাবে reverse হবে
Permissions
Ownerসব permission
ManagerRedeem / Reminder পাঠানো
Customerনিজের point balance দেখা
Acceptance Criteria
  • Sale complete হলে point স্বয়ংক্রিয়ভাবে জমা হবে
  • Prediction date কাছে এলে reminder queue-তে যাবে
  • Lower-tier plan-এ feature UI locked/hidden থাকবে
FeatureAuthentication & Access Control
সব userSuper Admin
Actions
  • Login / Logout
  • Register (Shop signup)
  • Forgot / Reset password
  • OTP verify
  • Lock screen (session pause)
Business Rules
  • একই email/phone দিয়ে একাধিক tenant-এ owner হিসেবে register করা যাবে না
  • ৫ বার ভুল password দিলে account ১৫ মিনিটের জন্য lock হবে
  • Reset password link ৩০ মিনিট পর expire হবে
  • Cashier/Manager, Owner ছাড়া নিজে থেকে self-register করতে পারবে না — Owner-ই invite করবে
Permissions
OwnerRegister, staff invite, সব login
Manager / CashierLogin only (invite-এর মাধ্যমে account তৈরি)
Super Adminযেকোনো tenant-এর login force-reset করতে পারবে
Acceptance Criteria
  • Login হলে ঐ user শুধু নিজের tenant-এর dashboard-এ যাবে
  • Lock হওয়া account নির্দিষ্ট সময়ের আগে login করতে পারবে না
  • Session inactive থাকলে auto lock-screen হবে
FeatureReports & Analytics
Shop OwnerManager
Actions
  • Daily / Weekly / Monthly report দেখা
  • Sales, Purchase, Inventory report generate
  • Report export (PDF / Excel)
  • Date-range filter apply
Business Rules
  • Plan অনুযায়ী report depth limited হবে (Basic / Advanced / All)
  • Report সবসময় logged-in tenant-এর ডেটা থেকেই generate হবে
  • Export করা file-এ shop-এর নাম ও generate timestamp থাকবে
  • Deleted/voided transaction report-এ আলাদাভাবে চিহ্নিত থাকবে, সম্পূর্ণ বাদ যাবে না
Permissions
Ownerসব report + export
ManagerView + export (financial summary ছাড়া)
Cashierকোনো access নেই
Acceptance Criteria
  • Date-range filter করলে সংশ্লিষ্ট সব card/chart আপডেট হবে
  • Export file-এর টোটাল, on-screen টোটালের সাথে মিলবে
  • Lower plan-এ locked report section-এ upgrade prompt দেখাবে
FeatureMulti-Branch Management
Shop Owner
Actions
  • Branch add / edit
  • Branch-wise staff assign
  • Branch-wise stock transfer
  • Consolidated (all-branch) report দেখা
Business Rules
  • Plan-এর branch limit-এর বেশি branch add করা যাবে না (Premium: ৩টি, Enterprise: Unlimited)
  • প্রতিটি branch-এর নিজস্ব stock ও POS থাকবে, কিন্তু একই tenant-এর মধ্যে
  • Staff, তার assigned branch ছাড়া অন্য branch-এর ডেটা দেখতে পারবে না
  • Branch deactivate করলে ঐ branch-এর staff login করতে পারবে না, তবে data থেকে যাবে
Permissions
Ownerসব branch + consolidated report
Managerশুধু assigned branch
Cashierশুধু assigned branch-এর POS
Acceptance Criteria
  • Branch limit exceed হলে upgrade prompt দেখাবে
  • Stock transfer হলে উভয় branch-এর stock log আপডেট হবে
  • Consolidated report-এ প্রতিটি branch আলাদাভাবে breakdown দেখাবে
// most critical logic
POS Transaction Rules

শুধু POS page বানালেই হবে না — sale-এর প্রতিটা state change (draft → complete → return/cancel)-এ stock ও ledger ঠিকভাবে move করতে হবে। এই নিয়মগুলো Phase 0-এর business rules doc-এ চূড়ান্ত করে, POS development শুরুর আগেই সবার জানা থাকতে হবে।

01Stock Timing

  • ›Sale draft অবস্থায় stock কমবে না
  • ›Sale complete হলে stock কমবে
  • ›Return হলে stock পুনরায় বাড়বে

02Payment

  • ›Payment confirm হলে sale complete হবে
  • ›Partial payment support থাকবে
  • ›Due amount customer ledger-এ যাবে

03Edit & Correction

  • ›Completed sale direct edit করা যাবে না
  • ›Correction-এর জন্য return / adjustment ব্যবহার হবে

04Cancellation & Audit

  • ›Sale cancel হলে reason বাধ্যতামূলক
  • ›সব cancel/return audit log-এ থাকবে

⚠️ Decision Needed Before Development

Negative stock policy — stock শূন্য বা তার নিচে নেমে গেলে sale allow করা হবে কিনা, সেটা POS coding শুরুর আগেই নির্ধারণ করতে হবে। সাধারণত তিনটি অপশন থাকে:

  • Strict — stock শেষ হলে sale সম্পূর্ণ block হবে
  • Warn & Allow — warning দেখাবে কিন্তু owner/manager override করতে পারবে
  • Allow with Flag — sale হবে, কিন্তু negative stock হিসেবে flag/log হয়ে report-এ আলাদা দেখাবে

🔒 Decision Locked — Offline POS Strategy

দোকানে internet সমস্যা হতে পারে জেনেও, scope অস্পষ্ট রাখলে customer expectation ও development effort দুটোই অনিয়ন্ত্রিতভাবে বেড়ে যায় — তাই এই সিদ্ধান্ত Phase 0-তেই লিখিতভাবে চূড়ান্ত:

MVP → Online-only POS (internet সংযোগ ছাড়া sale complete করা যাবে না) Offline POS → RetailOS v2.0-এর পরে (roadmap-এ পরবর্তী ধাপ হিসেবে চিহ্নিত, MVP scope-এ নেই)
  • MVP-তে internet না থাকলে POS screen সরাসরি "No connection" state দেখাবে ও sale block করবে — silent failure বা partial/corrupt sale data তৈরি হতে দেওয়া যাবে না।
  • Sales page/marketing material-এ "Offline POS" ফিচার হিসেবে উল্লেখ করা যাবে না যতক্ষণ না v2.0-এ এটা প্রকৃতপক্ষে বিল্ড হচ্ছে — যাতে customer expectation ভুল না হয়।
  • v2.0-এ offline support যোগ করার সিদ্ধান্ত নিলে সেটার জন্য আলাদা ADR লেখা হবে (local queue/sync conflict resolution strategy সহ), কারণ এটা POS-এর ডেটা মডেলে নতুন জটিলতা যোগ করে।
// design system
টেক স্ট্যাক & ফোল্ডার স্ট্রাকচার

AdminLTE-ধাঁচের আধুনিক Bootstrap 5 dashboard — পরে Laravel/PHP-এ সহজে যুক্ত করার জন্য প্রতিটি HTML পেজ modular partial (header/sidebar/footer) দিয়ে বানানো হবে।

Bootstrap 5
Bootstrap Icons
Chart.js
ApexCharts
DataTables
Flatpickr
SweetAlert2
Light / Dark Mode
Glassmorphism
RTL Support (optional)
বাংলা + English
RetailOS-UI/ ├── auth/ ├── dashboard/ ├── inventory/ ├── sales/ ├── purchase/ ├── crm/ ├── customers/ ├── suppliers/ ├── reports/ ├── accounts/ ├── online-store/ ├── employees/ ├── admin/ │ ├── assets/ │ ├── css/ │ ├── js/ │ ├── fonts/ │ ├── images/ │ ├── icons/ │ └── plugins/ │ ├── partials/ │ ├── header.html │ ├── sidebar.html │ ├── footer.html │ └── scripts.html │ └── index.html
// sprint 01
এখনই যা তৈরি হচ্ছে

প্রথম ধাপের ১০টি deliverable — production-quality আকারে, একটি একটি করে।

RETAILOS · BUILD RECEIPT

FIRST DELIVERY BATCH
01LoginIN QUEUE
02RegisterIN QUEUE
03DashboardIN QUEUE
04SidebarIN QUEUE
05HeaderIN QUEUE
06FooterIN QUEUE
07Product ListIN QUEUE
08POSIN QUEUE
09Customer ListIN QUEUE
10Supplier ListIN QUEUE
TOTAL ITEMS10 / 78
// saas subscription
Plan & Pricing

চারটি স্তর — প্রতিটি স্তরে এমন feature যোগ করা আছে যা পরবর্তী স্তরে upgrade করার একটা স্পষ্ট কারণ তৈরি করে।

Starter
₹499
১ দোকান · ২ ইউজার
Business
₹999
১ দোকান · ১০ ইউজার
Premium
₹1999
১ দোকান · Unlimited ইউজার
Enterprise
Custom
Unlimited দোকান
Feature Starter Business Premium Enterprise
দোকানের সংখ্যা111Unlimited
Users / Employees210UnlimitedUnlimited
POS Sales✓✓✓✓
Product Management✓✓✓✓
Inventory✓✓✓✓
Barcode—✓✓✓
Purchase Management✓✓✓✓
Supplier Management✓✓✓✓
Customer Management✓✓✓✓
Due Management✓✓✓✓
Expense Management✓✓✓✓
Profit & LossDailyDaily+MonthlyFullFull
GST Balance Sheet (Optional)—OptionalOptionalOptional
ReportsBasicAdvancedAllAll
Low Stock Alert✓✓✓✓
Online Shop—BasicFullFull
Custom Domain——✓✓
CRM—BasicAdvancedAdvanced
Lead Management—✓✓✓
Smart Reminder——✓✓
Customer Consumption Prediction——✓✓
WhatsApp Integration——✓✓
SMS Notification—Add-on✓✓
Mobile App—View OnlyFullFull
Multi Branch——3 BranchUnlimited
API Access——LimitedFull
BackupWeeklyDailyReal-timeReal-time
Priority Support—EmailWhatsAppDedicated
🟢

Starter — ₹499/mo

ছোট দোকানের জন্য
  • ১টি দোকান, ২ জন ইউজার
  • POS, Product, Inventory
  • Purchase, Sales, Supplier
  • Customer, Due, Expense
  • Daily Report
  • Low Stock Alert
🔵

Business — ₹999/mo

বর্ধনশীল দোকানের জন্য
Starter-এর সবকিছু +
  • ১০ জন Employee
  • Barcode
  • Advanced Reports
  • Lead Management
  • Basic CRM
  • Basic Online Shop
  • Supplier Analytics
  • Customer Analytics
  • Daily Backup
🟣

Premium — ₹1999/mo

সিরিয়াস ব্যবসার জন্য
Business-এর সবকিছু +
  • Unlimited Users
  • Full CRM
  • Smart Consumption Engine
  • Customer Reminder
  • WhatsApp + SMS Integration
  • Online Store + Custom Domain
  • Multi Branch (৩টি)
  • AI Reports, Mobile App
  • Advanced Analytics
  • Auto Delivery Reminder
🟡

Enterprise — Custom

চেইন / বড় গ্রুপের জন্য
Premium-এর সবকিছু +
  • Unlimited Shops & Branches
  • Unlimited Employees
  • White Label + Custom Branding
  • Dedicated Server
  • Full API Access, ERP Integration
  • Priority Support
  • Dedicated Account Manager
  • Custom Feature Development

💎 যে ফিচারগুলোর জন্য মানুষ Premium-এ আপগ্রেড করবেই

বাজারে অনেক POS আছে, কিন্তু এমন সফটওয়্যার খুব কম আছে যা দোকানদারকে আগে থেকেই বলে দেয় — কোন কাস্টমারের কোন পণ্য শেষ হতে যাচ্ছে, এবং সেখান থেকেই সরাসরি Call, WhatsApp বা Delivery শুরু করার সুযোগ দেয়। Smart CRM + Smart Consumption Engine-কে RetailOS-এর প্রধান USP (Unique Selling Point) হিসেবে তুলে ধরা উচিত।

🤖 Smart Customer Prediction
📞 One Click Call
💬 WhatsApp Reminder
🚚 Delivery Reminder
🌐 Online Shop
📈 AI Sales Forecast
📊 Business Health Score
📱 Mobile App
🔔 Smart Notifications
// does ₹499 actually make money
Unit Economics

Setup + Training fee-এর কাঠামো ভালো, কিন্তু recurring মূল্য টিকিয়ে রাখতে হলে জানতে হবে প্রতি সক্রিয় দোকানের পেছনে মাসে কত খরচ যাচ্ছে। নিচের সংখ্যাগুলো একটা illustrative cost model — লাইভ হওয়ার পর real usage data দিয়ে প্রতি quarter-এ আপডেট করতে হবে।

খরচের খাত (প্রতি active shop / মাস)আনুমানিক
Server & Hosting (shared infra, amortized)₹35
Database (managed, indexing overhead)₹20
Backup (daily + 6-hourly, object storage)₹10
SMS / WhatsApp (গড় ব্যবহার অনুযায়ী)₹45
Support (agent time, amortized)₹70
Payment Gateway Fee (~2% billing amount)₹15
GST / Compliance (accounting, filing tools)₹15
= Cost per Active Shop / মাস₹210
// margin check by plan
₹210 খরচের বিপরীতে কোন প্ল্যান 70%+ margin টার্গেট মেটায়
Plan ARPU / মাস Cost / মাস Gross Margin 70%+ Target
Starter₹499₹210~58%❌ Miss
Business₹999₹210~79%✅ Meets
Premium₹1,999₹210~89%✅ Meets
EnterpriseCustomCustom-scopedNegotiatedCase-by-case
CAC · Acquisition Cost
₹1,200–1,800

মার্কেটিং, সেলস effort ও onboarding সময় মিলিয়ে প্রতি নতুন shop-এ আনুমানিক খরচ — one-time Setup Fee (₹1,999–4,999) দিয়ে অনেকটাই cover হয়ে যায়।

Payback Period
২–৩ মাস

Setup Fee প্রথম মাসেই বেশিরভাগ CAC রিকভার করে; বাকিটা Business/Premium প্ল্যানের মাসিক margin দিয়ে ২–৩ মাসের মধ্যে পুরোপুরি পুষিয়ে যায়।

LTV (Business plan, ~5% মাসিক churn)
~₹15,800

গড় গ্রাহক-আয়ু ~২০ মাস ধরে হিসাব — ₹789 মাসিক margin × ২০ মাস। Starter-only গ্রাহকের LTV উল্লেখযোগ্যভাবে কম, তাই upgrade path জরুরি।

LTV : CAC Ratio
~9 : 1

সাধারণ SaaS benchmark ৩:১ বা তার বেশি হলে স্বাস্থ্যকর ধরা হয় — Business/Premium মিশ্রণে এই অনুপাত যথেষ্ট ভালো, কিন্তু শুধু Starter-নির্ভর হলে এই ratio অনেক নেমে যাবে।

✅ প্রায়োগিক নিয়ম

  • Starter প্ল্যান একা ৭০%+ margin টার্গেট মেটায় না (~58%) — তাই Starter মূলত acquisition/entry plan হিসেবে treat করতে হবে, প্রধান রাজস্ব-উৎস নয়। Onboarding flow-তে Business-এ upgrade করার incentive স্পষ্টভাবে দেখাতে হবে।
  • এই cost model অনুমাননির্ভর — লাইভ হওয়ার প্রথম ৩ মাসে actual server/SMS/support খরচ ট্র্যাক করে সংখ্যাগুলো recalibrate করতে হবে।
  • Support cost (₹70) সবচেয়ে বড় ও সবচেয়ে variable খাত — self-serve help doc/chatbot দিয়ে এই খরচ কমানো গেলে blended margin সরাসরি বাড়বে।
  • Plan mix (কত% Starter vs Business vs Premium) কোম্পানির overall gross margin নির্ধারণ করে — তাই sales target শুধু "কত নতুন shop" না, "কোন প্ল্যানে কত নতুন shop" ধরে সেট করা উচিত।
// extra revenue
Add-on Features

মূল সাবস্ক্রিপশনের বাইরে আলাদাভাবে বিক্রি করার মতো অতিরিক্ত আয়ের সুযোগ।

SMS Package₹199/mo
WhatsApp API₹299/mo
Extra Branch₹299/mo
Extra Employee (১০ জন)₹199/mo
Custom Domain Setup₹499 one-time
Data Migration₹999 one-time
Barcode Printer Setup₹499 one-time
Training Session₹999 one-time
// operational rules
SaaS Billing Rules

Plan & Pricing স্তরটা ঠিক আছে, কিন্তু "টাকা না দিলে কী হবে" — এই operational rules-গুলো Phase 0-তেই নির্ধারণ করে রাখতে হবে, নাহলে প্রথম failed-payment কেসেই ম্যানুয়ালি সিদ্ধান্ত নিতে হবে।

💳 Monthly vs Yearly — বার্ষিক প্ল্যানে ২ মাস ফ্রি (~১৭% ছাড়)
PlanMonthlyYearly
Starter₹499/mo₹4,990/yr
Business₹999/mo₹9,990/yr
Premium₹1,999/mo₹19,990/yr
EnterpriseCustomCustom (yearly-only discount নেগোশিয়েবল)

নিয়ম: বার্ষিক প্ল্যানের দাম সবসময় মাসিক দামের ১০ গুণ (অর্থাৎ ১২ মাসের মধ্যে ২ মাস ফ্রি) — নতুন প্ল্যান যোগ হলেও এই সূত্র অনুসরণ করা হবে।

01

Free Trial

১৪ দিন — কোনো কার্ড/পেমেন্ট তথ্য ছাড়াই Business প্ল্যানের ফিচার unlock করে দেখা যাবে। ট্রায়াল শেষে পেমেন্ট না করলে স্বয়ংক্রিয়ভাবে সবচেয়ে সীমিত (Starter) স্তরে নেমে আসবে, ডেটা মুছে যাবে না।

02

Payment Grace Period

নির্ধারিত তারিখে পেমেন্ট না হলে ৭ দিনের grace period — এই সময়ে সফটওয়্যার স্বাভাবিকভাবে কাজ করবে, শুধু একটা reminder banner দেখাবে।

03

Subscription Expiry Behaviour

Grace period শেষ হলে অ্যাকাউন্ট Read-only mode-এ যাবে — বিদ্যমান ডেটা দেখা/এক্সপোর্ট করা যাবে, কিন্তু নতুন Sale/Purchase এন্ট্রি বন্ধ থাকবে।

04

Upgrade Proration

মাসের মাঝপথে upgrade করলে বাকি দিনগুলোর জন্য pro-rata হিসেবে extra amount চার্জ হবে — পরের বিলিং সাইকেল থেকে নতুন প্ল্যানের পূর্ণ দাম কার্যকর হবে।

05

Downgrade Rules

Downgrade সবসময় চলতি বিলিং সাইকেল শেষে কার্যকর হবে (তাৎক্ষণিক না) — এবং higher plan-এর কোনো ডেটা (যেমন Extra Branch, Extra Employee) লিমিট অতিক্রম করলে আগে সেটা কমাতে হবে।

06

GST Treatment

সব সাবস্ক্রিপশন প্রাইস GST-exclusive হিসেবে দেখানো হবে; ইনভয়েসে প্রযোজ্য GST% আলাদাভাবে যোগ হবে এবং গ্রাহকের GSTIN (থাকলে) ইনভয়েসে উল্লেখ থাকবে।

07

Invoice Generation

প্রতিটা সফল পেমেন্টের পর স্বয়ংক্রিয়ভাবে একটা GST-compliant invoice তৈরি ও গ্রাহকের ইমেইলে পাঠানো হবে, এবং Dashboard থেকে ডাউনলোড/reprint করা যাবে।

// failed payment
Failed Payment Workflow

পেমেন্ট মিস হলে ঠিক কী ঘটবে, কোন দিনে কী স্টেট বদলাবে — এই timeline প্রতিটা subscription-এর জন্য অটোমেটেড থাকবে।

Payment due → 3-day reminder (email + in-app) Payment failed → 7-day grace period শুরু Grace period ends → Read-only mode 30 days unpaid → Account suspension

✅ প্রায়োগিক নিয়ম

  • Suspension মানে ডেটা মুছে ফেলা না — নির্দিষ্ট archive period (তেনান্সি সেকশনের Deletion Policy অনুযায়ী) পর্যন্ত ডেটা সংরক্ষিত থাকবে, তারপর নীতি অনুযায়ী permanent delete।
  • যেকোনো state change (reminder, grace, read-only, suspension)-এর আগে গ্রাহককে email + in-app notification যাবে, চমকে দেওয়া চলবে না।
  • Enterprise প্ল্যানে grace period ও suspension টাইমলাইন কাস্টম কন্ট্র্যাক্টে নেগোশিয়েবল হতে পারে।
// go-to-market
Setup Fee, Onboarding & Training Strategy

শুধু মাসিক সাবস্ক্রিপশন না — প্রথম ব্যবহারেই গ্রাহককে confident করে তোলার জন্য একটি One-time Setup + Training কাঠামো, যা ব্যবসা বাড়ার সাথে সাথে ধাপে ধাপে বাড়ানো যাবে।

খরচের ধরনমূল্য
Setup + Training Fee (One-time)₹2,999 – ₹4,999
Starter Plan₹499/মাস
Business Plan₹999/মাস
Premium Plan₹1,999/মাস
🚀 প্রথম গ্রাহক পাওয়ার অফার

প্রথম ৫০–১০০ জন গ্রাহকের জন্য

  • Setup Fee: ₹1,999
  • মাসিক: ₹499
  • ৭ দিনের ট্রেনিং
  • দোকানের ডেটা সেটআপে সহায়তা
  • ফোন / WhatsApp সাপোর্ট
এতে মানুষ নতুন সফটওয়্যার ব্যবহার করতে আগ্রহী হবে।
📈 জনপ্রিয় হওয়ার পর

ধাপে ধাপে Setup Fee বাড়ানো

  • Setup Fee: ₹4,999 – ₹9,999
  • Starter: ₹699 – ₹999/মাস
  • Business: ₹1,499/মাস
  • Premium: ₹2,499 – ₹2,999/মাস
// customer onboarding
৭ দিনের ট্রেনিং প্রোগ্রাম
DAY 1
সফটওয়্যার সেটআপ, লগইন, দোকানের তথ্য
DAY 2
Product, Category, Stock এন্ট্রি
DAY 3
Purchase, Supplier, Inventory
DAY 4
Sales (POS), Invoice, Due
DAY 5
Customer, CRM, Lead Management
DAY 6
Reports, Profit/Loss, Expenses
DAY 7
Online Shop, Backup, প্রশ্নোত্তর, লাইভ প্র্যাকটিস

⚠️ একটি বিষয় খেয়াল রাখুন

প্রতিটি গ্রাহককে নিজে ৭ দিন ধরে শেখালে ১০০–২০০ জন গ্রাহক হলে সময় সামলানো কঠিন হবে। তাই শুরু থেকেই তৈরি রাখুন:

  • ভিডিও টিউটোরিয়াল
  • বাংলা User Manual
  • সফটওয়্যারের ভেতরে Help Center

তাহলে আপনাকে শুধু জটিল সমস্যাগুলোতে সাহায্য করতে হবে।

// scale without hiring more trainers
Onboarding Automation

উপরের ৭ দিনের training একজন মানুষ চালালে ভালো লাগে, কিন্তু স্কেল করে না। তাই মূল onboarding journey-টা একটা automated trigger sequence হিসেবে বানানো হবে — সিস্টেম নিজেই সঠিক সময়ে সঠিক নাজ (in-app checklist + email/WhatsApp) পাঠাবে, মানুষ শুধু যেখানে আটকে আছে সেখানেই ঢুকবে।

Day 0 → Shop created (স্বয়ংক্রিয় ওয়েলকাম ইমেইল/WhatsApp + in-app checklist তৈরি) Day 1 → Product import guide (নাজ: "প্রথম ১০টা পণ্য যোগ করুন") Day 2 → First purchase tutorial (নাজ: "প্রথম Purchase এন্ট্রি দিন") Day 3 → First POS sale (নাজ: "প্রথম Sale সম্পন্ন করুন") Day 5 → Report tutorial (নাজ: "আপনার প্রথম Daily Report দেখুন") Day 7 → Onboarding completion check (checklist সম্পূর্ণ কিনা যাচাই)
01

In-app Checklist

Dashboard-এ একটা persistent progress checklist থাকবে ("৩/৬ ধাপ সম্পন্ন") — গ্রাহক নিজে দেখতে পারবে কোথায় আছেন, সাপোর্টকে জিজ্ঞেস না করেই।

02

Automated Nudge

প্রতিটা Day-milestone অনুযায়ী নির্দিষ্ট সময়ে email + WhatsApp reminder স্বয়ংক্রিয়ভাবে যাবে — কোনো human trigger লাগবে না।

03

Skip Detection

নির্ধারিত Day-এ প্রত্যাশিত অ্যাকশন (যেমন প্রথম Sale) না হলে সেটা "stuck" হিসেবে চিহ্নিত হবে ও পরদিন একটা follow-up নাজ যাবে।

04

Human Escalation Rule

Day 7-এর completion check-এ checklist অসম্পূর্ণ থাকলে সেই অ্যাকাউন্ট স্বয়ংক্রিয়ভাবে support queue-তে flag হবে — শুধু তখনই মানুষ ম্যানুয়ালি ফোন/WhatsApp করবে।

05

Onboarding Analytics

কোন ধাপে সবচেয়ে বেশি গ্রাহক আটকে যাচ্ছে (drop-off point) তা ড্যাশবোর্ডে ট্র্যাক হবে — যাতে নাজ/tutorial নিয়মিত উন্নত করা যায়।

06

Completion Tag

Day 7-এ সব ধাপ সম্পন্ন হলে অ্যাকাউন্ট "Onboarded" ট্যাগ পাবে — CRM/support-এর কাছে এটা একটা সংকেত যে এই গ্রাহকের basic হ্যান্ডহোল্ডিং লাগবে না।

💡 লক্ষ্য: ৭ দিনের human-led training শুধু প্রথম দিকের গ্রাহকদের জন্য বা জটিল কেসে রাখা হবে; বাকি সবার জন্য এই automated sequence-ই প্রাথমিক onboarding চালাবে — এতে গ্রাহক সংখ্যা বাড়লেও manual support লোড লিনিয়ারভাবে না বেড়ে অনেকটা flat থাকবে।
💡 শুরুতে ₹1,999 – ₹2,999 এককালীন Setup + Training Fee এবং ₹499/মাস — এটি একটি ভালো ভারসাম্য হবে। পরে সফটওয়্যারের মান ও চাহিদা বাড়লে ধীরে ধীরে দাম বাড়ানো যাবে।
// architecture
Domain, Subdomain & Multi-tenant Architecture

একটাই কোডবেস, একটাই সার্ভার — কিন্তু প্রতিটা দোকানের ডেটা সম্পূর্ণ আলাদা, সুরক্ষিত ও strict নিয়মে isolated। সোর্স কোড আলাদাভাবে কাউকে দেওয়ার দরকার নেই।

🆓 সব প্ল্যানে ফ্রি

Free Subdomain

সাইনআপ করলেই স্বয়ংক্রিয়ভাবে একটা subdomain তৈরি হবে — কোনো এক্সট্রা কনফিগারেশন লাগে না।

shopname.retailos.com
💎 Premium / Enterprise

Custom Domain

নিজস্ব ডোমেইন (DNS-এ CNAME পয়েন্ট করানো) কানেক্ট করা যাবে — নতুন সার্ভার লাগে না, শুধু কনফিগারেশন।

shopname.com
// one codebase, isolated data
Multi-tenant মডেল
এক সার্ভার / এক কোডবেস / এক ডাটাবেস (shared DB, tenant_id দিয়ে separate) │ ├── shop1.retailos.com → Shop A-এর ডেটা (isolated) ├── shop2.retailos.com → Shop B-এর ডেটা (isolated) ├── shop3.retailos.com → Shop C-এর ডেটা (isolated) └── shopname.com → Custom domain (Premium/Enterprise)

✅ মূল নিয়ম

  • একটা ফিচার আপডেট করলে সব দোকানের জন্য একসাথে চালু হয়ে যায় — আলাদা আলাদা করে আপডেট করার দরকার নেই।
  • এক দোকান আরেক দোকানের ডেটা কখনো দেখতে পারবে না।
  • সোর্স কোড আলাদা করে দেওয়ার দরকার শুধু তখনই, যদি কেউ One-time License কিনে নিজের সার্ভারে self-host করতে চায় (আলাদা, higher pricing-এ)।
// non-negotiable
Multi-tenant Security Rules

Shared database মডেলে একটা মাত্র query-র ভুল পুরো tenant isolation ভেঙে দিতে পারে। তাই এই নিয়মগুলো কোনো module-এর জন্যই optional নয় — Phase 0 architecture doc-এর অংশ হিসেবে দিন থেকেই enforce করতে হবে।

⚠️ Core Isolation Rules
  1. Every tenant-owned table must contain a tenant_id column — কোনো exception নেই।
  2. Every tenant query must be automatically scoped — ডেভেলপারকে ম্যানুয়ালি প্রতিটা query-তে WHERE tenant_id = ? লিখতে হবে না, এটা query layer-এই default হয়ে যাবে।
  3. Tenant ID must never come directly from an editable frontend request (body, query param, hidden field) — সবসময় authenticated session / resolved domain থেকে আসবে, ইউজার পাঠানো কোনো value থেকে না।
  4. Tenant access must be verified through a fixed chain:
    Domain → Tenant → Authenticated User → Permission
01

Global Tenant Scope

ORM / query builder লেভেলে একটা default global scope থাকবে যা প্রতিটা মডেল query-তে স্বয়ংক্রিয়ভাবে tenant_id ফিল্টার যোগ করে দেয় — কেউ ভুলে বাদ দিলেও ডেটা leak হবে না।

02

Tenant Middleware

প্রতিটা incoming request-এ domain/subdomain থেকে tenant resolve করে request context-এ inject করা হবে — বাকি পুরো অ্যাপ ওই context থেকেই tenant জানবে।

03

Tenant-aware Authorization

শুধু role/permission চেক করলেই হবে না — ইউজার আসলেই ওই নির্দিষ্ট tenant-এর সদস্য কিনা, সেটাও প্রতিটা authorization check-এ যাচাই হবে।

04

Cross-tenant Access Test

প্রতিটা রিলিজের আগে একটা automated test suite চলবে যা এক tenant-এর session/token দিয়ে অন্য tenant-এর ডেটা access করার চেষ্টা করে — এবং সেটা fail (blocked) হওয়া বাধ্যতামূলক।

05

Tenant-specific Backup

প্রতিটা shop-এর ডেটা আলাদাভাবে export/backup ও restore করা যাবে — পুরো ডাটাবেস না ছুঁয়ে একটা নির্দিষ্ট tenant-এর ডেটা নিয়েই কাজ করা সম্ভব হবে।

06

Tenant Deletion Policy

Shop cancel/close হলে সাথে সাথে hard delete না — নির্দিষ্ট grace period-এর জন্য soft delete + archive, তারপর নীতি অনুযায়ী permanent delete।

// why, not just what
Architecture Decision Records (ADR)

Phase 0-তে কোন কোন সিদ্ধান্ত নেওয়া হবে সেটা আগেই ঠিক আছে — কিন্তু কেন নেওয়া হলো, কী বিকল্প বাদ দেওয়া হলো, আর কোন ঝুঁকি জেনে-শুনে নেওয়া হলো, সেটার লিখিত রেকর্ড না থাকলে ৬ মাস পর কেউ প্রশ্ন তুললে জবাব দেওয়া কঠিন হয়ে যায়। এই সেকশন সেই "কেন"-এর দলিল।

প্রতিটা ADR-এ ৪টা অংশ থাকে — Decision (কী ঠিক হলো), Reason (কেন এটাই বেছে নেওয়া হলো), Risk (এই সিদ্ধান্তের ফলে কী ঝুঁকি তৈরি হয়) আর Mitigation (সেই ঝুঁকি কীভাবে সামলানো হবে)। কোনো decision পরে বদলাতে হলে, পুরনো ADR মুছে ফেলা হয় না — নতুন একটা ADR যোগ করে পুরনোটাকে "Superseded" মার্ক করা হয়।
ADR-001 · Database Isolation
Shared Database + tenant_id
Decided · Phase 0
Decision

এক ডাটাবেস, প্রতিটা tenant-owned টেবিলে tenant_id কলাম দিয়ে data আলাদা রাখা হবে — আলাদা ডাটাবেস বা schema-per-tenant নয়।

Reason

কম infra খরচ, সহজ migration/deployment (একবারে সব tenant আপডেট হয়), নতুন দোকান সাইনআপে সাথে সাথে সার্ভার provisioning লাগে না।

Risk

একটা ভুল query-তে cross-tenant data leak হওয়ার সম্ভাবনা — shared model-এর সবচেয়ে বড় দুর্বলতা।

Mitigation

ORM-লেভেলে global tenant scope, tenant middleware, ও প্রতিটা রিলিজের আগে বাধ্যতামূলক automated cross-tenant access test (বিস্তারিত: Tenancy সেকশন)।

বিকল্প বিবেচিত হয়েছিল: Database-per-tenant (সম্পূর্ণ isolated কিন্তু costly ও migration জটিল), Schema-per-tenant (মাঝামাঝি, তবে PostgreSQL-নির্ভর ও ops overhead বেশি)।
ADR-002 · Background Processing
Queue System — Database driver দিয়ে শুরু, পরে Redis
Decided · Phase 0
Decision

Laravel Queue ব্যবহার হবে — শুরুতে database driver, ট্রাফিক বাড়লে Redis driver-এ migrate করা হবে। Invoice generation, WhatsApp/SMS পাঠানো, report export — সব async job হিসেবে চলবে।

Reason

শুরুতে আলাদা Redis সার্ভার maintain না করে দ্রুত launch করা যায়; কোড একই থাকে, শুধু .env-এ driver বদলালেই migration হয়ে যায়।

Risk

Database driver উচ্চ concurrency-তে ধীর ও DB-তে অতিরিক্ত লোড তৈরি করে — অনেক tenant একসাথে সক্রিয় হলে bottleneck হতে পারে।

Mitigation

Job table-এ index, queue-ভিত্তিক worker আলাদা রাখা (notifications আলাদা queue, reports আলাদা queue), এবং একটা নির্দিষ্ট active-tenant থ্রেশহোল্ডে Redis-এ পূর্বনির্ধারিতভাবে সুইচ করার প্ল্যান রাখা।

বিকল্প বিবেচিত হয়েছিল: শুরু থেকেই Redis/SQS (বেশি robust কিন্তু early-stage-এ অপ্রয়োজনীয় infra খরচ ও complexity)।
ADR-003 · Performance
Cache Strategy — Redis (application + query cache)
Decided · Phase 0
Decision

Dashboard KPI, product/category list, permission matrix-এর মতো ঘন ঘন-পড়া কিন্তু কম-পরিবর্তনশীল ডেটা Redis-এ cache হবে, tenant-scoped cache key দিয়ে।

Reason

Multi-tenant dashboard-এ একই ধরনের aggregate query বারবার চলে — cache ছাড়া DB-তে অপ্রয়োজনীয় লোড পড়ে, বিশেষত Business Health Score-এর মতো heavy calculation-এ।

Risk

Cache key-তে tenant_id বাদ পড়লে এক tenant-এর cached data আরেক tenant দেখে ফেলতে পারে — stale/leaked data দুটোই সম্ভব।

Mitigation

সব cache key তৈরির একটাই central helper থাকবে যা বাধ্যতামূলকভাবে tenant_id prefix যোগ করে; write operation-এ related cache tag invalidate করা standard practice হবে।

বিকল্প বিবেচিত হয়েছিল: No caching (simple কিন্তু scale-এ ধীর), File/APCu cache (single-server-এ ঠিক আছে, কিন্তু multi-server scaling-এ কাজ করে না)।
ADR-004 · Assets
File Storage — S3-compatible object storage
Decided · Phase 0
Decision

Product image, invoice PDF, backup export — সব local disk-এ নয়, S3-compatible storage (যেমন DigitalOcean Spaces/Wasabi)-এ tenant-ভিত্তিক folder path দিয়ে রাখা হবে।

Reason

Server redeploy বা horizontal scaling-এ local disk-এর ফাইল হারানোর/অসামঞ্জস্যতার ঝুঁকি থাকে; object storage থেকে CDN-এর মাধ্যমে দ্রুত সার্ভ করা যায়।

Risk

Third-party storage provider-এর downtime বা মাসিক খরচ বৃদ্ধি; ভুল করে public bucket policy সেট হলে অন্য tenant-এর ফাইল exposed হতে পারে।

Mitigation

Signed/temporary URL দিয়ে sensitive ফাইল সার্ভ করা, bucket policy audit checklist, এবং provider abstraction layer রাখা যাতে দরকার হলে provider বদলানো সহজ হয়।

বিকল্প বিবেচিত হয়েছিল: Local server disk (সস্তা, দ্রুত শুরু করা যায়, কিন্তু scaling ও reliability-তে দুর্বল)।
ADR-005 · Discoverability
Search Engine — DB index দিয়ে শুরু, dedicated engine পরে
Decided · Phase 0
Decision

Product/customer/invoice সার্চ শুরুতে MySQL full-text index ও proper indexing দিয়ে চলবে; product catalog বড় হলে Meilisearch/Typesense যোগ করার সিদ্ধান্ত নেওয়া হবে।

Reason

প্রাথমিক পর্যায়ে প্রতিটা দোকানের product সংখ্যা তুলনামূলক কম — আলাদা search infra maintain করা অপ্রয়োজনীয় খরচ ও complexity।

Risk

Product সংখ্যা ও tenant সংখ্যা বাড়লে DB-based সার্চ ধীর হয়ে যেতে পারে, বিশেষত fuzzy/typo-tolerant সার্চে।

Mitigation

সার্চ layer-কে interface-এর পেছনে abstract রাখা হবে, যাতে পরে dedicated engine-এ সুইচ করলে বাকি কোড না বদলাতে হয়; product-count থ্রেশহোল্ড নির্ধারণ করে রাখা হবে migration trigger হিসেবে।

বিকল্প বিবেচিত হয়েছিল: শুরু থেকেই Elasticsearch/Meilisearch (overkill infra early-stage-এর জন্য)।
ADR-006 · Money Movement
Payment Gateway — Aggregator (bKash / Nagad / SSLCommerz)
Decided · Phase 0
Decision

Subscription billing ও online store checkout-এর জন্য একটা payment aggregator (SSLCommerz-জাতীয়) ব্যবহার হবে যা bKash/Nagad/card একসাথে সাপোর্ট করে — প্রতিটা gateway আলাদা integrate করা হবে না।

Reason

একটা integration দিয়েই বাংলাদেশের প্রধান পেমেন্ট মেথডগুলো কভার হয়ে যায় — প্রতিটা মেথড আলাদা integrate করলে maintenance ও compliance overhead অনেক বেড়ে যেত।

Risk

Aggregator downtime হলে সব পেমেন্ট মেথড একসাথে বন্ধ হয়ে যায়; transaction fee সরাসরি gateway integrate করার চেয়ে বেশি।

Mitigation

Manual/offline payment option (bank transfer + admin approval) সবসময় fallback হিসেবে রাখা হবে; webhook-ভিত্তিক payment confirmation-এর সাথে idempotency check বাধ্যতামূলক থাকবে যাতে duplicate charge না হয়।

বিকল্প বিবেচিত হয়েছিল: প্রতিটা মেথড (bKash, Nagad) সরাসরি আলাদা API integrate করা (বেশি নিয়ন্ত্রণ কিন্তু অনেক বেশি ডেভেলপমেন্ট ও maintenance সময়)।
ADR-007 · Customer Communication
WhatsApp Provider — Official Cloud API
Decided · Phase 0
Decision

Lead follow-up, order confirmation, ও notification-এর জন্য Meta-এর official WhatsApp Cloud API ব্যবহার হবে — কোনো unofficial/browser-automation ভিত্তিক সমাধান নয়।

Reason

Official API স্থিতিশীল, rate-limit predictable, এবং account ব্যান হওয়ার ঝুঁকি নেই — যা SaaS-এর জন্য বাধ্যতামূলক নির্ভরযোগ্যতা।

Risk

Per-message খরচ ও template pre-approval প্রয়োজন — unofficial সমাধানের চেয়ে ধীর সেটআপ ও চলমান খরচ বেশি।

Mitigation

Notification layer provider-agnostic রাখা হবে (SMS fallback সহ), এবং প্রায়শই ব্যবহৃত টেমপ্লেটগুলো আগে থেকেই approve করিয়ে রাখা হবে।

বিকল্প বিবেচিত হয়েছিল: Third-party unofficial BSP/browser-automation টুল (সস্তা কিন্তু account-ban ও reliability ঝুঁকি অনেক বেশি — SaaS-এর জন্য অগ্রহণযোগ্য)।
ADR-008 · Disaster Recovery
Backup Architecture — Automated daily + tenant-level export
Decided · Phase 0
Decision

প্রতিদিন পুরো ডাটাবেসের automated backup object storage-এ যাবে, সাথে প্রতিটা tenant আলাদাভাবে নিজের data export/download করতে পারবে (tenant-specific backup, Tenancy সেকশনে উল্লেখিত)।

Reason

Shared database মডেলে একক ব্যর্থতা (বাগ, ভুল migration, accidental delete) সব tenant-কে প্রভাবিত করতে পারে — দ্রুত পূর্বাবস্থায় ফেরার সক্ষমতা বাধ্যতামূলক।

Risk

শুধু full-DB backup থাকলে একটা tenant-এর data restore করতে পুরো ডাটাবেস affect হওয়ার ঝুঁকি থাকে; backup ব্যর্থ হলেও কেউ খেয়াল নাও করতে পারে।

Mitigation

Backup সফল/ব্যর্থ হওয়ার automated alert, নিয়মিত restore-drill (test restore) সিডিউল, এবং tenant-level export আলাদা রাখা যাতে single-tenant restore পুরো ডাটাবেস না ছুঁয়ে করা যায়।

বিকল্প বিবেচিত হয়েছিল: শুধু full-DB backup (সহজ, কিন্তু granular/single-tenant recovery সম্ভব না)।
ADR-009 · Data Model
Multi-branch — একই tenant-এর অধীনে branch_id
Decided · Phase 0
Decision

একাধিক শাখাওয়ালা দোকানের জন্য প্রতিটা শাখা আলাদা tenant নয় — একই tenant-এর অধীনে branch_id দিয়ে inventory, sales, staff আলাদা করা হবে।

Reason

Owner-এর কাছে সব শাখার consolidated report/dashboard দরকার — আলাদা tenant হলে cross-branch reporting জটিল হয়ে যেত এবং subscription billing-ও দ্বৈত হতো।

Risk

tenant_id ও branch_id — দুই স্তরের scoping একসাথে সামলাতে হয়, একটা বাদ পড়লে এক শাখার staff আরেক শাখার data দেখে ফেলতে পারে।

Mitigation

branch-level scope একই global scope mechanism-এ tenant_id-এর সাথে chain করা থাকবে; staff role-এ "assigned branch" বাধ্যতামূলক field হিসেবে থাকবে ও authorization-এ যাচাই হবে।

বিকল্প বিবেচিত হয়েছিল: প্রতিটা শাখা আলাদা tenant হিসেবে treat করা (isolation সহজ কিন্তু consolidated owner view ও billing জটিল হয়ে যায়)।
ADR-010 · API Convention
REST + versioned endpoints — GraphQL নয়
Decided · Phase 0
Decision

সব internal ও ভবিষ্যতের mobile-app API versioned REST endpoint (/api/v1/...) দিয়ে বানানো হবে, একটা standard response/error format মেনে।

Reason

Team-এর পরিচিতি Laravel/REST-এ বেশি, tooling (Postman, docs) সহজ, এবং প্রথম বছরে জটিল nested query-র প্রয়োজন নেই যা GraphQL-এর মূল সুবিধা।

Risk

Over-fetching/under-fetching সমস্যা হতে পারে জটিল dashboard screen-এ, যেখানে একাধিক resource একসাথে দরকার হয়।

Mitigation

Dashboard-এর মতো heavy screen-এর জন্য নির্দিষ্ট aggregate/composite endpoint বানানো হবে (যেমন /dashboard-summary), যাতে বহু ছোট API call এড়ানো যায়।

বিকল্প বিবেচিত হয়েছিল: GraphQL (flexible কিন্তু learning curve, caching complexity, এবং multi-tenant authorization layer-এর সাথে যুক্ত করা বেশি জটিল)।
ADR-011 · Financial Records
Invoice Numbering — Tenant + branch scoped sequential
Decided · Phase 0
Decision

প্রতিটা invoice নম্বর tenant (ও প্রযোজ্য ক্ষেত্রে branch)-ভিত্তিক আলাদা sequence-এ জেনারেট হবে — একটা global counter নয়। জেনারেশন হবে atomic DB transaction দিয়ে।

Reason

প্রতিটা দোকান নিজস্ব invoice সিরিজ (যেমন ১ থেকে শুরু) আশা করে হিসাব ও ট্যাক্স রিপোর্টিং-এর জন্য — global sequence ব্যবসায়িকভাবে অর্থপূর্ণ নয়।

Risk

একসাথে অনেক concurrent sale হলে race condition-এ duplicate invoice নম্বর তৈরি হওয়ার ঝুঁকি।

Mitigation

Row-level lock/atomic increment ব্যবহার করে নম্বর জেনারেট করা হবে, এবং DB-তে (tenant_id, branch_id, invoice_no) কম্বিনেশনে unique constraint বাধ্যতামূলক থাকবে যাতে ভুলেও duplicate সংরক্ষিত না হয়।

বিকল্প বিবেচিত হয়েছিল: Global auto-increment ID-কে invoice নম্বর হিসেবে ব্যবহার (সহজ কিন্তু ব্যবসায়িকভাবে অগ্রহণযোগ্য — দোকানদার নিজের সিরিজ চায়)।
ADR-012 · Live Updates
Real-time — Polling দিয়ে শুরু, Websocket পরে
Decided · Phase 0
Decision

Dashboard KPI ও notification badge শুরুতে periodic polling দিয়ে আপডেট হবে; POS/multi-counter real-time sync-এর প্রয়োজন হলে পরের ধাপে Laravel Echo + Websocket যোগ করা হবে।

Reason

Polling implement করা সহজ ও infra-নির্ভরতা কম — প্রথম ভার্সনে একই শাখায় একাধিক POS counter একসাথে সক্রিয় থাকার case কম।

Risk

একাধিক counter/staff একসাথে stock আপডেট করলে সামান্য delay-তে stale data দেখানোর সম্ভাবনা (যেমন স্টক আউট হওয়া প্রোডাক্ট আরেক counter-এ বিক্রি করে ফেলা)।

Mitigation

Stock deduction-এর মতো critical operation-এ optimistic locking/DB-level constraint রাখা হবে যাতে race condition হলেও negative stock না হয়; polling interval short রাখা হবে high-impact screen-এ।

বিকল্প বিবেচিত হয়েছিল: শুরু থেকেই Websocket (real-time কিন্তু আলাদা persistent connection infra maintain করা early-stage-এ অপ্রয়োজনীয়)।
ADR-013 · Notification Delivery
WhatsApp Primary, SMS Fallback
Decided · Phase 0
Decision

Order/lead notification প্রথমে WhatsApp Cloud API দিয়ে পাঠানোর চেষ্টা হবে; ব্যর্থ হলে (delivery fail বা কাস্টমারের WhatsApp নেই) স্বয়ংক্রিয়ভাবে SMS-এ fallback হবে।

Reason

WhatsApp তুলনামূলক সস্তা ও rich (rich formatting, delivery status), কিন্তু বাংলাদেশে সব কাস্টমারের WhatsApp সক্রিয় নাও থাকতে পারে — SMS সবচেয়ে নির্ভরযোগ্য reach।

Risk

দুটো চ্যানেল maintain করার জন্য অতিরিক্ত complexity ও কস্ট (দুই providerর বিল), এবং fallback logic ভুল হলে duplicate notification যাওয়ার ঝুঁকি।

Mitigation

একটা central Notification service delivery-status track করবে ও fallback trigger করার আগে idempotency check করবে যাতে একই notification দুইবার না যায়; প্রতিটা tenant-এর জন্য মাসিক notification cost visible রাখা হবে।

বিকল্প বিবেচিত হয়েছিল: শুধু SMS (নির্ভরযোগ্য কিন্তু বেশি খরচ ও কম rich), শুধু WhatsApp (সস্তা কিন্তু reach সীমিত)।
ADR-014 · POS Connectivity
MVP-তে POS Online-only — Offline Queue নয়
Decided · Phase 0
Decision

MVP-তে POS সম্পূর্ণভাবে online-only থাকবে — internet connection ছাড়া sale complete করা যাবে না। Offline sale queue/local-first architecture এই ধাপে বিল্ড হবে না, RetailOS v2.0-এর scope-এ রাখা হলো।

Reason

Offline sync মানে local queue, conflict resolution (দুই device একই stock বিক্রি করলে কী হবে), ও eventual-consistency ডিজাইন — যা ডেটা মডেল ও QA effort উল্লেখযোগ্যভাবে বাড়ায়। MVP-এর লক্ষ্য দ্রুত একটা নির্ভরযোগ্য online POS দেওয়া, স্কোপ না বাড়ানো।

Risk

বাংলাদেশের অনেক দোকানে internet সংযোগ মাঝেমধ্যে বিচ্ছিন্ন হয় — সংযোগ না থাকলে সাময়িকভাবে POS ব্যবহার করা যাবে না, যা কাস্টমার অভিজ্ঞতায় প্রভাব ফেলতে পারে।

Mitigation

সংযোগ বিচ্ছিন্ন হলে POS একটা স্পষ্ট "No Connection" state দেখাবে (silent failure বা corrupt partial sale নয়); sales/marketing material-এ "offline support" দাবি করা হবে না যতক্ষণ না v2.0-এ প্রকৃতপক্ষে বিল্ড হয় — যাতে customer expectation ঠিক থাকে।

বিকল্প বিবেচিত হয়েছিল: Local-first POS + background sync queue (ভবিষ্যতে ভালো UX দেয়, কিন্তু MVP timeline-এ ফিট করে না — v2.0-এ পুনর্বিবেচনা করা হবে)।
ADR-015 · Internationalization
Multi-language UI — i18n key-based framework, শুধু বাংলা/English নয়
Decided · Phase 0
Decision

পুরো Dashboard/menu UI একটা key-based i18n framework দিয়ে বানানো হবে (Laravel localization ফাইল + frontend-এ JSON string bundle) — যেকোনো ভাষা যোগ করা যাবে, শুধু বাংলা+English hardcode করা হবে না। প্রতিটা user tenant-এর মধ্যে নিজের পছন্দের ভাষা বেছে নিতে পারবে (profile-level setting, tenant-wide নয়)।

Reason

শুরুতেই hardcoded বাংলা/English স্ট্রিং দিয়ে ৭৮টা পেজ বানালে পরে নতুন ভাষা (যেমন Hindi, Urdu, Nepali) যোগ করতে পুরো UI আবার touch করতে হতো — key-based approach দিয়ে শুরু করলে নতুন ভাষা শুধু একটা নতুন translation file।

Risk

Development শুরুতে সামান্য বেশি সময় লাগে (প্রতিটা string hardcode না করে key দিয়ে রেফার করতে হয়); অনুবাদ না হওয়া নতুন ভাষায় missing-key fallback ঠিকভাবে না সামলালে UI-তে raw key দেখা যেতে পারে।

Mitigation

UI Kit (Phase 01)-এর প্রথম component থেকেই string key discipline চালু হবে — কোনো hardcoded UI text merge হবে না; missing translation key থাকলে default (English) fallback দেখাবে, silent blank/raw-key নয়।

বিকল্প বিবেচিত হয়েছিল: শুধু বাংলা + English hardcode (দ্রুত শুরু করা যায়, কিন্তু ভবিষ্যতে নতুন ভাষার বাজারে (Hindi/Urdu-ভাষী region) সম্প্রসারণ ব্যয়বহুল হয়ে যায়)। এই ADR শুধু UI/menu অনুবাদ কভার করে — customer-facing product/invoice কনটেন্ট নিজ ভাষায় অনুবাদ করা এই স্কোপে নেই।
ADR-016 · Money Display
Multi-currency — Per-tenant single currency, live conversion নয়
Decided · Phase 0
Decision

শপ registration-এর সময় প্রতিটা tenant একটা নির্দিষ্ট currency (৳ BDT, ₹ INR, $ USD ইত্যাদি) সেট করবে — সেই currency-তেই তাদের সব POS/invoice/report চলবে। একই tenant-এর মধ্যে একাধিক currency-তে live লেনদেন (real-time exchange rate সহ) এই স্কোপে নেই।

Reason

অধিকাংশ retail shop একটা মুদ্রাতেই ব্যবসা করে — export/multi-country transaction ছাড়া live exchange-rate সিস্টেম বানানো অপ্রয়োজনীয় জটিলতা যোগ করে (rate fetch/caching, rounding rules, FX-gain/loss হিসাব)। Per-tenant single currency দিয়েই আন্তর্জাতিক গ্রাহকদের (যেমন USD ব্যবহারকারী) মূল প্রয়োজন মেটে।

Risk

Currency একবার সেট হয়ে গিয়ে অনেক sales/invoice রেকর্ড জমা হওয়ার পর বদলাতে চাইলে ঐতিহাসিক ডেটার currency মিসম্যাচ হবে — সাধারণ update দিয়ে সমাধান করা যাবে না।

Mitigation

প্রতিটা money-related টেবিলে (sales, invoices, expenses) tenant-এর currency code সংরক্ষিত থাকবে সাথে amount-এর; currency সেটিং onboarding-এর সময় একবার lock হয়ে যাবে (Data Ownership/Onboarding নিয়মের মতো) — পরে বদলাতে হলে Super Admin-এর মাধ্যমে explicit migration path (নতুন currency দিয়ে নতুন হিসাব শুরু, পুরনো রেকর্ড archive) অনুসরণ করা হবে।

বিকল্প বিবেচিত হয়েছিল: Live multi-currency (single tenant একাধিক currency-তে লেনদেন করতে পারবে, real-time rate সহ) — export-heavy বা multi-country business-এর জন্য দরকারি হতে পারে, কিন্তু বর্তমান scope-এর বাইরে; ভবিষ্যতে আলাদা ADR হিসেবে পুনর্বিবেচনা করা যাবে যদি Enterprise-tier চাহিদা আসে।
// database ERD companion
Data Ownership Matrix

Phase 0-এর Database ERD deliverable শুধু table আর relation দেখায় — কিন্তু প্রতিটা table আসলে কার (tenant / branch / platform), সেটা আলাদাভাবে লিখিত না থাকলে ডেভেলপ করার সময় scope গুলিয়ে যায়। এই ম্যাট্রিক্স প্রতিটা core entity-র জন্য owner স্তর নির্ধারণ করে।

✅ ওই স্তরে scoped/isolated — query-তে ওই ID দিয়ে ফিল্টার বাধ্যতামূলক Optional — column থাকে, কিন্তু nullable (ব্যবসার ধরন অনুযায়ী প্রযোজ্য/অপ্রযোজ্য) ❌ ওই স্তরে প্রযোজ্য নয় — কোনো column/scope নেই
Entity Tenant-owned Branch-owned Global
Product / Category / Brand / Unit✅Optional❌
Customer✅❌❌
Supplier✅Optional❌
Sale / POS Invoice✅✅❌
Purchase✅✅❌
Stock / Inventory Ledger✅✅❌
Expense✅✅❌
Employee / Staff✅✅ (assigned branch)❌
Lead / CRM Record✅Optional❌
Online Store Order✅Optional❌
Coupon / Discount Rule✅Optional❌
Shop / Tenant Profile✅ (self)❌Optional (platform read-only)
Support Ticket✅ (raised by)❌Optional (platform-visible)
Subscription Plan❌❌✅
Subscription / Billing TransactionOptional (tenant read-only)❌✅
Platform Admin / Staff❌❌✅
System Settings❌❌✅
Notification Template (default)Optional (tenant override)❌✅
Global Analytics / Platform Reports❌❌✅

✅ মূল নিয়ম

  • একটা table-এ একইসাথে tenant_id ও কোনো "global" flag দুটোই থাকবে না — কোনো table হয় tenant-scoped, নয়তো global, দুটো একসাথে মিশিয়ে ডিজাইন করা যাবে না।
  • Branch-owned মানে tenant_id + branch_id — branch কখনো tenant_id ছাড়া একা কাজ করে না, tenant স্তরের scope-এর ভেতরেই branch স্তরের scope বসে।
  • Global entity-তে কোনো tenant_id/branch_id column-ই থাকবে না; থাকলে সেটা schema-review-এ reject হবে।
  • "Optional" মার্ক করা column-গুলোর জন্য migration-এ explicit nullable() ও query layer-এ null-safe scope লিখতে হবে, যাতে ভুলবশত সব row বাদ না পড়ে যায়।
  • Database ERD ডায়াগ্রাম রিভিউ করার সময় এই ম্যাট্রিক্সের সাথে মিলিয়ে দেখা হবে — কোনো table এই তিন ক্যাটাগরির কোনোটাতেই স্পষ্টভাবে না পড়লে সেটা Phase 0 sign-off পাবে না।
// non-negotiable
Definition of Done

প্রতিটি feature-কে "complete" বলার আগে নিচের প্রতিটা শর্ত পূরণ হতে হবে — একটাও বাদ দিয়ে feature merge/close করা যাবে না।

✓UI complete
✓Mobile responsive
✓Backend complete
✓Validation complete
✓Permission applied
✓Tenant isolation verified
✓Error states handled
✓Audit log added
✓Tests passed
✓Documentation updated
✓Staging deployment completed

✅ প্রায়োগিক নিয়ম

  • এই checklist-এর যেকোনো একটা item বাকি থাকলে feature "in progress" — কোনোভাবেই "done" ধরা যাবে না।
  • Sprint review/demo-তে শুধু Definition of Done পাশ করা feature-ই দেখানো হবে; বাকিগুলো পরবর্তী sprint-এ carry-forward হবে।
  • QA section-এর test suite এই checklist-এর "Tests passed" অংশের সাথেই সরাসরি যুক্ত — একসাথে verify করা হবে।
// non-negotiable
Quality Assurance

প্রতিটি release-এর আগে একটা নির্দিষ্ট test suite অবশ্যই চালাতে হবে — শুধু "কাজ করছে মনে হচ্ছে" এই ভরসায় production-এ পুশ করা যাবে না। বিশেষ করে POS, Inventory, Tenant Isolation এবং Payment-এর মতো জায়গায় একটা ছোট বাগও সরাসরি টাকা বা ডেটা লস করাতে পারে।

01

Authentication Tests

Login, register, OTP verify, password reset, session expiry ও token refresh — সবগুলো flow ঠিকভাবে কাজ করছে কিনা।

02

Permission Tests

প্রতিটা role (Owner, Manager, Cashier ইত্যাদি) ঠিক ততটুকু অ্যাক্সেস পাচ্ছে যতটুকু তার permission matrix-এ নির্ধারিত — কম বা বেশি না।

03

Tenant Isolation Tests

এক tenant-এর session/token দিয়ে অন্য tenant-এর ডেটা কোনোভাবেই access করা না যায়, সেটা প্রতিটা release-এ যাচাই করা।

04

POS Sale Tests

Barcode scan থেকে payment ও invoice print পর্যন্ত পুরো sale flow, split payment ও discount সহ, সঠিকভাবে সম্পন্ন হচ্ছে কিনা।

05

Return Tests

Full ও partial return, stock ফেরত যোগ হওয়া, এবং refund/ledger ঠিকভাবে আপডেট হওয়া নিশ্চিত করা।

06

Inventory Calculation Tests

Purchase, sale, return, batch/expiry — প্রতিটা movement-এর পর stock count ও valuation নির্ভুল থাকছে কিনা।

07

Payment Tests

Split payment, due/partial payment, subscription billing ও gateway callback — টাকার হিসাবে কোনো mismatch নেই তা যাচাই।

08

Mobile Responsive Tests

ছোট স্ক্রিনে (ফোন/ট্যাব) সব critical flow — বিশেষত POS ও Dashboard — ভেঙে না গিয়ে ঠিকভাবে ব্যবহারযোগ্য থাকছে কিনা।

09

Browser Compatibility Tests

Chrome, Firefox, Safari ও Edge-এর সাম্প্রতিক ভার্সনে UI ও functionality সমানভাবে কাজ করছে কিনা।

// release gate
Minimum Release Rule

এই তিনটি শর্ত পূরণ না হলে কোনো release production-এ যাবে না — এটা negotiable নয়।

Critical tests → 100% pass High-priority tests → 100% pass Unresolved critical security issue → থাকা যাবে না (0)

✅ প্রায়োগিক নিয়ম

  • Critical ও High-priority test list Phase 0-এর business rules doc-এর সাথেই চূড়ান্ত করে রাখতে হবে, যাতে পরে নতুন করে সংজ্ঞায়িত করতে না হয়।
  • যেকোনো unresolved critical security issue থাকলে release automatically block হয়ে যাবে — কোনো ম্যানুয়াল override অনুমোদিত না।
  • প্রতিটা release-এর test result (pass/fail summary) পরবর্তী release-এর আগ পর্যন্ত সংরক্ষণ করে রাখতে হবে, ট্র্যাকিং ও audit-এর জন্য।
// measurable, not vibes
Performance SLO

"দ্রুত লোড হবে" — এটা একটা target না, একটা আশা। প্রতিটা critical screen/action-এর একটা নির্দিষ্ট, মাপা যায় এমন সংখ্যা থাকতে হবে, যাতে ডেভেলপমেন্টের সময় ও production monitoring-এ "pass/fail" স্পষ্টভাবে বলা যায়।

Dashboard Load
< 2s
POS Search
< 500ms
Sale Completion
< 2s
API p95 Response
< 800ms
Monthly Uptime
99.9%
// infra sizing baseline
Initial Target Load

উপরের SLO-গুলো কোন স্কেলে ধরে রাখতে হবে, সেটা না জানা থাকলে সার্ভার sizing, DB indexing, ও queue capacity — সবকিছুই আন্দাজের উপর করতে হয়। এই সংখ্যাগুলোই প্রথম বছরের infrastructure planning-এর ভিত্তি।

Initial target
৫০০ shops
Active users
৫,০০০
Sales / month
১,০০,০০০

✅ প্রায়োগিক নিয়ম

  • Load testing এই টার্গেট সংখ্যার উপর ভিত্তি করে চালানো হবে (৫০০ shop, ৫,০০০ active user সমপরিমাণ concurrent traffic simulate করে) — production-এ পৌঁছানোর আগেই।
  • এই সংখ্যা ছাড়ানোর ইঙ্গিত পেলে (যেমন ৭০% ব্যবহারে পৌঁছালে) পরবর্তী স্কেলিং ধাপ (ADR-002 queue migration, ADR-003 cache tuning) আগেভাগে trigger করতে হবে — সার্ভার ধীর হয়ে যাওয়ার পর নয়।
  • SLO miss হলে সেটা bug backlog-এর মতোই ট্র্যাক হবে, শুধু "পরে ঠিক করব" বলে বাদ দেওয়া যাবে না — বিশেষত POS Search ও Sale Completion, কারণ এগুলো সরাসরি দোকানদারের দৈনন্দিন কাজে প্রভাব ফেলে।
// non-negotiable
Security Standards

এই স্ট্যান্ডার্ডগুলো কোনো "ভবিষ্যতে যোগ করব" ফিচার না — Phase 0-এর architecture doc-এর অংশ হিসেবে দিন থেকেই বাস্তবায়িত থাকতে হবে, কারণ পরে যোগ করতে গেলে পুরো ডেটা মডেল আবার ছুঁতে হয়।

01

Password Hashing

কোনো password plain text-এ কখনো সংরক্ষণ হবে না — শক্তিশালী, salted hashing algorithm (যেমন bcrypt/argon2) ব্যবহার হবে।

02

OTP Expiry

প্রতিটা OTP-এর একটা নির্দিষ্ট, ছোট মেয়াদ থাকবে; মেয়াদ পার হলে সেটা স্বয়ংক্রিয়ভাবে অকার্যকর হয়ে যাবে।

03

Login Rate Limiting

বারবার ভুল লগইন চেষ্টা হলে IP/অ্যাকাউন্ট সাময়িকভাবে ব্লক হবে, যাতে brute-force আক্রমণ ঠেকানো যায়।

04

Session Expiry

নির্দিষ্ট সময় নিষ্ক্রিয় থাকলে সেশন স্বয়ংক্রিয়ভাবে expire হবে এবং re-authentication চাইবে।

05

CSRF Protection

প্রতিটা state-changing request-এ CSRF token যাচাই বাধ্যতামূলক, যাতে ভুয়া/ক্রস-সাইট রিকোয়েস্ট গ্রহণ না হয়।

06

Role-based Access

প্রতিটা অ্যাকশন role/permission matrix অনুযায়ী চেক হবে — শুধু UI-তে লুকিয়ে রাখলেই হবে না, backend-এ enforce থাকতে হবে।

07

Audit Logs

কে, কখন, কোন ডেটা তৈরি/সম্পাদনা/মুছেছে — এই তথ্য ট্র্যাক হবে, বিশেষত financial ও inventory-সংক্রান্ত অ্যাকশনে।

08

Encrypted Backups

ব্যাকআপ ফাইল rest-এ encrypted থাকবে, যাতে সেটা চুরি হলেও সরাসরি readable না হয়।

09

Daily Automated Backup

প্রতিদিন স্বয়ংক্রিয়ভাবে পুরো ডেটাবেস (ও প্রয়োজনে ফাইল) ব্যাকআপ নেওয়া হবে, ম্যানুয়াল হস্তক্ষেপ ছাড়াই।

10

Backup Restore Test

ব্যাকআপ শুধু নিলেই হবে না — নিয়মিত বিরতিতে restore করে দেখতে হবে যে সেটা আসলেই কাজ করে।

11

Sensitive Data Access Logging

Customer/payment-এর মতো sensitive ডেটা কে অ্যাক্সেস করেছে, তা আলাদাভাবে লগ হবে — সাধারণ audit log-এর চেয়ে বেশি নজরদারিতে।

// backup ≠ recovery
Backup & Restore Objectives

শুধু ব্যাকআপ নেওয়া হচ্ছে জানলেই চলবে না — কতটা ডেটা হারানো "গ্রহণযোগ্য" (RPO) আর সমস্যার পর সার্ভিস কত দ্রুত ফিরে আসবে (RTO), সেই সংখ্যা লিখিতভাবে ঠিক না থাকলে ক্রাইসিসের সময় প্রতিশ্রুতি আর বাস্তবতা মিলবে না।

Database backup
প্রতি ৬ ঘণ্টা
Daily full backup
প্রতিদিন
Backup retention
৩০ দিন
RPO · Recovery Point Objective
সর্বোচ্চ ৬ ঘণ্টা

যেকোনো disaster-এ সর্বোচ্চ ৬ ঘণ্টার ডেটা হারানো গ্রহণযোগ্য ধরা হবে — এর বেশি হলে সেটা target miss হিসেবে গণ্য হবে ও review হবে।

RTO · Recovery Time Objective
৪ ঘণ্টার মধ্যে

Critical service (login, POS, checkout) ইনসিডেন্টের পর সর্বোচ্চ ৪ ঘণ্টার মধ্যে restore করে চালু করার লক্ষ্য — এর বেশি সময় লাগলে escalation trigger হবে।

Restore Test
মাসে ১ বার

শুধু backup file আছে ধরে নেওয়া যাবে না — প্রতি মাসে অন্তত একবার আসল restore করে যাচাই করা হবে যে সেটা সত্যিই কার্যকর, এবং সময় লেগেছে কতটা তা লগ হবে।

// when something goes wrong
Security Incident Process

Tenant isolation rule যতই শক্তিশালী হোক, "যদি একটা incident ঘটেই যায়" — তার জন্য একটা fixed, প্র্যাকটিসড response process থাকতে হবে। ঘটনার মুহূর্তে সিদ্ধান্ত নেওয়ার চেষ্টা করলে ভুল হওয়ার সম্ভাবনা বেশি; তাই এই ধাপগুলো Phase 0-তেই লিখে রাখা।

01
Incident detected
↓
02
Affected account/tenant restricted
↓
03
Logs preserved
↓
04
Impact assessed
↓
05
Security fix deployed
↓
06
Affected customer notified
↓
07
Post-incident review
Who can access production database?

খুবই সীমিত সংখ্যক senior engineer — নামসহ একটা fixed access list থাকবে, এবং সরাসরি DB access সাধারণ ডেভেলপমেন্ট workflow-এর অংশ হবে না। Read-only দরকার হলে আলাদা replica/reporting connection ব্যবহার হবে।

Emergency access কীভাবে হবে?

নির্দিষ্ট incident-এর জন্য সাময়িক, time-boxed access গ্রান্ট করা হবে (যেমন ২৪ ঘণ্টার জন্য) — অনুমোদনসহ, এবং মেয়াদ শেষে স্বয়ংক্রিয়ভাবে revoke হয়ে যাবে। প্রতিটা emergency access grant নিজেই একটা audit-logged ইভেন্ট।

Admin action audit হবে?

হ্যাঁ — প্রতিটা Super Admin/Platform Admin অ্যাকশন (tenant suspend, plan override, manual refund, data export ইত্যাদি) কে, কখন, কী করেছে তা immutable audit log-এ থাকবে, যা কোনো admin নিজেও এডিট/মুছতে পারবে না।

Suspicious login alert থাকবে?

হ্যাঁ — নতুন ডিভাইস/অস্বাভাবিক লোকেশন থেকে লগইন, বারবার ব্যর্থ লগইন চেষ্টা, বা একই অ্যাকাউন্টে অস্বাভাবিক সময়ে multiple session তৈরি হলে — অ্যাকাউন্ট মালিককে (ও প্রয়োজনে platform admin-কে) স্বয়ংক্রিয় নোটিফিকেশন যাবে।

Security log কতদিন রাখা হবে?

Audit ও sensitive-access log কমপক্ষে ১২ মাস রাখা হবে (কমপ্লায়েন্স/dispute resolution-এর জন্য); সাধারণ application log ৯০ দিন পর archive/rotate হবে। Incident-সংশ্লিষ্ট log আলাদাভাবে সংরক্ষিত থাকবে যতদিন না post-incident review সম্পন্ন হয়।

// known unknowns, written down
Risk Register

প্রতিটা বড় প্রজেক্টে ঝুঁকি থাকে — সমস্যা হয় যখন সেগুলো কারো মাথায় থাকে কিন্তু কোথাও লেখা থাকে না। এই register-এ প্রতিটা চেনা ঝুঁকির probability, impact, owner ও mitigation প্ল্যান লিখিতভাবে থাকবে, এবং প্রতি sprint review-তে status আপডেট হবে।

ID Risk Probability Impact Severity Owner Mitigation Status
RSK-01 Cross-tenant data leakSecurity Low Critical High Lead Backend Eng Global ORM tenant scope + বাধ্যতামূলক automated cross-tenant test প্রতি release-এর আগে (ADR-001)। Monitoring
RSK-02 Backup আছে কিন্তু restore আসলে কাজ করে নাOperations Medium Critical High DevOps মাসে অন্তত ১ বার লাইভ restore test, সময় ও ফলাফল লগ করা (দেখুন Backup & Restore Objectives)। Monitoring
RSK-03 একমাত্র সিনিয়র ডেভেলপারের উপর নির্ভরতা (key-person risk)Team Medium High High Project Lead ADR ডকুমেন্টেশন, code review বাধ্যতামূলক, critical module-এ কমপক্ষে ২ জনের familiarity নিশ্চিত করা। Open
RSK-04 v1.0 সম্পূর্ণ হওয়ার আগে v1.5/v2.0 ফিচার শুরু (scope creep)Process High Medium Medium Project Lead Release Plan-এর "প্রায়োগিক নিয়ম" কঠোরভাবে অনুসরণ — v1.0 sign-off ছাড়া v1.5 branch-ই ওপেন হবে না। Monitoring
RSK-05 Tenant/product সংখ্যা বাড়ার সাথে DB পারফরম্যান্স কমে যাওয়াTechnical Medium Medium Medium Lead Backend Eng Query-level index review, Redis cache layer (ADR-003), এবং search engine migration থ্রেশহোল্ড আগে থেকেই ঠিক করা (ADR-005)। Open
RSK-06 WhatsApp/SMS API-এর rate-limit বা pricing পরিবর্তনThird-party Medium Medium Medium Product Owner Provider abstraction layer রাখা যাতে দ্রুত অন্য gateway-এ সুইচ করা যায়; fallback SMS/email channel রাখা। Open
RSK-07 Object storage provider outage বা bucket misconfigurationInfrastructure Low Medium Low DevOps Signed/temporary URL, bucket policy audit checklist, provider abstraction layer (ADR-004)। Mitigated
RSK-08 Consumption Prediction ভুল হয়ে গ্রাহকের আস্থা কমে যাওয়াProduct Medium Low Low Product Owner Prediction-কে "suggestion" হিসেবে ফ্রেম করা, confidence কম হলে UI-তে স্পষ্টভাবে দেখানো, ম্যানুয়াল override সবসময় খোলা রাখা। Open
RSK-09 Pricing plan-এর margin আসলে টার্গেট অনুযায়ী না মেলাBusiness Medium Medium Medium Founder / Finance Unit Economics সেকশনের হিসাব প্রতি quarter রিভিউ, infra খরচ বাড়লে plan pricing পুনর্মূল্যায়ন। Monitoring
High business-critical impact — সরাসরি টাকা, ডেটা বা multi-tenant বিশ্বাসের ক্ষতি Medium সার্ভিস/টাইমলাইন প্রভাবিত হবে, তবে সরাসরি ক্যাটাস্ট্রফিক নয় Low লোকালাইজড ইমপ্যাক্ট, ওয়ার্কঅ্যারাউন্ড সম্ভব

✅ প্রায়োগিক নিয়ম

  • প্রতিটা High-severity risk-এর একটা named owner থাকতেই হবে — "team" বা "সবাই" owner হতে পারবে না।
  • এই register প্রতি sprint review-তে revisit হবে; নতুন ঝুঁকি চোখে পড়লে সাথে সাথে যুক্ত করা হবে, পুরনো কোনো entry ইতিহাস থেকে মুছে ফেলা হবে না — শুধু status বদলাবে (Open → Monitoring → Mitigated)।
  • কোনো risk production incident-এ পরিণত হলে, সেটার Security Incident Process অনুসরণ করা হবে এবং post-incident review-এর ফলাফল এই register-এর mitigation column-এ ফিরে আসবে।
// what blocks what
Dependency Map

কোন module কোন module-এর উপর নির্ভরশীল, আর কোন module বন্ধ থাকলে আর কী কী আটকে যায় — এটা আগে থেকে স্পষ্ট না থাকলে sprint planning-এ ভুল ক্রমে কাজ শুরু হয়ে যায় এবং শেষ মুহূর্তে rework লাগে। v1.0-এর জন্য একটা নির্দিষ্ট critical path-ও চিহ্নিত করা হয়েছে — এই চেইনের কোনো একটা ধাপ দেরি হলে সরাসরি পুরো v1.0 launch date পিছিয়ে যাবে।

⚠ Critical Path · v1.0
01
Authentication
Login, tenant provisioning, session
↓
02
Tenant Setup
Shop profile, branch, ADR-001 scope active
↓
03
Roles & Permissions
সব পরের module-এর permission gate
↓
04
Products
Catalog, category, unit
↓
05
Inventory
Stock ledger, purchase-in
↓
06
POS
Checkout, invoice generation
↓
07
Sales & Reports
v1.0 launch-ready state

এই সাতটা ধাপ সিরিয়ালি নির্ভরশীল — প্রতিটা ধাপ তার আগের ধাপের উপর hard dependency (নিচের dependency card-গুলোতে বিস্তারিত)। এর বাইরে যা কিছু আছে (CRM, WhatsApp, Consumption Prediction, Online Store) সেগুলো এই critical path-এর সাথে parallel বা পরের release-এ চলবে — এগুলোর দেরি হলে v1.0 launch date সরাসরি প্রভাবিত হয় না।

Products / Inventory
v1.0 · Foundation
Depends on
AuthenticationMulti-tenant schema (ADR-001)
Blocks
PurchasePOSOnline Store (v2.0)
Type
Hard dependency
POS / Checkout
v1.0 · Core
Depends on
Products/InventoryCustomers
Blocks
InvoiceReturnsBasic Reports
Type
Hard dependency
Multi-tenant Security Layer
Phase 0 · Non-negotiable
Depends on
ADR-001 sign-off
Blocks
সব data-writing modulePhase 0 sign-off
Type
Hard dependency
CRM / Loyalty
v1.5 · Growth
Depends on
Customers (v1.0)POS transaction history
Blocks
Due RemindersWhatsApp integration
Type
Design পারে শুরু হতে, build নয়
Consumption Prediction Engine
v1.5 · Growth
Depends on
ন্যূনতম historical sales dataInventory ledger
Blocks
Due Reminders (accuracy)
Type
Data dependency, code নয়
Online Store
v2.0 · Scale
Depends on
Products/InventoryCoupon/Discount RulePayment gateway
Blocks
কিছুই না — leaf module
Type
Hard dependency
Multi-branch / Enterprise Controls
v2.0 · Scale
Depends on
Data Ownership Matrix (branch-owned entities)
Blocks
Advanced Analytics (branch-level)
Type
Hard dependency

✅ প্রায়োগিক নিয়ম

  • Hard dependency মানে depended-upon module production-ready না হলে dependent module-এ কোনো build কাজ শুরু হবে না।
  • Soft dependency মানে design/spec আগে থেকে করা যেতে পারে, কিন্তু actual implementation নির্ভরশীল module স্থিতিশীল হওয়ার আগে merge হবে না।
  • Sprint planning-এর সময় এই ম্যাপ চেক করে দেখা হবে যাতে কোনো task তার dependency শেষ হওয়ার আগেই schedule না হয়ে যায়।
  • নতুন কোনো module যুক্ত হলে, সেটার dependency এই ম্যাপে যোগ করার আগে ticket/sprint-এ তোলা যাবে না।
// who builds this
Team & Resource Allocation

কাগজে-কলমে module ভাগ করা থাকলেও, বাস্তবে কে কোন অংশের দায়িত্বে সেটা লেখা না থাকলে sprint planning-এ ধোঁয়াশা তৈরি হয়। প্রতিটা core role এবং তার responsibility scope নিচে নির্ধারণ করা হলো — নাম এখনো ঠিক না হলেও, role অনুযায়ী ownership boundary স্পষ্ট থাকা জরুরি।

01 / BACKEND

Lead Backend Engineer

Database schema, multi-tenant architecture, API, ADR ownership। Data Ownership Matrix ও Security Standards-এর মূল দায়িত্ব এই role-এর।

02 / FRONTEND

Frontend Engineer

UI Kit থেকে শুরু করে ৭৮টা পেজ implementation, responsive/theme consistency, ও component reuse বজায় রাখা।

03 / QA

QA / Test Engineer

Definition of Done checklist enforce করা, প্রতিটা release-এর আগে test suite চালানো, cross-tenant ও regression bug ধরা।

04 / DEVOPS

DevOps

Deployment pipeline, backup/restore, monitoring, infra খরচ — নিচের Infra & DevOps সেকশনের বাস্তবায়ন দায়িত্ব।

05 / PRODUCT

Product Owner

Feature scope, pricing, onboarding strategy, ও Risk Register-এ Business/Product ক্যাটেগরির ঝুঁকির owner।

06 / LEAD

Project Lead

Sprint schedule, dependency map মেনে কাজ schedule করা, key-person risk (RSK-03) mitigate করা।

✅ প্রায়োগিক নিয়ম

  • প্রতিটা role-এর জন্য একজন named owner থাকবে; একজন একাধিক role চালালেও দায়িত্ব আলাদা করে লেখা থাকবে যাতে ধোঁয়াশা না হয়।
  • Critical module-এ (payment, tenant-isolation) কমপক্ষে ২ জনের familiarity নিশ্চিত করা হবে — key-person risk কমাতে।
  • Team-এর আকার বাড়লে/কমলে এই সেকশন আপডেট হবে এবং Version Control Metadata-তে entry যুক্ত হবে।
// where and how it runs
Deployment & Infra / DevOps

Security ও Performance SLO সেকশনে "কী মান বজায় রাখতে হবে" লেখা আছে — এখানে লেখা থাকবে সেটা বাস্তবে কোন environment ও pipeline দিয়ে অর্জন করা হবে।

1
Local / Dev
Feature branch-এ ডেভেলপ, লোকাল ডেটাবেসে টেস্ট।
↓
2
CI Pipeline
Pull request-এ automated test + lint চলবে; DoD checklist এখানে enforce হবে।
↓
3
Staging
Production-এর মতো ডেটা দিয়ে QA sign-off, cross-tenant test এখানে বাধ্যতামূলক।
↓
4
Production
CD দিয়ে deploy, রোলআউটের পরে monitoring alert active থাকবে।

✅ প্রায়োগিক নিয়ম

  • Dev → Staging → Production — এই তিনটা environment সবসময় আলাদা থাকবে; production ডেটাবেসে সরাসরি টেস্ট করা যাবে না।
  • Backup & Restore Objectives অনুযায়ী মাসিক restore-test infra pipeline-এর অংশ হিসেবে schedule হবে (RSK-02 mitigation-এর সাথে সংযুক্ত)।
  • Monitoring/alerting ছাড়া কোনো নতুন module production-এ যাবে না — অন্তত uptime ও error-rate alert বাধ্যতামূলক।
  • Infra খরচ Unit Economics-এর সাথে প্রতি quarter রিভিউ হবে (RSK-09-এর সাথে সংযুক্ত)।
// document, not just code, has versions
Version Control Metadata

এই রোডম্যাপ ডকুমেন্ট নিজেই একটা living artifact — কোড-এর মতো এটারও version, owner আর change history লিখিত থাকা দরকার, যাতে "কোন সিদ্ধান্তটা কবে এবং কেন বদলালো" তা সহজে ট্রেস করা যায়।

Document Version
v1.7
Status
Living Document
Last Updated
05 Aug 2026
Owner
Karmakar Web Solution
Version Date Author Change Summary
v1.0 initial Karmakar Web Solution মূল রোডম্যাপ — Vision, Phases, 78-page inventory, Feature Specs, Tech Stack।
v1.1 +1 Karmakar Web Solution Pricing, Billing Rules ও Onboarding Strategy সেকশন যুক্ত হলো।
v1.2 +2 Karmakar Web Solution Multi-tenant Architecture, ADR, Data Ownership Matrix, Definition of Done, QA, Performance SLO ও Security Standards যুক্ত হলো — Phase 0 governance সম্পূর্ণ করা হলো।
v1.3 current Karmakar Web Solution Risk Register, Dependency Map এবং এই Version Control Metadata সেকশন যুক্ত হলো — production planning সম্পূর্ণ করার জন্য।
v1.4 current Karmakar Web Solution Team & Resource Allocation, Deployment & Infra/DevOps, এবং Legal & Compliance সেকশন যুক্ত হলো — refinement review-এ চিহ্নিত গ্যাপ পূরণের জন্য।
v1.5 current Karmakar Web Solution Phase 00 (Product & System Architecture) draft সম্পূর্ণ হলো — User Roles, Permission Matrix, Tenant Model, ERD, POS Flow, Inventory Rules, Invoice Numbering, Subscription Rules, API Conventions, Error-handling Standards। বিস্তারিত: Phase 00 Architecture Spec ডকুমেন্ট। Sign-off checklist review বাকি।
v1.6 current Karmakar Web Solution Phase 01–05-এর draft spec ডকুমেন্ট সম্পূর্ণ হলো (UI Kit, Shop Owner Panel, CRM, Online Shop, Super Admin) — এখন সবগুলো ৬টা build Phase (00–05)-এরই বিস্তারিত spec আছে, timeline-এ "Draft — sign-off pending" ট্যাগ যোগ করা হলো। প্রতিটা Phase-এর নিজস্ব sign-off checklist সংশ্লিষ্ট spec ডকুমেন্টে।
v1.7 current Karmakar Web Solution ADR-015 (Multi-language UI — i18n key framework) ও ADR-016 (Multi-currency — per-tenant single currency) যুক্ত হলো। Phase 00 (Tenant Model) ও Phase 01 (UI Kit) spec-এ সংশ্লিষ্ট রেফারেন্স আপডেট করা হলো।

✅ প্রায়োগিক নিয়ম

  • এই ডকুমেন্টের কোনো major সেকশন (ADR, Risk Register, Data Ownership Matrix) বদলালে version number বাড়বে এবং change log-এ entry যুক্ত হবে — silent edit করা যাবে না।
  • Minor typo/formatting ফিক্স version bump দাবি করে না; কিন্তু কোনো decision, rule, বা number বদলালে সেটা সবসময় একটা নতুন version entry।
  • এই রোডম্যাপ ফাইলটাই source of truth ধরা হবে — অন্য কোনো chat/মেসেজ থ্রেডে নেওয়া সিদ্ধান্ত এখানে যুক্ত না হওয়া পর্যন্ত "official" নয়।
// shipping strategy
Release Plan

৭৮টা page একসাথে বানানোর চাপ না নিয়ে, তিনটা স্পষ্ট release-এ scope ভাগ করা হয়েছে — প্রতিটা release নিজে থেকেই সম্পূর্ণ ও ব্যবহারযোগ্য (usable) থাকবে।

// mvp

RetailOS v1.0

প্রথম launch — একটা দোকান চালানোর জন্য যা যা লাগবে, ঠিক ততটুকুই।

  • Authentication
  • Products
  • Customers
  • Suppliers
  • Purchase
  • Inventory
  • POS
  • Invoice
  • Returns
  • Basic reports
// growth

RetailOS v1.5

কাস্টমার রিলেশন ও রিটেনশন-ভিত্তিক ফিচার — বিক্রি বাড়ানোর দ্বিতীয় ধাপ।

  • CRM
  • Loyalty
  • Due reminders
  • WhatsApp
  • Consumption prediction
// scale

RetailOS v2.0

একাধিক শাখা ও এন্টারপ্রাইজ-লেভেল ক্লায়েন্টদের জন্য।

  • Online store
  • Multi-branch
  • Advanced analytics
  • Enterprise controls

✅ প্রায়োগিক নিয়ম

  • v1.0 সম্পূর্ণ ও production-এ যাওয়ার আগে v1.5 বা v2.0-এর কোনো ফিচার শুরু করা যাবে না।
  • প্রতিটা release নিজে থেকেই "Definition of Done" checklist ও QA test suite পাশ করেই production-এ যাবে।
  • একসাথে ৭৮টা page-এর চাপ না নিয়ে, স্কোপ এই তিনটা release-এর মধ্যে ভাগ করে ধাপে ধাপে ডেলিভার করা হবে।