Context
The problem
Bangladeshi merchants sell through Facebook pages and spreadsheets. Shopify exists, but it doesn't speak the local market: no bKash or Nagad, no integration with local courier networks, pricing in dollars for businesses that operate in taka. Merchants needed a storefront platform built around how commerce actually works in Bangladesh: local payments, local logistics, SMS-first customers, and cash on delivery as the default, not an afterthought.
Ownership
My role
Solo build: product scope, architecture, backend, storefront, merchant dashboard, platform admin, and every integration.
Solution
Approach
Local-first integrations
Integrated 5 payment gateways (bKash with tokenized checkout, Nagad with RSA-encrypted credentials, SSLCommerz, Surjopay, and AmarPay) plus 3 courier networks (Steadfast, Pathao, RedX) behind normalized abstractions with webhook receivers and per-provider status mapping. Gateway credentials are AES-256-GCM encrypted at rest; COD amounts are computed against prepaid gateway payments; Pathao delivery areas are remembered per customer phone so repeat checkout is one tap. SMS rides a two-provider fallback chain.
Growth tooling merchants actually use
Shipped six auto-seeded RFM segments (VIP, Loyal, At Risk, New…) that rebuild on a schedule, A/B testing with variant assignment and conversion events (winning variants apply to products through sanitized overrides), and 3-stage abandoned-cart recovery: SMS first, then email, then both, with configurable delays and discount codes. SMS first, not email, because that's the channel Bangladeshi customers respond to. Campaign dispatch and attribution run as background jobs.
Multi-tenant from day one
One codebase, row-level tenant isolation, and a membership model that lets one account run multiple stores with owner/admin/manager/viewer roles. Storefronts resolve from platform subdomains to verified custom domains; suspended tenants are blocked from mutations everywhere except their appeal endpoint. Merchants pick from 5 industry storefront templates (fashion, electronics, grocery, restaurant, general), themed per tenant.
Operations as a first-class feature
22 scheduled background jobs on a PostgreSQL-backed queue handle cart recovery, segment rebuilds, billing renewal, campaign attribution, SEO audits, image backfills, and data retention. There is no separate queue infrastructure to operate. Audit logs with hashed IPs record every merchant action; per-plan email and SMS quotas are enforced at dispatch time.
System
Architecture
A Turborepo monorepo: a Hono API, three Next.js apps (merchant admin, platform admin, marketing), four shared packages, and a separate template workspace for storefronts. PostgreSQL with Drizzle ORM underneath, pg-boss for jobs, Cloudflare R2 + Sharp for the image pipeline.
- 79 database models across 61 API route files and 66 admin pages
- Row-level tenant scoping + subdomain/custom-domain storefront resolution in middleware
- Payment and courier credentials AES-256-GCM encrypted at rest
- 22 cron jobs on a PostgreSQL-backed queue, zero extra queue infrastructure
- Per-tenant self-hosted analytics provisioning and audit logging
Results
Outcomes
5 + 3
payment gateways and courier networks integrated
79
database models under one tenant-scoped schema
22
scheduled background jobs running the platform
1 codebase
serving every merchant storefront
- Live in production at banikh.com.
- Full commerce stack, from catalog to courier handoff to cart recovery, operated by one engineer.
- Five industry storefront templates let merchants launch without a designer.
Contact
Get in touch.
If you're building something and want a hand, write to me. Same if you just want a second opinion on an architecture decision.
Prefer to talk? Grab 15 minutes in my calendar.