Product Roadmap · Platform 1.0
A marketplace platform combining commerce, live consultations, and automated fulfilment in one product.
This roadmap defines what ships, in what order, and why — without overbuilding Phase 1 or underestimating the hard parts.
Scope discipline — the argument up front
A word on scope discipline. You are hiring a team now. That means Phase 1 takes longer than you expect — not because the team is slow, but because onboarding, architecture decisions, and the first supplier integration will each consume weeks you haven't budgeted for. This roadmap is scoped accordingly. Phase 1 is large, but every feature in it is load-bearing — pull one out and a revenue stream breaks. Phase 2 onwards is where we earn the right to get clever.
Every roadmap we write contains a paragraph like this one. A plan that only lists features is a wish list; a plan that states its own risks is something you can hold us to.
Saying no, in writing
Why the subscription tier is Phase 2, not Phase 1. I know it's a revenue stream and you want it in. But it needs the credit wallet, priority queue logic in the matching algorithm, and delivery-tier differentiation — all of which depend on the base transaction flows working flawlessly first. Launching it on top of a shaky Phase 1 means subscribers churn before month two. Ship the core. Prove it works. Then sell the upgrade.
This is the section clients remember. Our product owner argued the founder out of a revenue stream — in the document, on the record, with the reasoning visible. That's what a roadmap is for.
Phasing
PhaseDeliveryWhat it achievesDependency
Phase 1Core platform — web, mobile, adminCommerce with standard and gated checkout. Two mobile apps. Live consultations. Automated fulfilment. Admin back-office. Matching algorithm. Payments.Existing storefront stays live until cutover.
Phase 2Engagement + monetisationSubscription system with credit wallet. AI-assisted session notes from transcription. Advanced admin: analytics, CMS, dispute resolution. Notification campaigns.Phase 1 in production. Real usage data informs priorities.
Phase 3Intelligence + automationML-powered ranking with behavioural signals. Automated credential verification. Predictive demand signals. Search with ML recommendations.6+ months of real usage data from Phases 1–2.
Phase 4Scale + ecosystemPublic partner API. Multi-language. White-label fulfilment for partners. Advanced revenue analytics.Platform at scale. Phase 3 intelligence proven.
Parity vs net-new
Before estimating anything, we separate what already exists from what has never been built. Rebuilds carry known risk; net-new carries unknown risk. Mixing them in one estimate is how timelines die.
✦ PARITY — MIGRATED- Catalogue with search & filtering
- Cart & standard checkout
- Payment processing
- Order tracking & status emails
- Accounts & order history
- Shipping integrations
★ NET NEW — NEVER EXISTED- Gated checkout with expert notification
- Two mobile apps (Flutter)
- Live video / audio / chat sessions
- E-signature approval flow
- Automated fulfilment pipeline
- Multi-supplier sync engine
- Ranking & matching algorithm
- Comprehensive admin panel
User journeys
Every critical path through the platform is mapped as a flow with actors, decision points, and edge cases — including the unhappy ones. These are what engineering scopes sprints from. The original document contains ten; one is shown here.
01
Gated purchase → existing expert
Happy path — the customer has worked with this expert before. The system auto-routes the approval request.
CUSTOMERAdds a restricted item to cart
SYSTEMDetects the restriction flag → blocks checkout → shows the approval gate
SYSTEMChecks history → finds existing expert → offers to notify themIf multiple, customer picks. Highest relationship score first.
SYSTEMSends push + email with a pre-filled form. Order status → “Awaiting approval”
DECISIONDoes the expert approve?
APPROVESReviews → adjusts if needed → e-signs → document generated → checkout unlocked
DECLINESDeclines with reason → customer notified → offered the consultation path instead
CUSTOMERReturns to cart → completes checkout
SYSTEMOrder + signed approval → fulfilment API → tracking injected → delivered → saved to history
Ten journeys like this one, covering four purchase paths, three session types, and three lifecycle flows — each with its failure branches written down. Engineering estimates against these, not against a feature list.
Recommended stack, with reasons
Opinionated choices, each with the reasoning attached, and the client's CTO holding the final call. A recommendation you can't argue with isn't a recommendation — it's a decree.
Next.jsSEO matters for commerce. SSR for catalogue pages. Same ecosystem as the admin panel.
FlutterOne codebase, two platforms. Strong for consultation-heavy UI. Dart is a hiring trade-off — plan for it.
Node.js (NestJS)TypeScript end to end. Structure for a team that's still forming. Suited to real-time.
PostgreSQL + RedisRelational where consistency matters; cache where latency is felt.
Elasticsearch60K items with typo tolerance and faceted filtering. Full-text search won't cut it at this size.
AWS + GitHub ActionsMature, well-documented, hireable expertise. Simple pipelines for a forming team.
The parking lot
Real commitments, not rejected ideas — each waiting on infrastructure or data that doesn't exist yet. Writing them down stops them from being re-litigated every sprint.
Insurance integrationRequires Phase 2 analytics + partner API
Automated refillsRequires Phase 2 tracking + purchase history
Wearable integrationRequires Phase 2 timeline feature
International expansionRequires Phase 4 multi-language + legal framework
Supplier scoringRequires 6+ months multi-supplier data
Education hubRequires Phase 2 CMS + content strategy
