CropAxis

Product Vision

I started CropAxis to attack a specific, stubborn problem: Sri Lanka's fresh king-coconut export trade is one of the country's premier foreign-exchange earners, yet it runs on middlemen and paperwork. Growers — overwhelmingly smallholders — sell through layers of collectors with no price transparency. Exporters can't easily find, verify and aggregate genuinely export-grade stock across the island. And the Coconut Development Authority (CDA), which enforces the export rules that keep containers from being rejected at the port, does it all manually.

The vision was a single platform where all three sides meet on shared data — and where the regulator isn't a bottleneck bolted on at the end, but a digital step built into the core workflow.

• Who it's for: smallholder Tree Owners, licensed Exporters, and a CDA Officer as a first-class digital regulator — plus an Admin operator.
• The bet: transparent listings, a fair ML-driven sourcing layer, and a built-in compliance gate can collapse the middleman tiers without losing the quality guarantees exporters depend on.
• Success looked like: a working, multi-sided platform a grower, an exporter and a CDA officer could each run end-to-end — list → audit → discover → offer → pay & export — in their own language.

Architecture Stack

CropAxis is deliberately decoupled: a light React single-page app for the business workflow, Supabase as the cloud data, auth and realtime layer, and a separate Python service for the machine learning. Keeping the models out of the web tier means the app stays fast, the ML can scale and retrain on its own clock, and API keys never ship to the browser.

• Presentation — a role-aware SPA in React 19 + TypeScript + Vite + Tailwind on Vercel, with Leaflet maps for geo-tagged listings and live market-price views. Built trilingual from the start — Sinhala, Tamil and English.
• Data & security — Supabase: Postgres for listings, orders, profiles and compliance, with Row-Level Security policies per role, Realtime for the live map, Storage for imagery, and Edge Functions isolating secrets. The public anon key is public by design — RLS is what enforces access, and I verified no secrets ship in the client bundle.
• AI microservice — a separate Python FastAPI service so the models scale independently of the web tier and expensive operations sit behind admin-key-guarded endpoints.

The ML layer — real models, honestly measured

These are the results I defended, validated with 5-fold cross-validation rather than a single lucky split:

For grading, Gemini Vision is the primary engine with the local ensemble as a graceful fallback, so a grade always comes back even if the vision API is unavailable.

The CDA compliance engine — the novel part

I modelled the CDA's real export rules as software: three FastAPI endpoints under /compliance/*, each backed by its own Supabase table with RLS.

• Store audit — CDA Annexure II/IV: ≥ 1,500 sq.ft, smooth concrete floor, vermin-proofing, calibrated scales → Approved or Pending-Correction (30-day deadline).
• King-coconut batch — ≥ 15.5″ circumference, < 30% mite damage, golden-orange maturity, 6 nuts/box, food-grade wrap → on pass, the system issues a unique CDA-KC sticker and releases the listing to the market.
• Export-trade — e.g. the UAE circular's US$ 0.80/nut floor and DP terms, auto-computing the shipment + 30-day remittance deadline.

PM Execution

Building a four-sided product solo means the product calls and the engineering calls are the same calls. The sequencing that mattered:

• Model the supply chain before the screens — four roles and the objects that move between them: trees, listings, offers, orders, compliance records.
• Translate the regulation — the genuinely hard work was reading the CDA's circulars and store/batch standards and turning them into a verification workflow with a real pass/fail gate and an audit trail.
• Decouple the AI — pull the models into their own FastAPI service so they scale, retrain and redeploy independently of the web app.
• Be honest about what's live — I built a clear live-vs-simulated boundary into how the product demos, so nothing pretends to be wired when it isn't.

The hard call was resisting the urge to fake the last 10%. WebXPay's callback and the chatbot depend on edge functions I hadn't deployed, so I marked them simulated rather than staging a fake success. The models, the marketplace, the realtime map and the compliance engine are real — and saying exactly where that line falls is what makes the rest believable.

The Pitch

CropAxis is what it looks like when one person takes a genuinely multi-sided GovTech product from a messy real-world problem all the way to a working, deployed MVP with real, cross-validated machine learning — and stays honest about the maturity curve while doing it.

What it proves:

• System design — a clean, decoupled architecture (React/Supabase web tier + an independent Python ML service) a single engineer can reason about and extend.
• Real ML, not a mock-up — XGBoost yield forecasting at R² ≈ 0.98, Ridge price forecasting at MAPE ≈ 2.17%, a ≈ 95% grading ensemble behind Gemini Vision, and a Haversine matching engine — all validated, all serving the workflow.
• Product judgement — turning government export regulation into an auditable software engine is the differentiator, and it's the unglamorous domain work that makes a platform trustworthy.
• Founder's honesty — a built-in live-vs-simulated boundary, and every claim here survives someone reading the source.

It passed its final-year viva and runs as a live demo, and it's now in go-live prep: deploying the WebXPay and chatbot edge functions, adding JWT auth to the ML endpoints, and onboarding the first exporters.

CropAxis is the clearest statement of how I build: get the system boundaries right, make the hard domain logic real, and never let the story run ahead of the code.