Mota — Operations Manual
SDLC phase: Implementation (Chapter 5.3: installation, training, review, backup)
Purpose: How the system runs, how it fails, and how it's recovered — with enough specificity that someone else could operate it.
1. Environments
| Environment |
Purpose |
Data |
Access |
| Local |
Development |
Seeded fixtures |
Builder |
| Staging |
UAT, E2E, demo |
Synthetic only |
Builder + UAT participants |
| Production |
Live |
Real user data |
Builder (MFA), no direct DB access by default |
Rule: staging never receives a production database dump. Test data is generated.
2. Deployment
Mobile app (consumer)
| Step |
Detail |
| Build |
EAS Build (Expo) |
| Distribution |
Google Play, staged rollout 10% → 50% → 100% |
| Versioning |
Semantic; versionCode increments per upload |
| Rollback |
Play Store cannot un-ship a binary — ship a server-side feature flag off, or a hotfix within 24h |
| Mandatory update |
Never hard-block; warn after 30 days on an unsupported version |
The critical operational constraint: a bad mobile release cannot be rolled back the way a web deploy can. This is why every risky feature ships behind a remote flag. Flags are evaluated server-side where possible.
Backend
| Step |
Detail |
| Platform |
Supabase (managed) |
| Migrations |
Versioned SQL, applied in order, each with a down path |
| Review |
Every migration is read before apply — no blind db push to production |
| Rollback |
Down migration; database backup if the migration is destructive |
| Zero-downtime rule |
Additive changes only on hot tables; never rename or drop in the same deploy as the code change |
Garage console
| Step |
Detail |
| Platform |
Vercel |
| Preview |
Every branch gets a preview URL for review |
| Rollback |
Instant revert to the previous deployment |
3. Monitoring
| What |
Tool |
Alert threshold |
Who |
| Crash-free sessions |
Sentry |
<99% over 1h |
Builder (push) |
| API error rate |
Supabase logs / Sentry |
>2% over 15 min |
Builder (push) |
| Sync failure rate |
Custom event |
>1% of attempted syncs |
Builder (daily digest) |
| Reminder delivery |
Custom job |
<95% delivered within 1h |
Builder (daily digest) |
| Payment webhook failures |
Paynow + Sentry |
Any failure |
Builder (immediate) |
| Uptime |
Better Stack |
2 consecutive failures |
Builder (push) |
| Database size / storage |
Supabase dashboard |
>80% of plan |
Builder (weekly) |
Alert hygiene rule: every alert must be actionable. An alert nobody acts on is noise and will train us to ignore all alerts. If an alert fires 3 times without action, delete it or fix the condition.
4. Backups and disaster recovery
| Aspect |
Target |
Implementation |
| RPO (max data loss) |
24 hours |
Supabase daily backup + weekly logical dump to cold storage |
| RTO (max downtime) |
4 hours |
Documented restore procedure, tested quarterly |
| Retention |
7 daily, 4 weekly, 3 monthly |
Provider default plus our own dump |
| Restore drill |
Quarterly |
Restore to staging, verify row counts and a sample of records |
| Secrets |
Rotate on any suspected exposure; stored in a password manager, never in the repo |
|
The drill is the point. An untested backup is a hope, not a backup. The quarterly drill must reconstruct a working staging environment and verify that the interval engine produces the same results on restored data.
Restore procedure
1. Provision a new Supabase project (or use the staging project).
2. Restore the most recent daily backup.
3. Run migrations to bring schema to current.
4. Verify: row counts per table, latest record timestamp, RLS policies present.
5. Run the RLS isolation test suite against the restored instance.
6. Recompute due items for a sample of 100 vehicles and compare to pre-restore values.
7. If verified: repoint application environment variables.
8. Record the drill in the ops log with duration and discrepancies.
5. Support
| Channel |
Detail |
| Primary |
WhatsApp Business number — the only channel this market uses |
| Secondary |
In-app "report a problem" |
| Hours |
Business hours, best effort. No 24/7 SLA at this scale. |
| Response target |
First response <24h; resolution <5 working days for non-critical |
Support tiers
| Tier |
Example |
Handling |
| T1 — Usage |
"How do I log a service?" |
Canned reply + 20-second screen recording |
| T2 — Data |
"My record is wrong / missing" |
Reproduce, fix, explain. Data errors are always T2 minimum. |
| T3 — Access |
"I can't log in" |
OTP troubleshooting; check network/operator first |
| T4 — Billing |
"I was charged twice" |
Verify against Paynow, refund or credit within 48h |
| T5 — Privacy |
"Delete my data" |
Execute within 30 days; confirm in writing |
Data errors are escalated above feature requests. A user who reports a wrong service date is telling us the core product failed; that is more important than any new feature.
6. Incident runbook
Severity levels
| Level |
Definition |
Response |
| S1 |
Data loss, data breach, or payment integrity failure |
Immediate, all hands, user communication |
| S2 |
Core flow broken (cannot log, cannot sync, no reminders) |
Same day |
| S3 |
Degraded (slow, cosmetic, non-core feature down) |
Next business day |
| S4 |
Minor |
Backlog |
S1 — suspected data breach
1. CONTAIN Revoke exposed credentials/keys. Disable affected endpoint or feature flag.
2. ASSESS What data, how many users, what sensitivity? PII (phone numbers) is the highest tier.
3. DOCUMENT Timeline of discovery, actions, evidence. Start immediately; memory degrades.
4. NOTIFY POTRAZ as Data Protection Authority. Notify affected users if their PII is involved.
5. REMEDIATE Fix the root cause, not the symptom.
6. REVIEW Post-mortem within 7 days. Blameless. Concrete prevention.
Do not delay notification to finish the fix. Regulatory exposure compounds with time.
S1 — data loss
1. STOP WRITES Disable write endpoints to prevent divergence.
2. RESTORE Follow the restore procedure (§4) to a new instance.
3. RECONCILE Compare pre-incident backups to identify the loss window.
4. COMMUNICATE Tell affected users exactly what was lost and what was recovered.
5. PREVENT Identify why RPO was exceeded and fix it.
S2 — sync failing
1. Check Sentry for the failing endpoint and error class.
2. Check whether a migration or deploy correlates with the start time.
3. If deploy-correlated: roll back first, investigate second.
4. If data-correlated: identify the pattern (a specific field, a specific client version).
5. Ship a client fix if needed; expect a 24–72h tail as users update.
S2 — reminders not sending
1. Verify the scheduler job ran (Supabase cron logs).
2. Verify the push provider accepted the batch (Expo/FCM response).
3. If the provider rejected: check credential expiry and token format.
4. If tokens are stale: prune invalid tokens; expect a delivery dip until users reopen the app.
5. Backfill missed reminders carefully — do not send 30 days of stacked reminders at once.
7. Routine operations
| Cadence |
Task |
Duration |
| Daily |
Check Sentry, payment webhooks, sync failure digest |
10 min |
| Weekly |
Review metrics dashboard (M1–M4), garage activity, support backlog |
45 min |
| Weekly |
Review new leads and billing reconciliation |
20 min |
| Monthly |
Backup verification, dependency updates, cost review |
1 hour |
| Monthly |
Garage check-in calls (retention + feedback) |
2 hours |
| Quarterly |
Restore drill; RLS test suite; access review |
2 hours |
| Quarterly |
Post-launch review: are the Gate metrics moving? |
1 hour |
The weekly metrics review is the one that cannot be skipped. Everything else can slip a week. If M1–M4 aren't reviewed weekly, the kill criteria become retroactive excuses instead of decisions.
8. Security operations
| Control |
Implementation |
Cadence |
| Dependency audit |
npm audit in CI; block on high severity |
Every build |
| Secret scanning |
Pre-commit hook + CI scan |
Every commit |
| Access review |
Who has production credentials; MFA enforced |
Quarterly |
| RLS test suite |
Automated against staging |
Every deploy |
| PII access logging |
Any admin read of user records is logged |
Continuous |
| Vulnerability patching |
Critical within 72h; high within 7 days |
As discovered |
| Penetration test |
Lightweight external review before public launch |
Once, then annually |
9. Training / onboarding design
CUT's "training" section, translated for a consumer product.
| Audience |
Method |
Success measure |
| Consumer |
In-app first-run: 3 screens, one action each. No manual, no video. |
8/10 users log a service unaided (UAT) |
| Consumer — advanced |
Contextual tips on first encounter (e.g. first time a due item appears, explain what "based on your records" means) |
Reminder comprehension ≥90% in UAT |
| Garage |
In-person or WhatsApp onboarding, 15 minutes, one script. They must receive a real lead within their first week. |
Garage responds to first lead within 24h |
| Garage — self-serve |
90-second screen recording for each of: listing setup, lead response, price submission, invoice payment |
≥70% complete setup without a call |
| Future operator |
This document set plus the repo README |
Can restore a backup and deploy a fix unaided |
The garage onboarding script is a product artefact, not a nicety. It is the highest-leverage 15 minutes in the business. Write it once, refine it every five onboardings.
10. Post-launch review
| Review |
When |
Questions |
| Week 1 |
7 days after launch |
Did anything break? What did users do that we didn't expect? |
| Month 1 |
30 days |
Are M1/M2 tracking? Is retention real or is it friends being polite? |
| Gate review |
At each gate |
Are the exit criteria met? If not, is it a timing problem or a truth problem? |
| Quarterly |
Every 3 months |
Is this still worth the time? What would make us stop? |
The quarterly question is the important one. It's the only scheduled moment where stopping is a legitimate option rather than an admission of failure.
11. Cost model
| Item |
At launch |
At 2,000 users |
| Supabase |
US$0 (free tier) |
US$25/mo (Pro) |
| Vercel |
US$0 (hobby) |
US$0–20/mo |
| Expo EAS |
US$0 |
US$0–29/mo |
| Domain |
US$12/yr |
US$12/yr |
| Sentry |
US$0 (free tier) |
US$0–26/mo |
| WhatsApp Business API |
US$0 (deep links only) |
[OPEN] if API messaging is added |
| Play Store |
US$25 one-time |
— |
| Total |
~US$2/mo |
~US$50–100/mo |
Break-even at 2–3 garage subscriptions. Infrastructure is not the constraint at any plausible scale.