Business & Strategy · Software & Product Systems
Chomkar OrderLoop
A buyer-first coordination concept: one recurring buyer order assembled from documented smallholder commitments before harvest.
Can one recurring buyer order coordinate 30–100 smallholder commitments before harvest — reliably enough to improve farmer income?
What problem this attacks
Smallholder farmers often plant without reliable demand visibility, while buyers cannot easily coordinate consistent volume and quality across many small farms. Both sides lose: farmers to price uncertainty and spoilage, buyers to unreliable supply.
Who it serves
One recurring produce buyer, one cooperator who aggregates on the ground, and the smallholder farmers in that cooperator's network — deliberately not 'all farmers' or a marketplace.
Why it matters
Demand-blind planting is one of the quietest ways smallholder income evaporates. If coordination works for a single recurring order loop, it can be measured honestly; if it cannot work at that scale, a marketplace built on top of it was never going to.
What I actually did
My exact role
My share of a team project: interview design and analysis for the field research, business analysis of the order-loop economics, and the Khmer voice-intake layer — it is built on Kaskor ASR, my own fine-tuned speech model, and I provide that API from my own account for the team to build against.
Team contributions
A CHNAI LAB team project. We ran the field interviews, designed the concept, and submitted the hackathon entry together. My teammate wrote the code for the public Chomkar website; I contributed the research and the business analysis, and I provide the Kaskor ASR API — my own Khmer speech model — that the team builds the voice intake on.
What was researched and validated
Research
We ran structured interviews with bok choy farmers in Kang Meas district, Kampong Cham, focused on planting decisions, price information, and willingness to commit volumes pre-harvest. Interview records are private; the framing they produced is public in the Decision Grid repository.
Validation so far
Concept validation only so far: field interviews plus a hackathon placement. The pilot thesis is deliberately bounded — one recurring buyer, one cooperator, roughly 30–100 farmers — and no recurring delivery has been run yet, so order reliability and unit economics remain hypotheses.
How the solution works
Start from a confirmed recurring buyer requirement and work backwards: the cooperator collects farmer commitments against that order, the system documents each commitment and exception, and voice input in Khmer lowers the data-entry barrier. Software coordinates; the cooperator remains the operational anchor.
User workflow
- Buyer confirms a recurring order (volume, quality, cadence)
- Cooperator broadcasts the requirement to the farmer network
- Farmers commit volumes — by voice where typing is impractical
- The system assembles a documented lot and flags shortfalls early
- Delivery, exceptions, and payment timing are recorded for the next loop
System architecture
Deliberately minimal: a coordination record system over one order loop, with the Decision Grid engine as the lot-assembly brain and Kaskor ASR as a future voice-intake layer. No marketplace infrastructure until a single loop proves out.
Methods
Buyer-first product validation, structured field interviews, bounded pilot design, and a strict rule that software features wait for operational evidence — the first pilot may prove coordination matters more than code.
Business, rules, and risk
Business value
The commercial hypothesis is concrete: better fulfillment rates and less spoilage for the buyer, earlier price certainty for farmers, and a coordination fee that only makes sense if the loop demonstrably works. None of it is claimed as proven.
Contracts & policy considerations
A real pilot needs simple, honest commitment terms: what a farmer commitment binds, what buyer cancellation costs, who bears spoilage risk, and how disputes settle. Drafting these terms in plain Khmer and English is part of the pilot design, not an afterthought.
Data & privacy
Farmer interview records and any future commitment data are personal and commercially sensitive. Interviews remain private; a pilot would need documented consent for data collection and a clear statement of who can see farmer-level information.
Risks
- The pilot may show operational coordination matters more than software — and the honest response is to build less software
- Farmer income, buyer retention, and spoilage improvements are hypotheses until measured
- A failed pilot with real farmers has real costs for real people — bounded scope is a safety decision, not just a research one
business model
How Chomkar is meant to make money
The commercial design behind the order loop, stated before there is any revenue to point at. Nothing here is proven — the pricing row is deliberately empty because no pilot has run.
| Field | Statement | Evidence |
|---|---|---|
| Who pays | The buyer, never the farmer. chomkar.com states the model plainly: zero percent cut of the produce price, and farmers pay nothing to take part. | |
| Revenue stream | A coordination fee charged to the buyer on a recurring order — the fee for turning one request into one verified lot. Unpriced until a pilot shows the loop is reliable enough to charge for. | |
| Customer segments | One recurring produce buyer needing consistent bulk volume, one cooperator who aggregates on the ground, and the smallholders in that cooperator's network. | |
| Value to the buyer | Send one message, get back one assembled lot that can be checked before purchase — instead of chasing many farms for volume and quality. | |
| Value to the farmer | Demand visibility before planting rather than after harvest, and the negotiated price kept intact instead of eroded through middleman layers. | |
| Cost structure | The cooperator's coordination time is the real operating cost; the software is deliberately thin, so the model only works if coordination is cheaper than the spoilage and shortfall it prevents. | |
| What is unproven | Everything commercial. No pilot has run, no fee has been charged, and no buyer has committed to a recurring order — willingness to pay is a hypothesis, not a finding. |
What exists and what the evidence shows
Technical decisions
- Buyer-first order loop instead of a broad marketplace
- The cooperator as the operational aggregation point rather than assuming every farmer manages an app
- Field validation before scale claims
- Voice input and Khmer ASR treated as enabling infrastructure, not the product
Completed work
Structured field interviews with approximately 30 bok choy farmers in Kang Meas, Kampong Cham (team effort)
CompletedConcept placed Top 2 in Turing Hackathon Cycle 10, Market Access for Farmers track
CompletedOne recurring buyer pilot with documented commitments and exceptions
Planned
The receipts
Photographs
Results
Field research reframed the product from marketplace to single-order coordination loop — the strongest outcome so far is a smaller, more testable idea.
No pilot has run yet; there are no fulfillment, income, or spoilage results to report.
What limits it, and what I learned
Constraints (imposed)
- A recurring delivery pilot has not yet been run, so order reliability and unit economics are unproven
- Interview data is private, which limits what can be shown publicly
Tradeoffs (chosen)
- Bounded pilot scope (one buyer, one cooperator) trades speed of learning against breadth of claims
- Building the decision engine before the pilot risks some throwaway work if field reality contradicts the model
Lessons learned
- Field interviews kill more features than they inspire — and that is their value
- An operationally anchored cooperator beats an app-for-everyone assumption in low-connectivity contexts
- Hackathon validation is directional, not evidential; it earns a pilot, not a claim
What gets validated next
- Run one recurring buyer pilot and record every commitment and exception
- Measure fulfillment rate, coordination time, spoilage, and payment timing
- Decide which ML features are justified only after operational data exists