What ECOU is

ECOU is a voice-first product ordering platform for Romania. A buyer speaks what they need into a phone, something like "am nevoie de mere lângă Timișoara" (I need apples near Timișoara). The system listens, works out what they actually want, finds nearby farmers who carry it, and sends those farmers a message so they can call the buyer back. In the POC, the path from speaking to a farmer receiving the message takes a few seconds.

The interesting part of the platform is the piece in the middle: a single AI call that hears the audio, transcribes it, and pulls out the structured order all at once. There is no separate speech-to-text step. And the model is never trusted to be right on its own. Everything it produces is checked against the real database before anyone gets a message.

The problem

Romania has tens of thousands of small farms. A buyer, whether that is a restaurant, a shop, or a family wanting fruit in bulk, has no reliable way to find who has what, where, and at what price.

Today the whole thing runs on word of mouth and the weekly local market. If a buyer in Timișoara wants 200 kilograms of apples and their usual supplier is out, their choices are to drive to the next market, ask around, or post in a WhatsApp group and hope. None of those tell them about a farm one county over that has exactly what they need and would be glad for the sale.

For the farmer it is worse. A small farm has no website and no listing. Their reach ends at whoever shows up on market day. Growing the business means a bigger stall, not a wider audience.

The information already exists. A farmer in Arad has apples at a price, and a buyer in Timișoara wants apples in a quantity. The gap is that nobody has ever connected the two, because there was no system to do it.

Why voice

ECOU is built around voice, and the reasoning is straightforward. A lot of the people it is meant for are more comfortable speaking their needs out loud in Romanian than tapping through a search screen. A sixty-year-old buyer who has never used a filter can say "vreau zece kilograme de roșii lângă Cluj" (I want ten kilograms of tomatoes near Cluj) and mean something exact. The job of the system is to catch that meaning and act on it.

Voice also picks up detail that a form throws away. A spoken request might include a variety like "mere Golden", a delivery note, or a name. A dropdown of sixty-one products invites none of that. The model captures everything it hears, and the parts that do not fit a neat field travel along as a note attached to the message.

The risk voice brings, and how ECOU handles it

Voice has one failure mode that matters more than any other: quiet wrong answers. Speech recognition can hear "Bacău" as "Bihor" and the system would happily send the wrong county. Numbers are even worse. A misheard phone number means the message is sent, the farmer calls, nobody answers, and everyone’s time is wasted with no error showing up anywhere.

So the entire pipeline is built on the assumption that the model will be wrong sometimes, and the job of the code around it is to make "wrong" recoverable instead of harmful. The hardest part of building ECOU was never making the AI work. It was making the AI’s mistakes harmless.

That single idea drives most of the decisions below.

How it works, start to finish

Here is the path a request takes:

• The browser records the buyer’s voice.
• One Gemini call transcribes it and pulls out the order at the same time.
• The system checks what is missing. If the product or the location did not come through, it asks one spoken follow-up question and reopens the microphone. It will do this at most twice.
• A confirmation screen appears. The buyer reviews every field, fixes anything that is wrong from a dropdown, and types their phone number.
• The system finds matching producers in the buyer’s county, widening to neighbouring counties only if the home county has nobody.
• A small check gate (a simple sum) sits in front of the send button.
• The system sends a message in Romanian to each matched farmer, with the product, the amount, the location, and the number to call.

That flow looks like a straight line, but the decisions that matter are at the branches.

The one decision that holds everything up: no message sends unreviewed

The obvious shortcut would be to send messages automatically, straight after transcription, with no human review. ECOU deliberately does not do that.

Machine transcription must never send on its own when the result lands on real people and cannot be undone. A misheard product name means five farmers get a message about something nobody asked for. A wrong county means farmers in one region get a message meant for buyers in another. There is no unsend.

The point is not that the model is bad. It is that even a good model is wrong sometimes, and the cost of being wrong here is not a retry, it is somebody else’s afternoon. The confirmation screen costs the buyer about three seconds. Skipping it costs farmers false leads and costs the platform its credibility.

