A client asked us to automate something their ERP simply cannot do. The fastest way to say yes would have been the wrong thing to do, and understanding why is the clearest explanation of technical debt we can give.
A few days ago a food manufacturer reached out to us through a partner. Their request was concrete and completely reasonable: they prepare their products from a handful of fixed recipes, mixture one, mixture two, mixture three, and on every production run somebody re-enters those recipes into the system by hand. They wanted to stop doing that. They wanted to automate the mixtures.
It sounds like a small integration job. It is not. And the reason it is not is the whole point of this article.
What technical debt actually is
The term was coined by the programmer Ward Cunningham as a metaphor, and it is a good one. Shipping a quick, imperfect solution is like taking out a loan. You get something that works today, but you pay interest on it forever, a little extra effort every single time you touch the system, until you pay down the principal by doing the job properly.
Debt is not automatically a bad thing. Sometimes you take it on deliberately and with open eyes: a real deadline, a market window, a proof of concept you already know you will throw away. What makes debt dangerous is taking it on without noticing, or taking it on to paper over a problem that will never actually go away.
The worst kind of technical debt is the kind you can never repay, because it sits on a foundation you do not own.
The real problem, not the surface one
The client runs their business on Distrito K / SQL-PYME, a Spanish ERP built on a Firebird database. It has an API, and on paper that is good news: an API means we can integrate cleanly instead of poking at the raw database underneath.
So we read the API documentation carefully, from end to end. And here is the finding that changes everything. The API covers commercial management and the warehouse: customers, articles, stock, sales and purchase documents, stock movements. It does not expose a single manufacturing object. No production order. No bill of materials. No recipe, no "escandallo". You cannot even define the components of an article through it.
Now read the client's request again with that in mind. They asked us to automate their mixtures. A mixture is, by definition, a manufacturing operation: components go in, a finished product comes out, following a recipe. That is exactly, precisely, the one thing their ERP's API cannot represent.
The tempting patch
There is always a way to make it "work". You build a bridge. You read the master data, articles and stock, out of the ERP through its API. You model the recipes and the bill of materials in a second system that does understand manufacturing. You run the calculation there. And you write the result back into the ERP as a plain stock movement, because a stock movement is one of the few documents the API will accept.
On a slide it looks clean. In production it is a patch, and a patch charges interest:
- The real problem is still there. The ERP still cannot manage a manufacturing order. You have not given it that ability, you have only hidden the gap behind a second system.
- Now there are two brains. The recipes live in one place; the stock, the prices and the invoicing live in another. Every article, every unit, every price has to be kept in sync across a fragile link, forever.
- The link is fragile by design. The API is stateful, it allows a single session per user, and that session expires. Just to reach the client's server you need a dedicated machine sitting on their network and a private tunnel. None of that solves the client's problem: it is scaffolding whose only job is to hold the patch up.
- Every future change costs more. A new type of mixture, an extra field, a version upgrade of the ERP, each one now has to be handled twice and re-tested across the bridge.
That is the interest. You pay it every month, forever, and at the end of it you still do not own the one thing you actually needed: a system that manages your production.
Why we do not recommend the patch
We could have built it. It is real, billable work, on the order of a hundred and fifty hours of it. Saying yes would have been the easy and profitable answer.
But our job is not to sell hours. It is to leave a client better off than we found them. A bridge that permanently props up a tool which structurally cannot do the job does the opposite: it adds complexity, it adds points of failure, and it locks the client into paying interest on a debt that never gets paid down. That is not a solution. It is a subscription to a problem.
The honest answer is the harder one to say out loud: the mixtures are a manufacturing problem, so they belong in a system that was built to manage manufacturing.
The way out of debt
The right move is not to patch around the gap, it is to close it. Take the part the current ERP cannot do, production, recipes, bills of materials, manufacturing orders, and move it into a system that handles it natively.
That is exactly what a full ERP with a real manufacturing module does. In Odoo, for example, the MRP module treats recipes (bills of materials), manufacturing orders, component consumption and finished-goods output as first-class objects. The mixture that today somebody re-types by hand becomes a manufacturing order the system already understands: no bridge, no second brain, no tunnel holding up a patch.
It is more work up front than a quick integration. It is also the last time you pay for it. Instead of renting a workaround forever, the client owns the capability.
The takeaway
Technical debt is not just messy code. It is the distance between the quick answer and the right one, plus the interest you quietly agree to pay on that distance for as long as the system stays alive.
Some debt is worth taking, knowingly, with a plan to pay it back. The debt to avoid at all costs is the debt you take on to hide a problem you can never fix at its source. That is not a shortcut. It is a mortgage on somebody else's foundation.
Sometimes the most valuable thing a technology partner can tell you is: "we should not build this." We said it. That is the whole article.