NexaMart, taken apart

NexaMart is the store I show prospects before we talk about scope: a complete, working e-commerce platform where the AI answers customers and the back office runs itself. This is the teardown — what’s in it, why each piece is there, and where the honest trade-offs live.

Why build a demo store at all

Because “AI-powered” is unfalsifiable in a slide deck. Every agency claims it; almost none can hand you the keys to a system where it already works. NexaMart exists so the first conversation can skip “can you actually build this?” and start at “which parts does my store need?” A demo you can click beats a promise you can’t.

The layers

Storefront — Next.js 15, server-rendered. Product pages render on the server, so they’re fast on mediocre connections and fully indexable. The performance target was strict: under three seconds on a 4G connection — because a demo that lags would refute its own pitch, and because in commerce, speed is conversion.

Data — Supabase (Postgres). Catalog, orders, sessions, and the vector store for retrieval all live in one managed Postgres. One database doing four jobs means less infrastructure to babysit and realtime inventory comes almost free. The pgvector extension carries the chatbot’s memory — no separate vector database bill.

Payments — Midtrans. Real gateway, real payment methods Indonesian shoppers actually use (virtual accounts, e-wallets, QRIS). A checkout that ends at a fake “success” screen wouldn’t prove anything; wiring a real gateway is what makes the demo honest. Stripe slots in for international builds.

The AI layer — chatbot + RAG. The customer-service assistant is trained on the full catalog and FAQ, with retrieval-augmented generation grounding every answer in live data. Ask it about stock, sizing, returns, or “which of these two serums for oily skin?” and the answer comes from the database, not the model’s imagination. Coverage is 24/7, and the rare hard case escalates to a human with conversation context attached. There’s also a quieter agent watching request patterns for anomalies — a security monitor, not a feature customers see.

Operations — five n8n workflows. Order confirmations, low-stock alerts, customer follow-up sequences, CRM sync, and daily recaps — all running with nobody at the desk. Self-hosted n8n, so the automation bill is a small VPS, not a per-task subscription that grows with order volume.

The numbers it runs at

• <3s page loads on 4G
• 24/7 AI coverage of routine support
• 100% of chatbot answers grounded in the live catalog
• 5 back-office workflows running unattended

Measured on the system, not projected on a slide — that’s the entire point of it.

What I’d do differently today

A teardown that hides the regrets isn’t a teardown.

• I’d design the escalation path first, not last. Handing a conversation from bot to human — with context intact — turned out to be the detail prospects care about most, and it was retrofitted rather than designed in from day one.
• I’d cache retrieval harder. The same twenty questions dominate real traffic; caching grounded answers for hot queries cuts API spend meaningfully at scale. NexaMart does this now, but it should have from the first commit.
• I’d keep the schema more boring. An early experiment with a clever product-variant model cost more migration pain than it saved. Boring schemas age better; the intelligence belongs in the retrieval layer, not the tables.

What generalizes to your store

NexaMart is a demonstration, but nothing in it is demo-ware. The same architecture — SSR storefront, one Postgres doing catalog + vectors, a RAG-grounded chatbot, self-hosted automation — is what I deploy for client builds, scoped to the pieces each business actually needs. The full case study, including why each technology earned its place in business terms, is on the NexaMart case study page.

Want to poke at it yourself? The live demo is available on request — start a conversation and I’ll walk you through it.