Objective

I am building Social Commerce so Bangladeshi Facebook, WhatsApp, and Instagram sellers can run one connected workflow — message → order → invoice → shipment → payment → delivery — without Shopify, without an ERP, and without a website. The work covers multi-tenant SaaS isolation, dual operator audiences (platform staff vs shop owners), JWT + BFF auth with RBAC, plan-aware billing, and a commerce domain designed for Bangla invoices, bKash/Nagad/Rocket, and local couriers.

Product

Social Commerce targets small shops (roughly 20–500 orders/month) that take sales from inbox, not an online store: clothing, hijab, cosmetics, gadgets, cake, home food, gifts, and furniture sellers.

• Not Shopify — no storefront required
• Bangla + English UI and documents (invoices, receipts)
• Local payments: cash, bKash, Nagad, Rocket, bank, COD
• Local couriers (planned): Pathao, RedX, Steadfast, Sundarban

Day-to-day that means replacing the broken path of Messenger → Excel → notebook → courier site → bKash SMS with a single lightweight console.

Tasks I have done

• Product and domain design: MVP scope, business rules, localization (BDT, Asia/Dhaka, +880 phones), and commerce module boundaries
• Multi-app Turborepo architecture: API, Platform console, Tenant dashboard, Landing, Worker, and Scheduler
• Express API with JWT auth (access + refresh), session rotation, Zod validation, OpenAPI/Scalar docs, and server-side tenant isolation
• Next.js BFF pattern — httpOnly cookies on the app origin; tokens never exposed to browser JS
• Platform layer: tenants, plans, subscriptions, billing events, feature flags, onboarding, and operator IAM
• Tenant IAM and organization primitives (company, branch, department, designation) as the shared foundation for commerce
• Shared-database multi-tenancy strategy with tenant_id scoping and plan-enforcement hooks
• Background architecture decision: Redis + BullMQ worker/scheduler (API stays thin; long jobs run out-of-band)
• Commerce MVP specs for customers, products, orders, invoices, and payments (manual Facebook/WhatsApp entry via source channel)

Apps

• Platform console — SaaS operators: tenants, plans, billing, system settings
• Dashboard — shop owners: orders, customers, products, invoices, payments
• Landing — marketing site (no tenant login)
• API — security boundary for auth, RBAC, platform, and commerce

Features

• Multi-tenant SaaS with platform billing separate from shop invoices/payments
• Dual-audience auth: platform operators vs tenant users, with computed RBAC
• Server-first Next.js BFF with httpOnly session cookies
• Owner-first MVP workflow: customer → order (Facebook/WhatsApp/Instagram/phone/walk-in) → invoice → payment
• Bangla/English documents; BDT amounts; Dhaka timezone; E.164 BD phones
• Payment states: paid / due / partial / COD (cash, bKash, Nagad, Rocket, bank)
• Planned courier integration and shipment tracking after MVP
• BullMQ job pipeline for future courier sync, messaging, and reports
• Plan tiers (Free / Starter / Business / Enterprise) with feature and limit enforcement designed in

Architecture

Security boundary: Express is the source of truth for identity, sessions, tenants, roles, and permissions. Next.js apps are BFF + UI only. Platform billing tables stay separate from shop invoices and payments. Background work is enqueued to Redis/BullMQ so HTTP stays thin.

Sales pipeline (MVP): Seller creates an order from a Facebook/WhatsApp/Instagram message (manual entry, sourceChannel), links a customer and products, issues a Bangla/English invoice, records cash or wallet payment (including COD), then completes delivery. Courier API sync and WhatsApp templates come after MVP.