Four sections: backlog, methodology, stack, and what we need to start.
Extracted from existing documents — Fabrice's spec, the kickoff, the copils, the solution brief. Organized by business milestones. To be validated together, not presented as final.
Sizing and sprint assignment are not done yet — that requires a working session together.
A backlog tracks what needs to be built. Sprints deliver it in 3-week cycles. The backlog is the list. The sprint is how items from that list become working software.
Each of the 45 items follows this structure. Size (S/M/L/XL) determines how much sprint capacity it takes. The success criteria is how we know it's done — a real scenario on real data, not a checklist.
Every sprint has a deadline, a scoped deliverable, and a decision at the end.
The team works on the agreed scope.
Deliverable is functional. Quick check with the sprint sponsor. First real-world testing begins.
Feedback integrated. Testing on real data. The sprint ends with a 30-minute gate review.
If something doesn't fit, we cut scope — never extend the deadline. "What's the smallest version that creates real value?"
Before each sprint, a card states what will be delivered and why. The sprint sponsor confirms before work begins.
Stakeholders see real work on real data and make a Go / Iterate / Stop decision at every gate.
The sprint sponsor reviews and confirms the card before work begins. This is the contract for the sprint — what we commit to delivering and demoing at the gate.
30-minute demo on real data. Sprint sponsors make the decision.
Tactical. Demo + decision. Sprint sponsor attends. Go / Iterate / Stop. Confirm the next sprint.
Strategic. Reprioritize, resolve cross-stream dependencies, course-correct. Full leadership.
Zai is not a platform — it's a full-service offering: design, production, and delivery. The platform is the tech layer that powers it. Credits-based, design-led, white-label per client. The stack choices follow from that.
| Layer | Decision | vs. Spec |
|---|---|---|
| Frontend | Next.js + TypeScript + Tailwind CSS | Agreed |
| Backend | Payload CMS 3.0 + custom logic | Different Not Medusa |
| Database | Supabase (PostgreSQL + RLS + pgvector) | Agreed |
| Auth | Auth0 (Organizations for multi-tenant) | Added |
| Payments | Credits only for MVP → Stripe + CMI later | Deferred |
| Storage | Cloudflare R2 + Image Resizing | Different Not Cloudinary |
| Hosting | Railway (app) + Cloudflare (CDN) | Different Not Vercel |
| Monitoring | Sentry (errors) + PostHog (analytics + flags) | Agreed + PostHog |
| Project Mgmt | Linear (sprints, backlog, stakeholder visibility) | Added |
| Design System | Tailwind + custom Zai component library | Added Missing from spec |
One TypeScript codebase. One deployment. Payload handles the e-commerce plumbing (catalog, admin panel, media, multi-tenant) without constraining the model. Credits, engagement, and intelligence are custom logic alongside it. Python microservice added when AI features arrive at Milestone 5.
Both are commerce frameworks built for standard e-commerce: products, carts, orders, card payments. Zai's credits system, multi-tenant white-labeling, engagement workflows, simulation renders, and cross-client intelligence don't map to that model. Payload gives the catalog and admin plumbing without imposing a commerce opinion on the rest.
Before building starts: a focused session together to size the backlog items and define what goes into Sprint 1.
Sprint 0 + Sprint 1 = ~4 weeks to first delivery.
SGTM's branded store, live, with credits, handling real orders. Zai handles the rest — design, production, delivery.