Btaxi
A ride-hailing MVP for Cambodia, across rider, driver and admin.
I designed it and I built it: I wrote the spec and the business rules, ran the AI agent in Cursor that writes the code, worked with two contract developers and external QC, and shipped only what passed my tests.
Client UAT passed · launch on hold on the client's sideApp screens from my Figma file, admin screens from the live build, all shown in English with demo names, places and prices. Map data © OpenStreetMap contributors.
- How did I help
- End-to-end build
- Mobility · Cambodia
- Role
- Product designer & builder
- Team
- Me + an AI agent, 2 contract devs, external QC
- Surfaces
- Android, iOS, admin web
- Year
- 2026
- A ride-hailing MVP for Cambodia: a rider app, a driver app and a web admin, designed and built by me with an AI agent.
- Drivers top up by bank transfer with admin approval, because ABA Bank integration wasn't legally possible at MVP stage.
- 130 updates and 13 blocking bugs fixed in three months. Client UAT passed; the launch is on hold on the client's side.
The tour: No bank integration? → I build with an AI agent → Three bugs
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.
The same ride,
seen from both seats.
While the rider watches the driver come, the driver gets the rider's pickup and a button for each step of the trip.
Rules first,
screens second.
Each of these started as a rule in the spec, then became the screen that makes the rule obvious.
A coupon comes off the base fare
The discount applies to the base fare of the vehicle the rider picks, and the fare is fixed before booking.
- 01 / 04 · Rider app
A coupon comes off the base fare.
The discount applies to the base fare of the vehicle the rider picks, and the fare is fixed before booking.
02 / 04 · Rider appTuk-tuk first. A tuk-tuk, a 4-seat sedan and a 7-seat SUV, each with a fixed price shown before booking. The tuk-tuk comes first, with its own icon, so the product reads as Cambodian, not a clone.
The vehicle line-up and the local tuk-tuk icon.
03 / 04 · Driver appAdmins approve every top-up.
Bank integration wasn't legally possible at MVP stage, and automated checks would have grown the scope before the MVP proved itself. Manual approval works without the bank.
04 / 04 · Driver appA referral is a phone number.
A new driver types the inviter's phone number. The inviter is rewarded only after the new driver finishes a first ride, so fake accounts earn nothing.
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.
Inside the two apps.
Book a ride, ride it, drive it, and top up the driver's wallet.
Book a tuk-tuk with a coupon
Pick a destination, choose a vehicle at a fixed price, add a coupon, book.
- 01 / 04 · Rider app
Book a tuk-tuk with a coupon. Pick a destination, choose a vehicle at a fixed price, add a coupon, book.
The booking path, the ride options and the coupon sheet.
02 / 04 · Rider appFrom finding a driver to rating them. Each trip state has one clear message, and the fare at the end shows the coupon as its own line.
The trip states, the payment summary and the rating.
03 / 04 · Driver appOne button per step. Drivers work with one hand on a budget Android phone, so every step of a trip is a single large button at the bottom.
The offer, the eight trip steps and the cash confirmation.
04 / 04 · Driver appTop up by bank transfer. The driver picks an amount, copies the account, transfers with their phone number in the note, and waits for an admin.
The wallet, the transfer details and the pending state.
Profile,
documents, then review.
A new driver fills in a profile, uploads the ID, licence and vehicle papers, can add a referral, and waits for an admin to approve them.
One admin behind both apps.
Top-ups, drivers, rides, fares and coupons are run from one web admin. Captured from the live build, shown in English with demo data.
Approve a driver's top-up
Every bank transfer a driver reports waits here, with the amount and the time, until an admin approves or rejects it.
- 01 / 06 · Admin web
Approve a driver's top-up. Every bank transfer a driver reports waits here, with the amount and the time, until an admin approves or rejects it.
The approval queue, its tabs and the totals above it.
02 / 06 · Admin webApprove new drivers. Every driver with their rides and a status: approved, waiting for review, or locked.
The driver list and its statuses.
03 / 06 · Admin webEvery ride in one list. Rider, driver, ride type, fare and status for every booking, with search, filters and export.
The ride list and its status labels.
04 / 06 · Admin webWhat needs attention first. Drivers online, rides in progress, money approved and the top-ups still waiting, on the first screen an admin sees.
The dashboard cards and the top-up queue on it.
05 / 06 · Admin webFares per ride type. Each ride type has its seats, a minimum fare, a distance included and a price for every 100 m after that.
The service table that sets the prices the rider app shows.
06 / 06 · Admin webCoupons with limits. Each code has a discount, a cap on users and the dates it is valid. BTAXI50 is the code used in the rider app.
The coupon list and its form.
One system,
five scripts.
Semantic colours, responsive type for the app and the admin web, and a font-family variable per language: Manrope for English and Vietnamese, Noto Sans Khmer for Khmer, and Noto for Chinese, Japanese and Korean.
I build with an AI agent.
I don't hand-write the code. I write the spec and the rules, the agent writes each change, and nothing ships until it passes my tests.
- 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.
- 03Build with the agentAn AI agent in Cursor writes each change and opens a pull request. The contract devs build against the same spec.
- 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.
- 06ShipA backend developer merges it, it deploys to staging on its own, and a smoke test checks it.
54 test cases between the rules and the release.
Specs, tickets for the devs and the agent, and every test case live in one Notion hub. A change only moves on when its test case passes.
Three months,
written down.
Counted from my Notion logs, July to October 2026.
One row per change,
in four logs.
Backend, rider app, driver app and admin web each keep their own log: what changed, its priority, the files, the branch and whether it passed. My notes are in Vietnamese, the working language of the team.
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.
Three bugs,
traced to where they started.
When a ride failed, the ticket only closed once the cause was found, the data was repaired and a fresh test passed.
- SymptomRiders were told no drivers were available, even with drivers online.
- Root causeBooking saved the order, then called a live-update service that had been deleted, and broke. Each failure left a driver stuck as busy.
- FixThe backend now carries on when that service fails, and 6 stuck records were repaired.
- ProofA smoke test on staging passed.
When the happy path breaks.
A wrong verification code
A wrong code turns every box red and offers Resend, instead of a message the rider has to read.
- 01 / 05 · Rider app
A wrong verification code. A wrong code turns every box red and offers Resend, instead of a message the rider has to read.
The error state of the code entry.
02 / 05 · Rider appA coupon that doesn't apply. An invalid code says so at the top and leaves the base fares as they were.
The error message and the unchanged price rows.
03 / 05 · Rider appAsk why, in one tap. Cancelling asks for one reason from a short list, with Go back as the bigger button.
The cancel sheet and its reasons.
04 / 05 · Driver appA top-up waiting for an admin. Until an admin approves it, the request shows as Pending at the top of the history, with the wait time above.
The pending state and the history labels.
05 / 05 · Driver appA new driver's first day. Offline with no rides, the home still shows earnings and balance, and says there are no rides yet.
The empty state of the driver home.
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 paperwork: the Apple Developer account and the business licence the SMS sender needs.
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
