Inam Baig / projects / ecommerce-os
Platform / E Commerce Infrastructure
E Commerce OS
Multi tenant commerce OS, private Shopify style admin, storefronts, and APIs.
100% developed with agentic engineering under full personal ownership.
Role
Agentic Engineer · Product Manager · Technical Lead
Duration
2026-07 to Present
Company
The Glance Systems
Domain
E Commerce Automation · Worldwide
Tech highlights
Problem
What was hard
Overview
Operators need owned multi brand commerce without SaaS lock in.
Users affected
Multi store operators and brands needing a private control plane.
Why difficult
Shared infrastructure must behave like independent shops.
Existing limitations
- SaaS limits on ownership and extensibility
- Weak isolation across brands
Constraints
- Strict multi tenancy
- API first modular monolith
Solution
Approach
Overview
Turborepo monorepo with Next.js admin/storefront, NestJS API, BullMQ workers, PostgreSQL+RLS, Redis.
Architecture rationale
Modular monolith + dual layer tenancy balances velocity and isolation.
Major components
- Admin
- Storefront
- API
- Workers
- Postgres
- Redis
Key capabilities
- Multi tenant stores
- Theme storefronts
- Catalog/checkout/payments
- AI assists
Contribution
My contribution
Project outcome
I designed and built a runnable multi app commerce platform end to end.
What I personally owned
- I owned 100% of product and engineering with agentic engineering
- I owned architecture, monorepo, core commerce domains, admin/storefront, AI adapters
Features
Key capabilities
Expand a card for implementation detail and user value.
Architecture
Interactive diagram
Zoom, pan, and select nodes to explore components and connections.
Operators and shoppers hit Next.js Admin and theme driven Storefronts, which call a NestJS modular monolith. Prisma + PostgreSQL RLS is the system of record; Redis backs cache and BullMQ workers for outbox driven side effects, with payment and OpenAI adapters at the edge.
Stack
Technology
Grouped by layer. No skill bar percentages.
Frontend
- Next.js
- React
- TypeScript
Backend
- NestJS
- BullMQ
- Prisma
Database
- PostgreSQL
- Redis
DevOps
- Turborepo
- pnpm
- GitHub Actions
AI / ML
- OpenAI adapters
Decisions
Engineering decisions
Shared schema with TenantContext + PostgreSQL RLS
Why
Operational simplicity with defense in depth
Trade off
RLS complexity vs safer isolation
Alternatives: DB per tenant · App filters only · App + RLS
Challenges
Engineering challenges
Multi tenant isolation on a shared database
Why hard
Shared infrastructure had to behave like independent shops without leaking catalog, orders, or customer data across brands.
Solution
I used a shared schema with TenantContext plus PostgreSQL RLS instead of DB per tenant or app only filters, defense in depth with simpler operations.
Result
Runnable Turborepo commerce OS where tenant queries are constrained at the application and database layers.
Checkout reservations under concurrent demand
Why hard
Inventory and checkout side effects can't live only in the request/response path without double selling or stale storefront state.
Solution
NestJS modular monolith with Redis cache and BullMQ/outbox workers for reservations and other side effects.
Result
Checkout and storefront resolve stay on an async, cache backed path rather than blocking the API.
Performance
Notes
Performance
- Redis storefront resolve cache
Results
Outcomes
Outcomes
- Runnable Turborepo commerce OS
Related
Related projects
Also look at
