Mota — Delivery Plan¶
SDLC phase: Planning (Chapter 2.4)
Purpose: Stage-gated delivery with binary exit criteria. Replaces the CUT Gantt chart, which assumes a schedule that survives contact with reality.
1. Why stage gates, not a Gantt chart¶
A Gantt chart encodes the belief that the sequence of work is known and the durations are predictable. Neither is true for a solo builder validating an unproven market. What is controllable is what must be true before spending the next block of effort.
So each stage has:
- Exit criteria — binary conditions that must all be true to proceed.
- Kill criteria — conditions under which we stop, recorded in advance so the decision isn't made emotionally at the moment of disappointment.
- Time box — a limit, not an estimate. If the box expires without the criteria met, that is the answer.
2. Stage overview¶
graph LR
G0["Gate 0<br/>Validation<br/>2-3 weeks"] --> G1["Gate 1<br/>Core slice<br/>6 weeks"]
G1 --> G2["Gate 2<br/>Supply side<br/>6 weeks"]
G2 --> G3["Gate 3<br/>Monetisation<br/>8 weeks"]
G3 --> G4["Gate 4<br/>Scale or stop<br/>ongoing"]3. Gate 0 — Validation (time box: 3 weeks, zero code)¶
The purpose is to kill the idea cheaply if it deserves to die.
Activities¶
| # | Activity | Output |
|---|---|---|
| A1 | 15 owner interviews (WhatsApp car groups, in person at garages/petrol stations) | Evidence on: do they track service? do they know their odometer? what do they fear? |
| A2 | 5 garage owner interviews | Evidence on: do they track customers? would they pay for leads? what's their monthly marketing spend? |
| A3 | Landing page + WhatsApp broadcast in 5 car groups | Measure: clicks, phone-number signups |
| A4 | Competitive teardown: install and use MyAutoLog / Vehicle Maintenance Tracker for 3 weeks | Honest answer to "would a Zimbabwean use this instead?" |
| A5 | OTP feasibility test: transaction SMS/OTP delivery on Econet, NetOne, Telecel | Pass/fail — this gates the entire auth design |
| A6 | Interval data sourcing: find authoritative service schedules for the top 10 models | Assess effort to build the 40-model reference table |
Exit criteria — all must be true¶
| # | Criterion | Threshold |
|---|---|---|
| E0.1 | Owners report the problem unprompted | ≥10 of 15 describe losing service history or not knowing what's due, without leading |
| E0.2 | Owners want the artefact | ≥8 of 15 say a PDF service history would be useful at resale |
| E0.3 | Garages see the value | ≥3 of 5 say they would try a system that tells them which customers are due back |
| E0.4 | Garages will pay something | ≥2 of 5 state a specific amount they'd pay monthly, unprompted |
| E0.5 | Declared intent converts | ≥100 landing-page signups from 5 WhatsApp groups |
| E0.6 | OTP works | SMS/OTP delivered reliably on all three networks |
Kill criteria — any one stops the project¶
| # | Kill condition | Interpretation |
|---|---|---|
| K0.1 | <5 of 15 owners describe the problem unprompted | The pain is real to us and invisible to the market |
| K0.2 | <1 of 5 garages would pay anything | There is no revenue model; this becomes a charity project |
| K0.3 | <30 signups from 5 groups | Distribution is impossible without paid acquisition, which we can't afford |
| K0.4 | OTP is unreliable on any major network | The authentication design fails; the product cannot be used by a large segment |
If killed: return to 01-ranking.md and re-evaluate. The documented fallback is House Manager at a much lower ambition, or a pure garage-console tool sold as software rather than a consumer app.
4. Gate 1 — Core slice (time box: 6 weeks)¶
Build the smallest thing that delivers the core promise and produces the marketing artefact. No garage console. No price index.
Scope¶
| In | Out |
|---|---|
| Auth (phone OTP) | Multiple vehicles |
| Add vehicle (make/model/year/odometer, top 20 models) | Garage directory |
| Interval engine + due display | Price index |
| Service + fuel logging (offline-first) | Cost summary |
| Push + in-app reminder inbox | Billing |
| PDF service history + share | Console |
Exit criteria¶
| # | Criterion | Threshold |
|---|---|---|
| E1.1 | The interval engine is correct | All 10 test cases in 05-solution-design.md §4.5 pass; 100% unit coverage on the engine |
| E1.2 | Logging is genuinely fast | 8/10 first-time users log a service in <30s unaided |
| E1.3 | Offline works | Airplane-mode test: 3 writes sync exactly once |
| E1.4 | Real users activate | 100 activated users (1 vehicle + 1 event) |
| E1.5 | Retention floor | ≥40% of activations return within 7 days |
| E1.6 | The artefact is used | ≥25% of active users have generated or shared a PDF |
Kill criteria¶
| # | Kill condition |
|---|---|
| K1.1 | <100 activated users after 4 weeks live with active distribution effort |
| K1.2 | 7-day return rate <20% — the product is installed and forgotten |
| K1.3 | <10% PDF generation among active users — the growth artefact doesn't work |
If killed at Gate 1: the consumer proposition is wrong. Before abandoning, run one diagnostic: did users stop because logging is too slow, or because they never needed it? The answer decides whether to rebuild the input or the premise.
5. Gate 2 — Supply side (time box: 6 weeks)¶
Only build this once there is consumer demand to route.
Scope¶
| In | Out |
|---|---|
| Garage registration and listing | Payments |
| Lead inbox | Subscription billing |
| Booking request flow | Price index (deferred to Gate 3) |
| Lead status tracking | |
| Admin verification |
Exit criteria¶
| # | Criterion | Threshold |
|---|---|---|
| E2.1 | Garages onboard | 8 verified garages with complete listings |
| E2.2 | Leads flow | ≥30 leads generated in 4 weeks |
| E2.3 | Garages respond | ≥60% of leads acknowledged within 24h |
| E2.4 | Leads convert | ≥30% of leads marked booked |
| E2.5 | Garages return to the console | ≥5 of 8 garages checked their inbox in the last 7 days |
| E2.6 | Consumers use the directory | ≥20% of active users viewed a garage at least once |
Kill criteria¶
| # | Kill condition | Interpretation |
|---|---|---|
| K2.1 | <4 garages stay active after 4 weeks | The console doesn't fit their workflow |
| K2.2 | <20% lead conversion | The lead quality is too low to charge for |
| K2.3 | <3 garages check the inbox weekly | Notification and habit design failed; the lead dies in the inbox |
If killed at Gate 2: pivot to a garage-paid-only product — a lightweight customer-reminder tool the garage uses to message its own existing customers, with no consumer app at all. This is a smaller business but a real one. See 01-ranking.md §5.
6. Gate 3 — Monetisation (time box: 8 weeks)¶
Scope¶
| In | Out |
|---|---|
| Paynow integration | Marketplace checkout |
| Garage subscription billing | Insurance commissions |
| Lead fees + invoicing | Fleet features |
| Cash payment recording | |
| Parts price index (garage-submitted) | |
| Sponsored placement |
Exit criteria¶
| # | Criterion | Threshold |
|---|---|---|
| E3.1 | Garages pay | 5 paying garages (subscription or lead fees) |
| E3.2 | Revenue is real | US$300 MRR for 2 consecutive months |
| E3.3 | Churn is survivable | Monthly garage churn <5% |
| E3.4 | The price index is used | ≥1.5 price-index views per active user per month |
| E3.5 | Billing is operationally clean | ≤2 reconciliation discrepancies per month |
Kill criteria¶
| # | Kill condition | Interpretation |
|---|---|---|
| K3.1 | <2 garages convert to paying after 8 weeks of offering | The supply side won't pay; there is no business model |
| K3.2 | MRR <US$150 at 8 weeks post-billing | Revenue exists but is too small to justify continued investment |
| K3.3 | Churn >10%/month | The value isn't repeating; the model is a treadmill |
If killed at Gate 3: the product has users but no business. Options, in order of preference: (a) sell the audience to a parts retailer as a sponsorship property, (b) pivot to a single-garage-chain B2B deal, © wind down and publish the interval dataset as a free resource, which has independent value.
7. Gate 4 — Scale or stop (ongoing)¶
| Condition | Action |
|---|---|
| MRR >US$600 and churn <5% | Invest in expansion: second city, or the household module as a retention play |
| MRR US$300–600, stable | Maintain as a profitable side business; do not add scope |
| MRR <US$300 after 6 months of monetisation | Stop adding features. Either sell the asset or run it as-is at minimal cost |
Explicitly not planned: raising investment. The realistic ceiling (US$150–250k ARR) does not support a venture return, and pretending otherwise would corrupt every decision toward growth over profitability.
8. Timeline view¶
Not a Gantt — a dependency view, because the ordering is what matters.
Week 0-3 Gate 0: interviews, landing page, OTP test [no code]
Week 4-9 Gate 1: core slice build [code]
Week 10-13 Gate 1: live with real users, measure retention
Week 14-19 Gate 2: garage console + onboarding
Week 20-23 Gate 2: operate, measure lead quality
Week 24-31 Gate 3: billing, price index, monetisation
Week 32+ Gate 4: decide scale or stop
Total to first revenue: ~7 months. That is the honest number, and it assumes no major setbacks. Stated as a dependency sequence, not a deadline.
9. Effort allocation (per stage)¶
| Stage | Build | Ops/sales | Research | Notes |
|---|---|---|---|---|
| Gate 0 | 0% | 40% | 60% | Interviews and landing page only |
| Gate 1 | 80% | 10% | 10% | Mostly code |
| Gate 2 | 60% | 30% | 10% | Garage onboarding is the hidden cost |
| Gate 3 | 50% | 40% | 10% | Monetisation is a sales problem |
| Gate 4 | 30% | 50% | 20% | Running a business |
The pattern to internalise: build effort falls and sales effort rises at every gate. A founder who keeps building past Gate 2 is avoiding the real work.
10. Definition of done (per feature)¶
A feature is done when all of the following are true. Partial completion is not a state.
- Meets its FR acceptance criterion.
- Passes the relevant NFR targets on the reference low-end device.
- Has automated tests for business logic (≥70% coverage on that module).
- Works offline, or explicitly declares itself online-only in the UI.
- Has a loading, empty, error, and offline state — not just the happy path.
- Is instrumented with an analytics event (we cannot manage what we don't measure).
- Reviewed against the PII boundary — does it expose anything it shouldn't?