So the confirmation screen sits at the centre of the product. Everything else can be revised. This one holds the whole thing up.

The AI pipeline

This is where real engineering lives.

One call, not two

A normal voice pipeline runs speech-to-text first, then hands the transcript to a second model to pull out the details. ECOU skips the middle. Gemini gets the raw audio and returns structured data in a single pass.

This is not only faster; it also removes a whole processing step. In a two-step setup, the transcript can look perfectly fine to a human while the second model reads it differently. A Romanian accent on "Timișoara" might come out as "Timishwara", which a person reads without a second thought but a model trained on the standard spelling can trip over. When the same model hears the audio and pulls out the meaning, it settles the accent at the source instead of inheriting a bad transcript.

The model picks from reality, it does not invent

The core rule is that the model is instructed to select products and places only from the supplied catalogue. The instructions contain the full catalogue: sixty-one products with their Romanian and English names and their IDs, all forty-two county-level administrative units with their localities, and the available counties. The model has to return an ID from those lists, or return nothing.

If it returns nothing, the system asks a follow-up question, which is easy to recover from. If it returned an invalid ID, it could lead to the wrong farmers being selected, so the instructions are blunt about it: pick from the list, and if nothing clearly matches, say so rather than guessing at the nearest thing.

Because both language names are listed for every product, "I need apples", "am nevoie de mere", and "vreau niște mere Golden" all land on the same ID.

Grounding is a hope. The check is the guarantee.

Telling a model to pick from a list is a good technique, but it is not a promise. A model that was handed sixty-one product IDs can still return an invalid one if it gets confused enough. So after the model answers, a verification step runs over everything it returned. Every ID is checked against the real catalogue held in memory. A product ID that does not exist becomes nothing. A city ID that does not exist becomes nothing. If the county and the city disagree, the city wins, because it is the more specific signal. A language code that is not Romanian or English falls back to whatever the interface is set to.

The result is simple to reason about: once that step has run, a product ID that is still there corresponds to a real entry in the catalogue. The rest of the code can treat it as a database key without a second thought.

A few smaller decisions that matter

• Temperature set to zero. Pulling an order out of speech is a reading task, not a creative one. Temperature is set to zero to minimize sampling variability and make extraction more consistent.
• Arithmetic stays in code. The model is told never to do maths and never to convert units. If the buyer says "two crates", it returns two and "crate". If they say "half a ton", it returns 0.5 and "t". The conversion to kilograms happens in ordinary code with a table that can be tested. A model quietly turning "two and a half crates" into a kilogram figure is doing sums nobody can check.
• Phone numbers are never taken from voice. Spoken digits are especially error-prone in speech recognition, so the phone number is always typed on the confirmation screen, never guessed from audio.
• It works in both languages. The system detects the language the buyer actually spoke and carries it forward. A Romanian speaker who landed on the English page still gets Romanian follow-up questions. The farmer’s message, though, is always in Romanian, because the farmer is Romanian no matter what language the buyer used.
• It can hold a short conversation. If the first answer is missing the product or the location, the system asks one question, remembers what it already knows, and merges the new answer in. It stops after two rounds, so the buyer never feels interrogated. Past that, a plain form appears.

The rest of the engineering

The AI is the hard part, but plenty else had to be right for the path to work.

Finding nearby farmers without GPS

A map-based radius search would be the textbook answer, but at this stage no farmer has real coordinates on file. So distance is modelled as a map of which county-level areas touch which. Matching looks in the buyer’s own county first, then widens to neighbouring counties only if the home county has nobody.

Widening is all or nothing. If there are three farms in the buyer’s own county, the system shows those three and does not mix in farms from two counties over. Within the home county, someone in the buyer’s actual city sorts first, then price breaks any ties. When real coordinates exist one day, only the piece that returns candidate counties has to change. The rest stays the same.

Keeping messaging costs down

