13 MonthsConstruction / PropTech
Construction Tech Platform
A construction platform where clients, architects, engineers, contractors, and agents finally work from the same project, not five different versions of it.
- UI/UX Design
- Product Strategy
Designing BTAXI — A Ride-Hailing Ecosystem for Cambodia.
BTaxi was a side project where I worked directly with the client on product design across Rider, Driver, and Admin, while collaborating with external dev and QC teams to move the MVP toward delivery. The work focused on localization, lean product decisions, and making the product usable within the realities of the Cambodian market.
[01]IMPACT & SUMMARY_
A localized ride-hailing MVP across Rider, Driver, and Admin — shaped around real delivery constraints in Cambodia.
Project Status
Design Delivered
Rider, Driver, and Admin flows were completed and handed off for development.
iOS Pending
Release is still blocked by the client’s Apple Developer registration status.
Project Status
Design Delivered
Rider, Driver, and Admin flows were completed and handed off for development.
iOS Pending
Release is still blocked by the client’s Apple Developer registration status.
BTaxi was a side project where I worked directly with the client to shape a ride-hailing MVP for Cambodia across Rider, Driver, and Admin. Beyond product design, I also stayed close to delivery by coordinating with external developers and QC, especially around localization, payment limitations, and platform-specific blockers.
Android builds are available for testing, while iOS release is still paused because the client’s Apple Developer corporate registration has not been resolved yet.
Executive Summary
- Challenge: Build a 3-surface ride-hailing MVP for Cambodia on a limited budget, while dealing with low-end Android constraints, Khmer script rendering, and no legal access to ABA Bank integration at the MVP stage.
- Approach: Reused existing booking and GPS foundations where possible, then focused design effort on localization, trust, MVP scope, and practical workarounds for payment and delivery.
- My role: Product design across Rider, Driver, and Admin, plus day-to-day coordination with the client, external developers, and QC during delivery.
[02]THE PROBLEM_
THE PROBLEM
ONE MARKET. THREE SURFACES. MANY LOCAL CONSTRAINTS.
This product had to work across three connected surfaces: Rider, Driver, and Admin. Each one depended on the others to feel reliable, but the project also had to stay realistic for an early-stage client with limited budget and limited room for custom infrastructure.
Some of the hardest constraints were local. Khmer script could easily break layouts on lower-end Android devices, and the team could not rely on direct integration with ABA Bank during the MVP stage, even though it was one of the most important payment expectations in the market.
[03]DISCOVERY & APPROACH_
DISCOVERY & APPROACH
BUILD LESS FROM SCRATCH. FOCUS ON WHAT NEEDED LOCAL THINKING.
One of the biggest early decisions was not to rebuild ride-booking and GPS infrastructure from zero. Since this was a side project with a limited budget, the more practical path was to work from existing foundations where possible, and spend design time on the parts that actually needed local product decisions: script support, trust, payment behavior, and role-specific flows.
This approach helped keep the MVP realistic while still giving the product enough local specificity to feel usable in the Cambodian context.
Technical Adaptation
- Khmer script support: Tuned typography and layout behavior with Noto Sans Khmer to reduce stacking, spacing, and legibility issues on lower-end Android devices.
- Local visual cues: Added tuk-tuk-oriented iconography and transport cues so the experience felt more familiar than a generic ride-hailing clone.
- Payment workaround: Since ABA Bank integration was not legally available at the MVP stage, the flow relied on a semi-manual QR top-up approach with screenshot verification.
[04]DELIVERY STATUS_
DELIVERY STATUS
THREE SURFACES COMPLETED. DELIVERY DEPENDED ON EXTERNAL READINESS.
BTaxi was delivered as a full ecosystem across Rider, Driver, and Admin. My role was centered on product design, but because this was a side project with an external dev and QC setup, I also had to stay involved in coordination to keep scope, handoff, and delivery moving in the same direction.
As designer:
This meant balancing product decisions with practical delivery issues — especially around payment limitations, platform rollout, and what the team could realistically support at MVP stage.
As coordinator:
Worked directly with the client and collaborated with external dev and QC teams to keep scope realistic, handoff clear, and delivery aligned with the project’s technical and administrative constraints.
CURRENT STATUS
Android builds are available for testing. iOS release is still blocked because the client’s Apple Developer corporate registration has not yet been completed, which also affects internal acceptance flow.
[05]Reflection_
Reflection
01
Invest selectively: Not every part of a product needs to be custom. Reusing infrastructure where possible gave the project more room to solve the parts that actually shaped local trust and usability.
02
Script is technical: Localization was not just a translation task. Supporting Khmer properly meant testing layouts, typography, and rendering behavior on devices where UI quality could break down quickly.
03
Administrative risks are real: Some of the biggest blockers in delivery were not design or engineering issues, but platform-account and legal dependencies on the client side. This project was a good reminder that product delivery also depends on operational readiness.
