Case study 02
Inventory Commerce
Retailers, distributors and online sellers in Bangladesh often run on spreadsheets, a separate POS, order lists from Facebook pages and manual accounting, so stock is wrong across branches and channels and the books lag behind. Inventory Commerce brings stock, warehouses, point of sale, purchasing, B2B sales, an online storefront with cash-on-delivery and courier fulfilment, and double-entry accounting into one system, where every sale, receipt and transfer posts its stock movement and its journal together. It starts with Bangladesh VAT and is built so a new country is a new country pack, not a rewrite.
No public site or source code. The architecture and the decisions behind it are described below.
- Founder & sole engineer
- Own product
- FinTech, SaaS
- Inventory Management, Point of Sale, E-commerce, Double-entry Accounting, Tax Engine, Multi-tenancy
- TypeScript
- Next.js
- NestJS
- PostgreSQL
- Drizzle
- Redis
- BullMQ
- Turborepo
- Docker
What Inventory Commerce does
- Inventory across branches, warehouses, zones and bins, with moving-average costing
- Warehouse management: receiving, transfers and stock counts
- Point of sale for retail branches, with cash and mobile-money payments
- Procurement: purchase orders, goods receipts, supplier bills and imports with landed cost
- B2B credit sales and accounts receivable for distributors
- Online storefront with cash-on-delivery and courier fulfilment
- Returns and refunds across every channel
- Double-entry general ledger, posted automatically from every business document
- Configurable tax engine, starting with Bangladesh VAT and statutory forms
- Multi-currency documents, with books kept in each legal entity's base currency
The problem
A shop with two branches, a stockroom and a Facebook page already has three versions of its stock. Add cash-on-delivery orders that come back undelivered, VAT forms and a distributor buying on credit, and spreadsheets stop adding up.
Approach
Every business command runs in one database transaction: the document, its stock movements, the updated costs, the journal and any statutory number commit together or not at all. Stock changes only through the inventory service and journals only through the posting service, so the warehouse and the ledger can't disagree.
Key decisions
- D1
One write path each
Stock moves only through InventoryService and journals only through PostingService, so every quantity and every balance has one source.
- D2
Revenue on delivery
COD orders move cost into goods in transit at dispatch and recognise revenue on delivery; a return to origin reverses only the stock movement.
- D3
Country packs
Tax rules, statutory documents, the chart of accounts and providers live in country packs, and lint rules stop country details leaking into the core.
My contributions
- Came up with the product and wrote its product requirements, technical design and database specification
- Designed the architecture: a NestJS modular monolith with PostgreSQL row-level security and a single write path for stock and for journals
- Defined the accounting model: a posting matrix from business events to journals, with COD revenue recognised on delivery
- Set up the monorepo with Turborepo and pnpm, with lint rules that enforce module boundaries, tenant safety and no hard-coded country rules