When SMS is used, Romanian diacritics can force Unicode encoding, reducing the number of characters available per SMS segment. For that reason, outgoing SMS text is normalized to plain ASCII where appropriate. The proven end-to-end POC path, however, uses WhatsApp Cloud API.

Guarding the send button

A few layers protect against both mistakes and abuse:

• Send once. A request that has already been sent cannot be sent again. This is enforced server-side so duplicate submissions from a double-click, refresh, or retry do not create another send.
• Rate limits. Three of them, stacked, because each catches a different problem: a per-IP hourly cap, a per-session cap, and a hard daily ceiling on total messages that bounds the bill no matter what. A mistyped phone number or a failed check does not burn one of the buyer’s attempts. Only a real send counts.
• A simple check gate. The confirmation screen asks the buyer to solve a small sum, signed by the server so the answer cannot be forged. It is a speed bump, not a lock. Its job is to make scripting the send endpoint cost something. The daily ceiling is what actually caps the damage.

Getting a real message to a real phone

Three ways to send are built in behind one common interface: a mock one for development, Twilio, and WhatsApp Cloud API direct from Meta. The one proven end to end is WhatsApp Cloud API. During testing, it delivered the app’s real message to a phone with the right product, place, quantity, and callback number. The test setup used the provider’s allowed-recipient constraints and reply window.

One rule the platform sticks to: never treat "accepted" as "delivered". Provider acceptance is not the same thing as successful delivery, so the system should rely on provider delivery status when available rather than assuming that acceptance means the phone received the message.

The vendor portal

Every onboarded farmer on ECOU has their own login and dashboard. They sign in and see the listings held for them and the buyer requests that matched them, all in one place. An admin still manages the master catalogue behind the scenes, but the farmer no longer depends on anyone to know what demand is coming their way.

What the portal gives a farmer

Turning a farmer into an account took two new fields on the existing producer record: an email and a password. There is no separate user table and no extra plumbing. A vendor is simply a producer who happens to have a password. That is the smallest change that gives them a way to log in.

On top of that sit three pages, each locked behind a login check:

• Overview: Two summary cards and a table of the farmer’s most recent matched leads.
• My Products: A table of the farmer’s listings: product, price per kilogram, stock, and status.
• Orders: Every buyer request that matched this farmer.

How login works

Farmer login runs on a signed cookie, a light approach used across the whole platform rather than a heavy third-party login system. It is one small file and no extra dependencies, and it keeps the sign-in fast and simple.

Farmers are onboarded by the admin

A farmer does not register on their own. The admin sets their email and password when creating or editing them, and hands the farmer their login. This suits a curated network. The admin vets every farmer before they join, so the farmer list stays clean and every account belongs to a real, known producer.

Orders: the demand coming their way, in one place

The Orders page shows every buyer request that matched the farmer: what was wanted, how much, where, and the buyer’s number to call back. Each one is marked once the farmer has been notified. It is the farmer’s own view of the demand heading toward them, so a lead never gets lost in a message thread. From here the farmer picks up the phone and closes the deal.

What ECOU does today, and what comes next

What works today

• The voice-to-order path. Romanian speech becomes checked, structured data in a couple of seconds.
• The "pick from reality, then verify" pattern. In the POC test set, no invalid product or place ID passed the validation layer.
• The county-neighbour approach, which gives the same "nearby first, then wider" feel a map search would, with no coordinates.
• Real messages reaching real phones with the right content.
• Romanian and English are both supported, including spoken quantities and units.
• The confirmation screen catching the model’s mistakes before they reach a farmer.
• A vendor portal where onboarded farmers log in and see their listings and their matched buyer requests.

On the roadmap for the full product

• On-platform ordering and payments, so a deal can close inside ECOU instead of over the phone.
• Self-service farmer signup and full listing management from the vendor dashboard.
• Consent and opt-out flows for messaging at scale.
• Shared storage so rate limits and caches hold steady across many servers.
• A commercial bot-check provider and delivery-and-read confirmation on every message.
• An automated test set of recorded samples that checks the model before each release.

Need support with a similar project?