Chomkar.com

Problem

Smallholder farmers often struggle to connect supply with buyer demand at the right time. The problem is not only posting crops online; it is coordination, demand visibility, trust, and clearer pre-harvest information.

My role

I co-founded and helped shape the project direction, contributed as a full-stack engineer, worked on product strategy and user flow, supported buyer and farmer flow design, helped prepare the pitch deck and demo flow, and worked on positioning the project for hackathon judging and startup validation.

What I built

• — A market-access product direction for farmer supply and buyer demand.
• — Farmer and buyer flow planning.
• — Full-stack product contributions during the build.
• — Pitch deck support, demo flow preparation, and business model explanation.
• — Project positioning from KasekorX AI voice-to-marketplace into Chomkar.com.

Architecture

The deployed system is deliberately DB-free at the edge: a static Khmer-first site plus a dependency-free hash-router PWA (farmer, operator, buyer, and verify views) backed only by Cloudflare Pages Functions, so the whole app stays offline-capable and cheap to run. The one live AI surface — a lesson helper on Claude Haiku with an optional ElevenLabs voice-to-text — is walled off from commerce by a two-layer guard, and commercial state is driven by an explicit multi-step spine where confirmed availability is never conflated with a sale. Voice was split into its own Worker after a multipart upload crashed the Pages runtime, and the service worker uses network-first-with-cache-reload so deploys are never hidden behind a stale edge cache.

The product focuses on connecting farmer supply with buyer demand through better coordination, clearer crop information, pre-harvest demand visibility, and a trust-focused supply flow.

Backend / deployment

Constraints

• — Built under hackathon pressure with a startup-style judging format
• — Needed to explain a Cambodia-relevant agriculture problem clearly
• — Had to connect product flow, business model, pitch, and demo into one story
• — Still an active student-built product, so public claims must stay honest

Tradeoffs

• — Focused the pitch around market access instead of trying to solve every agriculture problem at once.
• — Kept the product explanation practical so farmers, buyers, and judges could understand the flow.
• — Treated the hackathon result as validation, not as proof that the product is finished.

What I learned

• — How to frame a local agriculture problem as a product problem.
• — How to connect user flow, technology, business model, and pitch narrative.
• — How hackathon pressure forces simple product decisions.
• — How team collaboration changes the way a product grows.
• — Why agritech trust, coordination, and timing matter as much as the interface.

Next backend step

Add a durable persistence and auth layer behind the edge Functions — a hosted Postgres plus real cooperative and buyer accounts — as I move toward the hosted-backend cloud work I am actively studying.

Next steps

• — Keep improving the farmer and buyer flows.
• — Add stronger public proof with screenshots, photos, and event documentation.
• — Continue validating the product direction beyond the hackathon.