PlantMoney (ដាំលុយ)
A Khmer-first investment platform that delivers returns to customers at home, through agents.
- Engagement
- Cambotix product
- Industry
- Financial Services
- Year
- 2026
The challenge
Formal finance in Cambodia is built around collection: institutions expect customers to travel, queue and repay. For customers outside that habit, the trust gap is the product barrier. A platform that pays returns has to solve delivery and trust simultaneously, because a bank transfer to someone who doesn't use banking is not a payout.
Our approach
We modeled the agent as a first-class role rather than an operational detail. Agents get their own app, their own routing logic and their own accountability trail, because in this model the agent is the product's face and its largest risk. Scheduled deliveries are generated server-side so the operation is driven by the calendar rather than by someone remembering.
What it had to achieve
- Deliver returns physically, through a trusted local agent
- Make the customer app usable by someone whose first app is this one
- Support multiple operating subsidiaries under one platform
- Report social impact credibly, not decoratively
Architecture
The decisions that made the rest possible.
Agent routing as a scheduled pipeline
Due deliveries are computed and assigned on a schedule, producing each agent's route before their day starts. Nothing depends on an operator manually building a list.
Multi-subsidiary data partitioning
Every record carries a subsidiary scope, so several operating entities share one platform without one being able to read another's customers or ledgers.
Khmer-first interface, including numerals
Khmer is the base locale. Layouts, fonts and numeral rendering are designed for it from the start instead of added after an English build.
Delivery confirmation as a two-sided record
A payout is closed only when the agent records delivery and the customer's record reflects receipt, leaving a trail for any later dispute.
What we delivered
- Customer Flutter app: enrolment, holdings, scheduled returns, history
- Agent Flutter app: assigned routes, delivery confirmation, daily reconciliation
- Admin dashboard: customers, agents, subsidiaries, schedules, reporting
- Multi-subsidiary support with scoped access
- Scheduled delivery generation and agent assignment
- Social-impact reporting views
Security & reliability
- Subsidiary scoping enforced server-side on every query
- Payout confirmations recorded with agent identity and timestamp
- Agent reconciliation surfaces discrepancies the same day rather than at month end
Outcomes
What changed once it was live.
- Returns reach customers who do not use conventional banking channels
- Several subsidiaries operate on one platform without data bleed
- Agent routes are generated rather than assembled by hand
- Impact reporting is produced from transaction data, not compiled separately
What we would do differently
Every project teaches something. Publishing it is how you tell whether a team is reflecting or just selling.
- Treating the agent as a first-class role, with their own app and accountability trail, is what makes the model auditable. Bolting agent tracking onto an admin panel would not have held up.
- Khmer numerals affect layout width in ways English design systems do not anticipate. Deciding this at token level, not screen level, saved a lot of rework.
Let's find out if this is worth building.
A 45-minute discovery call, free. You describe the problem, we tell you honestly what it takes, what it costs, and whether you should build it at all.