7.7 KiB
04 — Roadmap
Assumes a core team of ~4–6 (2–3 app devs, 1–2 backend, 1 QA/support who knows Classic). Durations stretch/shrink with team size; the sequence and exit criteria are the point. Dates below start from project kickoff.
⚡ Staging update (founder call, 2026-07-09 — see D14)
Build the local product first; add the cloud tier afterwards. Phase 1 ships a fully working local-only system: POS counters (SQLite buffer) + the existing in-store Oracle 12c as store master (D12), offline licensing as Classic does today, local + exported backups. The cloud tier (Postgres, sync agent, licensing service, auto-update channel) is stood up as its own workstream and switched on per store afterwards.
The one non-negotiable that makes this safe: even in local-only v1, every write uses client-generated UUIDs and also writes its outbox row (dormant, drained by nothing). Cloud enablement then = install sync agent + drain backlog — a switch-on, not a data migration. Skip this and "add cloud later" becomes a second migration project.
Deferred until the cloud tier exists (moves with it, not with the phase numbers below): owner mobile app, Purchase Inbox, WhatsApp e-bills/reminders, UPI webhook auto-confirm, central backups, silent auto-update, HQ fleet dashboards (the HQ ops console starts earlier — see the HQ Ops workstream below), e-Invoice via GSP (can interim-run through a manual portal flow if needed before then).
Phase 0 — Prove the risky bits (4–6 weeks)
Goal: kill the project-killers before writing product code.
- Sync spike: two POS clients + cloud; bills offline on both, kill the network, sync, verify stock & numbering correctness. Evaluate PowerSync/ElectricSQL vs custom outbox.
- Hardware spike: Electron app printing ESC/POS (2"/3"), cash-drawer kick, scanner input, one weighing scale. This decides Electron vs Tauri (vs Flutter).
- Billing engine v0: pure-TS pricing/GST/rounding engine with golden tests derived from real Classic bills (grab 100 real bills, new engine must reproduce them to the paisa).
- Classic data audit: map the Oracle schema; export 2–3 real customer datasets; identify the ugly bits (they exist).
- UX prototype: clickable billing screen; put it in front of 3 real cashiers; time them.
- Founder decisions locked: 06-DECISIONS items D1–D5.
Exit criteria: sync demo survives a pulled cable; printed bill from Electron; engine reproduces Classic bills; stack decision written down.
Phase 1 — MVP: one store bills on it all day (3–4 months)
Scope (all "M" items in 01-SCOPE.md): masters + import, POS billing offline with print, payments (cash/UPI-static/card/khata), returns, purchases (manual), stock, day-end, party ledgers, GST invoice formats, core reports, users/roles/audit, licensing skeleton, auto-update, cloud backup, Classic migration tool alpha.
Pilot: 3–5 friendly existing customers (one mini, one medium, one busy counter) run Next in parallel with Classic for 2+ weeks, then cut over. Their cashiers' stopwatch beats our opinions.
Exit criteria: a real store bills a full day with zero Classic fallback; migration tool moves a real customer with verification report green; counter timing ≤ Classic.
Phase 2 — Compliance depth + counter polish (2–3 months)
GSTR-1/3B exports, e-Invoice + e-Way via GSP, Tally export, schemes/offers, UPI dynamic QR with auto-confirm, WhatsApp e-bills & khata reminders, multi-counter + Store Hub LAN sync, weighing-scale barcodes, salesman tracking, accounting vouchers/day book, multi-language UI (top 2 languages), onboarding wizard.
Exit criteria: a supermarket with 3+ counters runs through GST filing month entirely on Next; dealer can onboard a new store without us on the call.
Phase 3 — The differentiators (2–3 months)
Purchase Inbox (email/upload → AI parse → review queue → posted purchase, with item-matching memory), GSTR-2B reconciliation, owner mobile app v1, stock-take mobile scanning, dashboards & scheduled digests, loyalty, PO/GRN flow, expiry dashboards.
Exit criteria: ≥50% of pilot stores' purchase lines flow through the Inbox; owner app DAU > 60% of owners.
Phase 4 — Scale-out (ongoing)
Multi-store HO console, central pricing, inter-store transfers, consolidated reporting, Enterprise onboarding for chains, API access, customer display/promo engine, offer broadcasts, then evaluate: Android POS terminals, ONDC/e-commerce bridges, restaurant mode.
Migration & go-to-market thread (runs across all phases)
- Phase 1: migration tool + parallel-run playbook; migrate the 5 pilots.
- Phase 2: dealer training kit, migration-week checklist, Classic price-lock offer; migrate the top 20% (largest/most engaged) of the base.
- Phase 3: mass migration waves by region with dealer incentives; Classic enters maintenance-only mode (security/GST patches).
- Phase 4: Classic sunset date announced — only after >80% of active base has moved and Next's support ticket rate is demonstrably lower.
HQ Ops workstream — the internal console (parallel track)
New workstream (founder call, 2026-07-09 — D15 ✅ RESOLVED, 06-DECISIONS.md):
build apps/hq per 14-SPEC-HQ-CONSOLE.md — the
doc-11 HQ Console started early, aimed at the
current ~300 Classic clients (quotations/proforma/invoices in minutes, recurring
billing + reminders, AMC, per-client AWS cost, interaction log), replacing the internal
Oracle APEX app entirely. Runs in parallel with Phases 0–4, staffed lightly (~1 dev),
reusing the tested foundation packages (billing-engine, domain, ui, auth patterns) — it
doesn't compete with the product track for people.
Reconciling with the staging note above: this does not change D14 — the store product stays local. The HQ Console is vendor-side cloud, which doc 11 already prescribes. The fleet half (fleet dashboards, migration tracker UI, remote support) still waits for the cloud tier as deferred above — only the ops/billing slice starts now, on the same client registry the fleet features will later share.
| Phase | Ships (condensed from spec §6) |
|---|---|
| HQ-1 | Skeleton + auth/audit; client registry (APEX import + verification); module catalog + module_price_book; client_module tracking; quotation/proforma/invoice + letterhead PDF + Gmail send + payment recording |
| HQ-2 | Recurring plans + reminder engine (auto + manual queue); AMC contracts; money dashboard + follow-ups; interaction/visit/call/training log |
| HQ-3 | AWS usage & cost per client + margin view; reports (dues aging, module revenue, client profitability); Client 360° polish |
| HQ-4 | Convergence with doc-11 fleet features once SiMS Next ships — migration tracker, fleet dashboards, support queue on the same registry, no rebuild |
Standing risks to watch
| Risk | Mitigation |
|---|---|
| Sync correctness bugs erode trust fast | Phase-0 spike, property-based tests, sync health dashboard, replayable op logs |
| New POS feels slower than Classic to veteran cashiers | Keyboard-first + "Classic keys" preset; measure per-bill timings in pilots; don't ship until ≤ Classic |
| GST rule changes mid-build | Rates/thresholds as dated config; GSP handles portal churn |
| Migration data horror stories | Verification report (counts, balances, stock match) per migration; parallel-run period mandatory |
| Scope creep from Classic parity ("but it had X") | Parity backlog triaged against usage data from Classic telemetry/pilots, not memory |
| Team spread across 4 surfaces | Phase 1 ships POS + minimal back office only; owner app waits for Phase 3 |