Mota — Feasibility & Alternatives¶
SDLC phase: Planning (Chapter 2)
Purpose: Determine whether this is possible under our constraints, and whether there's a cheaper path to the same outcome.
1. Technical feasibility¶
1.1 Capability assessment¶
| Requirement | Feasible? | How | Risk |
|---|---|---|---|
| Service interval calculation per make/model | Yes | Static reference table seeded with the top 40 models in the Zim fleet; user can override | Reference data must be built manually. Medium effort, low risk. |
| Deadline reminders | Yes | Local scheduled notifications + server-side fallback | Android battery managers aggressively kill background jobs (see §1.3) |
| Offline-first logging | Yes | Local SQLite/WatermelonDB write queue, idempotent sync | Well-trodden pattern; moderate complexity |
| PDF service history | Yes | Client-side or server-side PDF generation | Trivial |
| Fuel consumption (km/l) | Yes | Delta calculation between fill-ups; requires odometer or litres consistency | Data quality depends on user discipline |
| Garage directory + lead handoff | Yes | Simple CRUD + deep links to WhatsApp/phone | Trivial |
| Parts price index | Yes | Garage-supplied price entries, normalised by part category | Requires garage cooperation — an ops problem, not a technical one |
| Payments (garage billing) | Yes | Paynow (EcoCash, OneMoney, cards) | Certification and reconciliation effort |
| Vehicle data by registration | No (v1) | ZINARA does not expose a public API | Do not build a feature that depends on it |
Conclusion: every v1 feature is technically achievable by 1–2 builders with standard web/mobile technology. There is no research risk. This is the strongest argument for the idea: technical feasibility is not the constraint.
1.2 Stack recommendation¶
| Layer | Choice | Rationale |
|---|---|---|
| Client | React Native (Expo) or PWA + Capacitor | One codebase; Expo gives reliable push and store distribution. PWA is lighter but push and background sync are unreliable on cheap Android. Recommend Expo — push reliability is worth the bundle cost. |
| Local storage | SQLite (expo-sqlite) | True offline-first, not a cache. |
| Backend | Supabase (Postgres + Auth + Storage + RLS) | Removes 80% of backend work. RLS gives per-user isolation without a custom auth layer. |
| Hosting | Supabase region closest to ZA/EU | Cross-border data transfer must be reviewed under CDPA — see open question Q3. |
Client-side (expo-print) |
No server round-trip; works offline. | |
| Payments | Paynow | EcoCash + OneMoney + cards in one integration; 1.5% + $0.50. |
| Notifications | Expo Push + WhatsApp deep links | Push is unreliable on cheap Android; WhatsApp is the fallback that always works. |
| Analytics | PostHog (self-hosted later) or Supabase events table | Keep cost at zero initially; own the data. |
Deliberate rejections:
- No microservices. One backend. Solo maintenance budget.
- No native iOS in v1. iOS share among this demographic doesn't justify the build and review cost. PWA covers the small overlap.
- No custom auth. Supabase Auth with phone OTP. Building auth is a cost with no differentiation.
- No ML recommendation engine in v1. A lookup table beats a model here — the domain is deterministic.
1.3 The specific technical risks¶
| Risk | Detail | Mitigation |
|---|---|---|
| Android background task killing | Cheap Androids (Tecno, Itel, Infinix) use aggressive battery managers that kill scheduled jobs. Local notifications may not fire. | Server-side scheduled push as primary; local notification as backup. Document per-OEM battery exemption steps during onboarding. |
| Notification permission denial | Users deny notification permission reflexively. | Onboarding asks for permission at the moment of value (after logging a vehicle), not at first launch. |
| Odometer drift | Users forget to update mileage; service intervals depend on it. | Prompt for odometer at every fill-up; show "last updated 42 days ago — is this still right?"; allow interval-based fallback (months, not km). |
| Duplicate/incorrect logs | User logs the same service twice. | Soft-delete with undo; dedupe on (date, type, odometer) within a tolerance window. |
| Parts price staleness | Garage-supplied prices go out of date. | Every price entry carries an as_of date and is displayed with it. Prices older than 90 days are visually flagged. Never display a price without its date. |
2. Operational feasibility¶
2.1 Can we run this with 1–2 people?¶
| Function | v1 load | Sustainable? |
|---|---|---|
| App development | Full-time for 3 months | Yes |
| Backend operations | Near-zero (Supabase managed) | Yes |
| Garage onboarding | ~2 garages/week at launch | Yes, but this is the hidden cost |
| Customer support | WhatsApp-based, ~5–10 tickets/week at 300 users | Yes |
| Reference data curation | 40 models × ~8 intervals, one-time | Yes |
| Content/marketing | WhatsApp groups, 2–3 posts/week | Yes |
The operational risk is garage relationship management. Everything else scales with software; garage onboarding is human, repetitive, and does not scale. At 25 garages it's ~5 hours/week. At 100 it's a full-time job. Plan a part-time field rep at that point, paid from revenue.
2.2 Operating requirements¶
| Requirement | Detail |
|---|---|
| Payment collection | Paynow for garages; cash accepted with manual reconciliation |
| Support channel | WhatsApp Business number (the only channel this market uses) |
| Data protection | POTRAZ data controller registration; privacy policy; deletion path |
| Store presence | Google Play (Android only) |
| Business registration | Required for Paynow merchant and POTRAZ registration — [OPEN] confirm entity |
2.3 Operational constraints that shape design¶
- Cash is normal. Garage subscriptions paid in cash must be a first-class state, not an exception. The console needs "mark as paid (cash)" with a receipt.
- Garages are not desk-based. The garage console must work on a phone. A desktop-only console will not be used.
- Trust is personal. Onboarding happens in person or via a referral, not via a self-serve funnel. Design for that: a shareable garage invite link is more valuable than a landing page.
3. Economic feasibility¶
3.1 Build cost¶
| Item | Cost | Notes |
|---|---|---|
| Development time | 12 weeks × 1 builder | Opportunity cost, not cash |
| Supabase | US$0 (free tier) → US$25/mo at scale | Free tier covers early usage |
| Domain + Play Store | ~US$25 one-time + US$25 one-time | |
| Expo | Free tier → US$0–99/mo for builds | EAS free tier is sufficient initially |
| Paynow setup | [OPEN] confirm merchant fees beyond 1.5% + $0.50 |
|
| Data controller registration | [OPEN] confirm POTRAZ fee |
|
| Cash total to launch | < US$100 |
This is genuinely near-zero capital. The investment is time.
A warning found in the competitive research: ZiMINDEX is currently returning Worker exceeded resource limits on several routes — a free-tier Cloudflare problem on a site with real traffic. That is exactly the failure mode a "free tier is enough" plan runs into: the cost arrives suddenly, at the moment of success, as an outage rather than an invoice. Budget for the paid tier of every dependency before launch, not after. At Mota's scale that is roughly US$25–50/month, which the break-even of two garages covers comfortably — but the plan should assume those tiers are paid from day one rather than discovering it under load.
3.2 Unit economics¶
Per garage (subscription model):
| Item | Value |
|---|---|
| Price | US$40/month |
| Payment processing (Paynow) | ~1.5% + $0.50 = ~US$1.10 |
| Infrastructure cost per garage | ~US$1/month (shared) |
| Support cost per garage | ~US$3/month (0.5 hr × US$6/hr informal rate) |
| Gross margin | ~US$35 (87%) |
Per lead:
| Item | Value |
|---|---|
| Lead fee | US$3.00 |
| Payment processing | ~US$0.55 |
| Support/allocation | ~US$0.30 |
| Gross margin | ~US$2.15 (72%) |
Customer acquisition cost: near zero in v1 (WhatsApp groups, garages onboarding their own customers). Paid acquisition is not viable — at US$40/mo per garage with unknown churn, a US$50 CAC would take too long to recover without strong retention.
3.3 Break-even¶
| Scenario | Garages | Leads/mo | MRR | Monthly cost | Net |
|---|---|---|---|---|---|
| Pessimistic | 5 subs | 20 | US$260 | US$40 | +US$220 |
| Base | 12 subs | 60 | US$660 | US$60 | +US$600 |
| Optimistic | 25 subs | 150 | US$1,450 | US$120 | +US$1,330 |
Break-even is reached at roughly 3 paying garages — the fixed cost base is almost entirely time. This is the single most attractive property of the business: it can be profitable at a scale no investor would fund, which means it doesn't need one.
3.4 Sensitivity¶
| Variable | -50% | Base | +50% | Verdict |
|---|---|---|---|---|
| Garage subscription price | US$20 | US$40 | US$60 | Survives — cost base is tiny |
| Garage count | 12 | 25 | 38 | Survives — reduces to a lifestyle business |
| Churn | 10%/mo | 4%/mo | 2%/mo | Sensitive. At 10%/mo the subscription model fails; leads-only survives |
| Lead conversion | 15% | 30% | 45% | Sensitive. Lead pricing may need to be per-booking, not per-lead, to de-risk the garage |
Churn and lead conversion are the two variables that decide the business. Both are supply-side behaviours that we don't control — which is why Gate 2 must measure them before we invest in the garage console.
4. Evaluation of alternatives¶
Before committing to build, we evaluate four paths to the same outcome.
Option A — Build the full app (chosen)¶
| Dimension | Assessment |
|---|---|
| Cost | 12 weeks of one builder |
| Control | Full — data model, monetisation, roadmap |
| Time to first user | ~6 weeks for the core slice |
| Risk | Execution risk, no distribution guarantee |
| Defensibility | Garage network + dataset |
Verdict: chosen. It's the only option that builds the asset (the dataset and garage relationships) rather than renting access to someone else's.
Option B — Build only the garage console, no consumer app¶
| Dimension | Assessment |
|---|---|
| Cost | 5 weeks |
| Pro | Faster to revenue; the payer is the garage |
| Con | Without consumers, the console has no data and no leads. It's a CRM for businesses that don't use CRMs. |
| Verdict | Rejected. Inverts the value chain. The consumer record is what makes the garage lead valuable. |
Option C — Integrate into an existing super-app (Hwindi, EcoCash)¶
| Dimension | Assessment |
|---|---|
| Cost | Low build, high business development |
| Pro | Instant distribution |
| Con | No control over the record; no ability to monetise garages independently; dependent on a partner's roadmap |
| Verdict | Deferred as a distribution channel, not a replacement. Revisit at 2,000 users as a partnership, not as the primary build. |
Option D — Do nothing / use existing global app¶
| Dimension | Assessment |
|---|---|
| Cost | Zero |
| Pro | Free, and MyAutoLog genuinely works for service logging |
| Con | No ZINARA, no EcoCash, no local garages, no local parts prices, no revenue |
| Verdict | Rejected on strategy, but used as the benchmark. If our app is not meaningfully better than MyAutoLog + a WhatsApp group, we should not build it. The differentiator must be local integration, not features. |
Option E — A different idea from the set¶
Evaluated in 01-ranking.md. Car Care scores 7.80 vs the next best at 6.05. The gap is large enough that the alternatives aren't close.
5. Feasibility conclusion¶
| Dimension | Verdict |
|---|---|
| Technical | Feasible. No research risk. All v1 features are standard, offline-first CRUD plus a scheduling engine. |
| Operational | Feasible at 1–2 people up to ~25 garages. Garage onboarding is the scaling bottleneck. |
| Economic | Feasible with almost no capital. Break-even at ~3 paying garages. Ceiling is a profitable small business (US$150–250k ARR), not a venture outcome. |
| Market | Unproven, and that's the entire risk. See Stage Gate 0. |
Recommendation: proceed to Stage Gate 0 (validation) before writing any production code. The technical and economic cases are settled; the market case is not, and it is cheap to test.