Kommerce
A multi-tenant e-commerce platform for cash-on-delivery markets, where every order is confirmed — by an agent in chat or a person on the phone — before it ships.
- Role
- Co-Founder & Engineer
- Dates
- 2025 – Present
Start month not pinned down on record.
Read as steps
- 01An order is written together with an outbox record in the same transaction.
- 02A SELECT … FOR UPDATE SKIP LOCKED relay drains the outbox, crash-safe and replica-safe.
- 03A deterministic closed-lexicon parser reads the customer's confirmation reply.
- 04An unambiguous reply confirms the cash-on-delivery order.
- 05Anything ambiguous hard-escalates to a human rather than letting the model guess.
The problem
In Algeria and much of MENA, most online orders are paid in cash at the door rather than by card. That changes what an e-commerce platform has to do: an order that ships without being confirmed is a real cost, because a courier drives to an address for a customer who never meant to buy. Merchants handle this by phoning every customer before dispatch, which does not scale past a certain order volume. Kommerce builds the confirmation step into the product itself, and connects a confirmed order straight through to whichever courier actually serves that commune.
What it is
A multi-tenant SaaS product. A merchant signs up, builds a storefront with a WYSIWYG page builder, and runs their orders out of the same system. Incoming orders are confirmed either by the AI sales agent in chat or by a person calling from the built-in call-center CRM, then dispatched across roughly twelve courier APIs, routed at commune level. The AI sales agent ships as an app a merchant installs on their store rather than as a fixed part of the platform. It is in production, built across a seven-app TypeScript monorepo, and co-founded with a partner.
My role
Co-founder and engineer, alongside one partner. On the engineering side I architected the domain-driven backend and the event backbone, built the AI sales and confirmation agent and its evaluation harness, the page builder and theming system, and the courier integration layer, and owned delivery on GCP. The project is in launch phase and ongoing; its start month is not pinned down on record.
Who uses it
Merchants selling cash-on-delivery in Algeria and the wider MENA market, who use it to build a storefront, take orders and get them delivered. Their call-center staff use the CRM to phone customers whose replies the agent could not resolve. Their end customers meet it as a storefront and a chat conversation — in Arabic, including Algerian darija — and can complete a cash-on-delivery order without leaving the chat.
Features
Storefront and page builder
A WYSIWYG editor where merchants assemble store pages block by block, with undo/redo and a live preview of the real storefront. An AI assistant works the same surface — creating pages, editing blocks and restyling a store from a prompt.
RTL, Arabic-first theming
Storefront appearance is driven by design tokens rather than hand-written CSS per store, and right-to-left Arabic layout is the default case, not a retrofit.
AI sales agent
A conversational agent that answers product questions from the merchant's own catalogue and content using pgvector retrieval, and understands Algerian darija rather than only formal Arabic. It runs on storefront chat, on WhatsApp, and hands off into the call centre.
Chat-to-COD checkout
A customer can complete a cash-on-delivery order inside the conversation — the agent collects what the order needs and places it, without pushing the customer to a separate checkout page.
Deterministic order confirmation
The step that actually commits an order for dispatch is read by a deterministic closed-lexicon parser rather than by the model. Anything it cannot read unambiguously is escalated to a person.
Call-center CRM
A workspace for the merchant's staff to phone customers and confirm orders by hand, covering both the escalated cases and merchants who prefer to confirm every order by voice.
Courier routing
Roughly twelve courier and last-mile APIs sit behind one gateway registry, with a commune-level geographic rail that decides which carrier serves a given destination.
Installable apps with entitlements
The AI agent is packaged as an app a merchant installs on their store, gated by an entitlement system that decides what each tenant may use and denies access on any internal error rather than defaulting to allow.
Architecture
- Domain-driven hexagonal backend
- 37 bounded contexts over 163 Prisma models and 78 hand-authored SQL migrations. Domain logic sits behind ports rather than being expressed directly against the ORM, and each context owns its own model.
- Boundaries enforced by CI, not convention
- Dependency rules between contexts are declared as machine-checkable constraints and verified by dependency-cruiser on every build, so a cross-context import that breaks isolation fails CI instead of surviving code review.
- Event backbone on one PostgreSQL instance
- A transactional outbox writes the event in the same transaction as the state change; a SELECT … FOR UPDATE SKIP LOCKED relay drains it so several Cloud Run replicas can consume concurrently and crash-safely; idempotency keys make redelivery harmless. No separate broker.
- Tenant isolation at the query layer
- Every tenant-scoped query carries a mandatory tenant_id boundary, treated as a structural invariant of the data layer rather than a rule applied per feature. The entitlement check fails closed.
- Channel-neutral agent runtime
- One ReAct-style tool-calling runtime serves storefront chat, WhatsApp and the call-center handoff. Channels are adapters at the edge, so agent behaviour is defined once instead of once per surface.
- Cross-origin page builder
- The editor and the storefront preview run on different origins. The editor holds an immutable block tree and drives the live iframe across that boundary, which is what makes undo and redo a matter of holding previous trees rather than reversing mutations in place.
- Delivery on GCP
- Seven-app TypeScript monorepo deployed to Cloud Run against Cloud SQL, built by Cloud Build, with infrastructure defined in Terraform.
Hard problems
The parts that took the most thinking, and what I actually did about them.
The confirmation step moves money. A confirmed cash-on-delivery order dispatches a courier and commits the merchant to the cost of that trip, and customer replies arrive as informal Algerian darija in mixed script and inconsistent spelling. A language model that is usually right about a yes or a no is not good enough for that step.
What I did
The decision was taken out of the model entirely. A deterministic closed-lexicon parser reads the reply, and it is eval-gated to 100% of its golden-case suite before any merge lands. A reply outside the lexicon is ambiguous by definition and hard-escalates to a human in the call-center CRM, rather than being resolved by the model. The escalation path is treated as a normal outcome, not a failure.
How do you know a change to the agent has not quietly made it worse? Scoring an agent with another model puts a model in the scoring path, so the quality bar moves whenever the judge model does.
What I did
An evaluation harness with 102 golden cases across 7 suites gates every merge, with no model anywhere in the scoring path. Alongside it, money- and data-critical milestones went through adversarial multi-agent code review before deploy. That review caught three defects that would otherwise have shipped: a transient-error path that could wipe the catalog instead of retrying, a checksum computed before embedding that dropped data in transit, and a discount that could be applied past its configured cap.
Reliable messaging normally means adding a broker, which is another system to run, secure and pay for — and the platform runs on a single Postgres instance behind autoscaling Cloud Run replicas that appear and disappear mid-work.
What I did
The outbox pattern keeps the event and the state change in one transaction, so an event can never describe a write that did not happen. The SKIP LOCKED relay lets any number of replicas drain the same queue without blocking each other, and rows held by a replica that dies return to the pool when its transaction is rolled back. Idempotency keys handle the duplicate deliveries that this design accepts in exchange for never losing one.
Thirty-seven bounded contexts in one monorepo stop being bounded the moment a context reaches into another's internals, and that erosion is invisible in a normal diff review.
What I did
The dependency rules are written down as constraints a tool can check and run in CI on every build. Architecture that is only documented decays; architecture that fails the build does not.
Outcomes
- In production, in launch phase.
- Three defects caught before deploy by adversarial multi-agent review: a transient-error catalog wipe, a checksum-before-embed data-loss bug, and a discount-cap bypass.
- The confirmation parser passes 100% of its golden-case suite as a merge gate; 102 golden cases across 7 suites gate every merge, with no model in the scoring path.
Stack
- TypeScript
- Prisma
- PostgreSQL
- pgvector
- dependency-cruiser
- GCP Cloud Run
- Cloud SQL
- Cloud Build
- Terraform
This is commercial work, so there is no public repository or demo to link. I am happy to walk through the architecture, the evaluation harness, or any decision on this page in a call.