Mota — Risk Register¶
SDLC phase: Planning (Chapter 2.3)
Purpose: Every material risk, with a named owner, an observable trigger, and a concrete mitigation.
Scoring: Likelihood (L) and Impact (I) each 1–5. Score = L × I. Anything ≥12 is a critical risk requiring active management.
1. The register¶
Market risks¶
| ID | Risk | L | I | Score | Trigger to watch | Mitigation | Owner |
|---|---|---|---|---|---|---|---|
| R-01 | Consumers won't install. Distribution is the binding constraint, not code. | 4 | 5 | 20 | <30 signups from 5 WhatsApp groups at Gate 0 | Garage-led acquisition (garages onboard their own customers); the PDF is a shareable marketing artefact | Founder |
| R-02 | Garages won't pay. Micro-businesses with thin margins and no software habit. | 4 | 5 | 20 | <2 of 5 garages name a price at Gate 0; <2 convert at Gate 3 | Free tier + zero-risk lead pricing (pay only on booked leads); prove value for 6 months before invoicing | Founder |
| R-03 | White space means no market. No local competitor may exist because nobody found a business here. | 3 | 5 | 15 | Gate 0 interviews produce politeness, not urgency | Treat Gate 0 as a genuine kill test, not a formality. Kill at 300 signups, not 3,000 | Founder |
| R-04 | A funded or incumbent player enters. | 3 | 4 | 12 | Job postings, app store listings, partnership announcements | Defensibility is garage relationships and the interval dataset, not features; accelerate the supply side | Founder |
| R-04a | ZWPRICE adds an automotive service category. It already runs a supplier-paid RFQ marketplace with 26 supplier brands, and its published examples include service requests ("a plumber in Chinhoyi this week"). Adding "a mechanic in Harare this week" is a prompt change. | 3 | 4 | 12 | New categories on zwprice.com/stores; automotive keywords in their example prompts |
Compete on the record, not the lead. ZWPRICE has no vehicle history, no intervals, and no reason for repeat visits. Accelerate the PDF and timeline so the record is genuinely valuable before a competitor can route a quote. Consider partnership: feed service requests into Mota's garage network | Founder |
| R-04b | ZiMINDEX extends into ZINARA/insurance renewal pricing. It already indexes statutory fees as priced line items with S.I. references. ZINARA and insurance are household costs of the same type. | 2 | 4 | 8 | New categories on zimindex.co.zw/products; any vehicle-related page |
Defend by making the record the hook: a user with three years of history won't switch to a cost index for a renewal reminder. Do not compete on cost-data breadth. Consider partnership for macro data | Founder |
| R-05 | Fleet growth stalls on import restrictions or currency policy. | 2 | 3 | 6 | ZINARA monthly registrations fall below 6,000 | Focus on the existing fleet and resale-history value | Founder |
Product risks¶
| ID | Risk | L | I | Score | Trigger | Mitigation | Owner |
|---|---|---|---|---|---|---|---|
| R-06 | Logging is too much effort. Users install, log once, never return. | 4 | 5 | 20 | 7-day return rate <20% at Gate 1 | 28-second logging requirement; chips not free text; aggressive pre-fill; UAT gates the release | Builder |
| R-07 | Reminders are wrong (bad reference data, stale odometer), destroying trust. | 3 | 5 | 15 | Reminder acknowledge rate <25%; support tickets about wrong dates | Show reasoning on every reminder; confidence levels; user override wins; recompute on reference changes | Builder |
| R-08 | Push notifications never arrive on cheap Android (battery managers, denied permissions). | 4 | 4 | 16 | <95% delivery rate measured server-side | Server-side scheduled push as primary; in-app inbox as the durable fallback; WhatsApp deep-link option | Builder |
| R-09 | The PDF is not valued. The growth artefact doesn't get shared. | 3 | 4 | 12 | <10% of active users export a PDF at Gate 1 | Test the PDF's resale value in Gate 0 interviews; if unvalued, replace with a simpler share card and remove it from the growth thesis | Founder |
| R-10 | Price index data goes stale, making the product look wrong. | 4 | 4 | 16 | >40% of price entries older than 90 days | Every price carries as_of; stale badge mandatory; prompt garages monthly to refresh; hide rather than show stale data |
Founder |
| R-11 | Scope creep — building the household module, marketplace, or iOS before the core works. | 4 | 4 | 16 | Any work on an item in the out-of-scope table | The out-of-scope table is contractual; gate reviews enforce it | Founder |
Technical risks¶
| ID | Risk | L | I | Score | Trigger | Mitigation | Owner |
|---|---|---|---|---|---|---|---|
| R-12 | Sync duplicates or loses records. | 3 | 5 | 15 | Any duplicate record reported by a user | client_id uniqueness enforced at DB level; replay = no-op; integration test with forced mid-sync crash |
Builder |
| R-13 | Data isolation failure (user A sees user B's data; a garage sees a phone number it shouldn't). | 2 | 5 | 10 | RLS test suite failure | RLS on every table; PII released only on explicit booking; suite is a hard release blocker | Builder |
| R-14 | CDPA non-compliance (unregistered data controller, cross-border transfer without basis). | 3 | 5 | 15 | Registration not complete before launch | Register before public launch; minimise PII; legal review of hosting region; documented deletion path | Founder |
| R-15 | OTP delivery unreliable on one or more networks. | 3 | 4 | 12 | Gate 0 network test fails | Test all three networks at Gate 0; if unreliable, fall back to WhatsApp-based verification or email | Builder |
| R-16 | Vendor lock-in (Supabase pricing change, Expo policy change). | 2 | 3 | 6 | Pricing announcements | Standard Postgres underneath; data export runs monthly; no proprietary-only features on the critical path | Builder |
| R-17 | Payment integration friction (Paynow onboarding, merchant requirements). | 3 | 3 | 9 | Merchant application stalled | Start the application at Gate 2, not Gate 3; record cash payments as a first-class fallback | Founder |
Operational risks¶
| ID | Risk | L | I | Score | Trigger | Mitigation | Owner |
|---|---|---|---|---|---|---|---|
| R-18 | Founder capacity. One person cannot build, sell, support, and operate. | 4 | 4 | 16 | Slipped gates without a quality decline | Ruthless scope discipline; stage gates force sequencing; task automation; accept slower growth | Founder |
| R-19 | Garage onboarding doesn't scale. Every garage needs a human. | 4 | 3 | 12 | >5 hours/week on onboarding at 15 garages | Self-serve onboarding video; referral-based onboarding; part-time field rep funded from revenue at 25 garages | Founder |
| R-20 | Support burden exceeds capacity at a few hundred users. | 3 | 3 | 9 | >15 tickets/week | Canned replies; in-app FAQ; screen recordings for common questions; measure ticket-per-user ratio | Founder |
| R-21 | Backup restore fails when needed. | 2 | 5 | 10 | Quarterly drill failure | Quarterly restore drill to staging with verification steps; an untested backup is a hope | Builder |
Commercial risks¶
| ID | Risk | L | I | Score | Trigger | Mitigation | Owner |
|---|---|---|---|---|---|---|---|
| R-22 | Churn too high for the subscription model. | 3 | 4 | 12 | >10%/month | Annual prepay option; measure at Gate 2 before building billing; lead-fees-only fallback | Founder |
| R-23 | Currency instability disrupts pricing. | 3 | 3 | 9 | Rapid ZiG movement | All pricing and accounting in USD; avoid ZiG-denominated contracts | Founder |
| R-24 | Lead attribution disputes — garage claims a lead wasn't real. | 3 | 3 | 9 | >1 dispute/month | Bill only on booked; timestamped status changes; no charge for lost/no_response |
Founder |
| R-25 | Cash collection leakage — cash payments recorded incorrectly or not at all. | 3 | 3 | 9 | Reconciliation discrepancies | Cash is an explicit state with an audit trail and a receipt; weekly reconciliation | Founder |
2. The ones that actually matter¶
Ranked by score, then by how much control we have over them.
| Rank | ID | Risk | Why it's top |
|---|---|---|---|
| 1 | R-01 | Consumers won't install | Highest impact, and entirely outside our control until we try |
| 1 | R-02 | Garages won't pay | Same. Together these two decide whether a business exists |
| 3 | R-06 | Logging is too much effort | The one product risk we fully control, and the easiest to get wrong |
| 4 | R-04a | ZWPRICE adds automotive | Newly discovered. Cuts the revenue line before we have it — but not the moat |
| 5 | R-08 | Push doesn't arrive | Technical, invisible until launch, and it breaks the retention mechanism |
| 5 | R-10 | Price data goes stale | The price index is a trust product; stale data is worse than no data |
| 5 | R-18 | Founder capacity | The risk that makes every other mitigation harder to execute |
| 8 | R-04b | ZiMINDEX indexes renewals | Lower probability, but it would take the most reliable reminder trigger |
R-01 and R-02 are not "managed" by clever engineering. They're answered by Gate 0, which exists precisely so we find out cheaply.
On R-04a specifically. This risk is unusual because the threat and the validation come from the same company. ZWPRICE proves the supplier-paid, buyer-free RFQ model works in Zimbabwe — which de-risks our business model considerably. It also proves someone else already has the supplier relationships, the payments plumbing, and the brand recognition a lead marketplace needs.
The distinction that decides whether this is a threat or an irrelevance: ZWPRICE captures transactions, Mota captures relationships. A quote marketplace has no reason for a buyer to return in eight months. A service record does. If the PDF and the timeline work, R-04a is a manageable annoyance. If they don't, we're a worse ZWPRICE with a car-shaped logo.
That makes R-04a a useful forcing function: it converts "make the record genuinely valuable" from a nice-to-have into the primary strategic requirement.
3. Risk review cadence¶
| Cadence | Activity |
|---|---|
| Weekly | Review any risk whose trigger has fired |
| At each gate | Re-score all critical risks; retire resolved ones; add newly discovered ones |
| Quarterly | Full re-score; verify that every mitigation is actually in place, not just written down |
The gate review is the important one. A risk register that is written once and never revisited is documentation theatre. The gate reviews are where it earns its keep.
4. Risks we are explicitly accepting¶
Being clear about what we're not mitigating, and why.
| Risk | Why accepted |
|---|---|
| No SLA for consumers | A free product cannot promise uptime. Stated in the terms, not hidden. |
| Reminders may be wrong if data is wrong | The product is advisory, not a safety system. This is stated in the UI and the PDF disclaimer. |
| No iOS for 12+ months | Accepted market loss to protect build capacity. |
| Garage data is self-reported and unverified | Verification of a garage's competence is a different business. We verify existence and contactability, not quality. |
| Small revenue ceiling | Accepted. This is designed to be a profitable small business, not a venture outcome. |
| No 24/7 support | Accepted at this scale. Revisit at US$2,000 MRR. |