Skip to content
All posts

Where the ERP stops: extending Winthor at Coagro

4 min read
Grupo Coagro logo on a black background with a technical grid

Winthor is Grupo Coagro’s ERP and it is going to stay that way. Inventory, invoicing, price tables, customer records, receivables: it is all there, it works, and nobody on the team wants to touch it.

That is why the interesting question was never “replace or keep”. It is a narrower and far more useful one:

Where do the ERP’s rules end and the business’s rules carry on?

A distribution ERP is designed for the general case — what holds equally for someone selling bolts, medicine or crop protection. That is what makes it dependable across twenty years, and it is exactly what leaves edges: the part of the business that is not “generic distribution” has no reason to live inside it.

The work lives on those edges. Not replacing what Winthor does — adding the rule it would have no reason to carry.

Three places where the edge shows

The order exists. The conversation leading to it does not.

The ERP records orders. But an order is the end of a sequence: a farm visit, a crop diagnosis, a recommendation, a quote, negotiation, follow-up. None of that is a sale yet, which is why none of it fit where sales live.

With nowhere to go, that sequence stayed in the salesperson’s head and notebook. It works — while they are there. The day they go on holiday, the account goes with them.

The CRM covers that stretch, and only that. It reads from Winthor what is already true (customer, purchase history, credit limit, available stock) and holds what has not become an order yet. When it does, the order is born in the ERP, where it always was.

Built in Flutter because an input salesperson works on the farm, not at a desk. A CRM that only opens on desktop becomes a nightly, from-memory exercise — when it gets filled in at all.

Issuing an agronomic prescription is an act carrying technical liability: product, crop, target pest, dose, area, responsible agronomist and signature, within what the law allows for that combination. It is not a text field — it is a rule that validates before it prints.

That is precisely the kind of rule a distribution ERP has no reason to carry: it does not apply to someone selling bolts. It applies to us, and getting it wrong is not rework, it is regulatory risk.

The tool pulls from the ERP what already exists — product, customer, what was purchased — and applies on top the rule the ERP does not know. The agronomist stops typing what the system already knows and goes back to deciding what only they can decide.

“Remembering every system” is not access control

Every new tool arrives with a tedious question: who gets in? Solved tool by tool, the answer becomes one login per system — and offboarding someone starts to depend on remembering all of them.

Remembering is not a control. It is an intention.

Centralising access was not user convenience. It is the difference between revoking access and hoping you revoked it — and in a company handling credit and customer data, that difference has a name: audit.

The principle that held it together

Looking at the three cases side by side, the pattern is the same:

The data belongs to the ERP. The new rule is ours. And the rule never copies the data.

If the information already has an owner in Winthor, it is queried, not replicated. Duplicating is faster to write and cheaper to read — which is exactly why it is tempting. The bill arrives later, the day the two copies disagree and nobody knows which one is right. Nobody wants to find that out from the customer.

What Supabase holds is only what was born with the tools and does not exist in the ERP: session, permission, draft visit, the note that has not become an order yet.

What is still hard

Reading from a database that is not yours means treating its schema as an API you do not control — no versioning, no changelog, no coordinated deploy. A column that changes meaning does not announce it; it simply starts returning something else.

The defence is the usual one, and it is not sophisticated: fail loud. An integration that breaks quietly hands back a plausible number, and a plausible wrong number is the most expensive defect there is — because nobody goes looking for what did not raise an error.

What I take from this

“Modernising the ERP” almost never means replacing the ERP. It means mapping precisely where it is right — usually most of it — and building only on the edge where the business asks for a rule it does not have.

Winthor is still the source of truth. What changed is that it no longer has to answer, alone, questions that were never its own.

Keep reading

Comments