A ride-hailing MVP for Cambodia, across rider, driver and admin.
I owned the design, the product logic and the build: directing two contract developers, external QC and an AI agent in Cursor, and checking every build against the business rules I wrote.
In testing: Android internal, iOS TestFlightBtaxi isn't public yet, so there's no usage data here. Success at this stage means both builds holding up on real devices in Cambodia.
- Role
- Product designer & builder
- Team
- 2 contract devs + external QC
- Surfaces
- Android, iOS, admin web
- Year
- 2026
- Status
- In testing
One market. Three apps. Local constraints.
The product had to work for locals, expats and tourists at the same time, on a startup budget.
- 01Three apps that must stay in syncRider, driver and admin all have to agree, or riders stop trusting the system.
- 02No budget for custom infrastructureSo I reused an existing ride-booking and GPS platform, and spent design time on the parts that needed local thinking.
- 03The payment people expect isn't availableABA Bank integration wasn't legally possible at MVP stage, even though it's how most people expect to pay in Cambodia.
Booking that feels local.
A local tuk-tuk icon instead of a generic car, so the product reads as Cambodian, not a clone.
No bank integration? Design a deposit flow admins can trust.
A semi-automated deposit with manual admin approval, so drivers can top up before a bank integration is legally possible.
- DriverTops up through ABA Bank in the app
- BankConfirms instantly
- ResultBalance topped up
- DriverRequests a top-up in the app
- DriverTransfers by QR, with their phone number in the note
- AdminMatches the transfer and approves on the web, within 4 hours
- ResultBalance topped up
I own the layer above the code.
I don't read or write code. I define the spec and the rules, direct the build, and QA the result against them.
- 01SpecI define what gets built: the screens, flows and states for all three apps.
- 02Business rulesPricing, payments and permissions written down as rules the build has to follow.
- 03Orchestrate buildThe contract devs and an AI agent in Cursor build against the spec. I direct the work.
- 04Agent-assisted QAI test each build against my rules, with an AI agent helping to check behaviour.
- 05FixAnything that breaks the spec goes back with the correct logic written out.
- 06HandoffThe build moves on only when it matches the rules.
A coupon that replaced the fare.
Because I owned the pricing rules, I could see the build breaking them, write out the correct logic and get it fixed before handoff.
- InputBase fare
- BugCoupon overwrites the base fare
- OutputWrong final price
- InputBase fare
- RuleCoupon applied to the base fare
- OutputCorrect final price
The spec is the product.
The devs and the AI agent only build what I actually write down. When I wrote the logic tightly, the build came back clean. When I left a rule a little fuzzy, QA is where it came back to bite me. So writing the rules is the real work, not the warm-up.
- Invest selectivelyReusing infrastructure freed design time for the parts that build local trust.
- Script is a technical problemKhmer support meant testing layout and rendering on budget Android, not just translating.
- Admin risk is product riskThe biggest blocker wasn't design or code. It was the Apple Developer account and the client's paperwork.
A multi-app MVP, scoped piece by piece.
Three connected apps are priced by what each one needs. Pick the pieces, and I send a written proposal within 48 hours of our call.
A build like this: multi-app, priced after a scoping call
