Vanility

Enabling Indonesian vanilla farmers to grade, cure, and sell export-ready vanilla directly to global buyers, boosting their earnings and bypassing middlemen.

Comment

Inspiration

The idea started from an Instagram account I stumbled across that talks about export and import in Indonesia. Scrolling through their posts about how commodities move from small producers to international buyers, I kept seeing the same pattern repeat itself: Indonesia produces incredible raw materials, but the people actually growing them rarely capture the value those materials are worth once they reach the export market.

Vanilla stood out to me specifically. Indonesia is one of the world's largest vanilla producers, yet the country's export value never reflects that. Digging deeper, the reasons became clear: farmers harvest too early out of financial pressure and fear of theft, curing is done inconsistently because there's never been an accessible way to know if you're doing it right, and farmers have zero direct connection to the buyers who would actually pay a fair price for quality.

I saw a problem that was real, measurable, and solvable with the technical skills I already had. So I decided to build it.

What it does

Vanility helps Indonesian vanilla farmers produce export-grade vanilla and connects them directly with buyers who value quality.

On the seller side, farmers input basic data about their harvest and curing process (pollination date, region, curing durations for sweating, sun drying, and conditioning). Vanility returns a predicted grade, a confidence score, estimated dry yield, and a market price range, so farmers know what they're holding before they sell. An interactive curing checklist aligned with SNI export standards guides them step by step toward Export Ready status. A Value-Add Calculator shows exactly how much more they could earn by processing raw beans into cured vanilla or extract instead of selling raw.

On the buyer side, buyers set their criteria (required grade, quantity range, preferred origin, industry) and activate Buyer Mode, joining a live, real-time presence pool. A rule-based matching engine scores every export-ready batch against every active buyer using four weighted factors: grade compatibility, quantity fit, origin preference, and industry alignment. The top matches are shown with a compatibility score and a plain-language explanation generated by an LLM Export Advisor, in either Indonesian or English.

How I built it

The grading engine is a hybrid system. I codified official SNI 01-0012-2015 standards and published IPB University curing research into a rule-based scoring logic, then used that logic to generate training data for a scikit-learn Random Forest classifier. The rule engine keeps the grading grounded in documented standards, while the ML layer smooths out rigid rule boundaries and provides confidence estimates across the full parameter space.

The matching engine is deliberately rule-based and deterministic rather than AI-driven. Buyer-seller matching decides real economic outcomes for real people, so I wanted every match to be explainable and auditable, not a black box. The LLM (via OpenRouter, using an NVIDIA Nemotron model) is only used at the very end of the pipeline, to turn a match's structured score into a natural-language explanation. It never makes the matching decision itself.

For live presence, I used Supabase Realtime to track which buyers are actively looking for vanilla at any given moment, so the buyer count and matching pool update instantly rather than relying on static, pre-seeded data.

Tech stack: Next.js 16 and React 19 on the frontend, FastAPI on the backend, Supabase for authentication, database, and real-time presence, and scikit-learn for the grading model.

Challenges I ran into

Being a solo builder for this hackathon meant every layer, from the ML model to the real-time matching system to deployment, was on me. A few specific challenges stood out:

Getting the matching engine to correctly exclude a batch's own seller from its own buyer recommendations required careful thought about edge cases in a real-time system where any user can switch between seller and buyer roles at any time.

Deployment turned into its own saga. I optimized the backend Docker image with a multi-stage build to cut its size down, tried multiple free-tier hosting platforms, and ultimately hit resource constraints that free tiers simply weren't built to handle for a Python service running scikit-learn and pandas. With time running short, I made the call to run the backend locally for the live demo rather than keep fighting infrastructure that wasn't the point of the project.

Balancing ambition with honesty was its own challenge too. It would have been easy to overclaim, saying I had verified global buyers or a fully built marketplace. Instead, I chose to be explicit in the product itself about what's real today (the grading engine, the live matching mechanism) versus what's still roadmap (onboarding actual verified export buyers at scale).

Accomplishments I'm proud of

Building a grading engine that's grounded in real, citable agricultural standards rather than an arbitrary black-box model. Every prediction traces back to documented SNI rules and published curing research.

Building a real-time buyer presence system that actually works live, not a static mockup, so a live demo can show the matching pool changing in real time in front of an audience.

Keeping the matching logic fully rule-based and explainable, so I can answer exactly why any given match was recommended, with no hand-waving.

Doing all of this solo within the hackathon timeframe, across ML, backend, frontend, real-time infrastructure, and design.

What I learned

That honesty about limitations is a feature, not a weakness. Being upfront that the model currently trains on synthetic (SNI-distributed) data rather than real field data, and that the buyer pool is currently a demo, not verified live international buyers, makes the whole product more credible, not less.

That real-time systems introduce a different class of bugs than typical CRUD apps, particularly around self-referential edge cases (a user acting as both buyer and seller) that don't show up until you actually test with multiple concurrent sessions.

That infrastructure and deployment can eat as much time as the actual product if you let it, and that knowing when to cut losses and fall back to a simpler, more reliable setup is its own kind of engineering judgment.

What's next for Vanility

Partnering with BRIN or local cooperatives to replace synthetic training data with real field data from Indonesian vanilla farms.

Onboarding actual verified export buyers, moving from a demo presence pool to a real, trust-verified marketplace layer.

Expanding the model beyond vanilla to other Indonesian spice commodities facing the same structural problem, like nutmeg and cloves.

Exploring a computer vision component that can analyze photos of cured vanilla pods directly, adding physical inspection (moisture, color, surface condition) on top of the current process-duration-based grading.

Built With

Share this project:

Updates