Every piece of business software encodes an opinion. It has a model of what a customer is, what an order is, which fields are required, and in what sequence work happens.
Where that model matches your operation, the software is invisible and helpful. Where it does not, something has to give — and it is never the software. The business adapts, and the adaptation is paid for daily by the people using it, most of whom had no say in the purchase.
This article is about what configuration actually means, where its limits are, and why the distinction between configuring and adapting decides whether a system gets used or worked around.
Three things get called configuration
The word covers work of very different depth, and vendors are rarely precise about which they mean.
Cosmetic configuration. Your logo, your colours, renaming a field label. Real, and it changes nothing structural.
Behavioural configuration. Which modules exist, what a workflow's steps are, what is mandatory, who can approve what, what the pricing rules are. This is where fit is actually decided.
Structural configuration. Whether the system's underlying model can express your reality — a transaction that behaves differently, a relationship the data model does not anticipate, a unit conversion running through everything.
Most products offer the first generously, the second partially, and the third not at all. The important question in an evaluation is not "is it configurable" — everything claims to be. It is "can it express the specific thing my operation does that is unusual".
Vocabulary is not cosmetic
Renaming fields sounds like the shallowest kind of configuration. In practice it has an outsized effect on whether a system is adopted.
If your team says consignment and the software says shipment, every user performs a small translation on every interaction, permanently. Individually trivial. Repeated hundreds of times a day, it is a tax on attention that shows up as slower work and more errors — and it makes training longer, because new staff must learn two vocabularies.
It also has a subtler cost. When software uses different words than the business, staff describe their work in the software's terms when talking to the system and in their own terms when talking to each other. The two descriptions drift, and eventually nobody is confident they mean the same thing.
Using the terms the business already uses is one of the cheapest things a system can do and one of the most consistently skipped.
Where configuration genuinely stops
Being honest about limits matters, because over-configured software is its own failure.
When the data model cannot express it. If the system assumes one price per product and your reality is customer-specific pricing with volume breaks and retrospective rebates, no amount of configuration produces that. This is a structural mismatch, and the honest conclusion is a different system.
When configuration becomes programming without the discipline. Products with deep customisation can be pushed into becoming bespoke systems — with no tests, no documentation, and no one who understands the accumulated rules. The result has the constraints of a product and the obligations of custom software. It is the worst position of the three in off-the-shelf or custom.
When you are configuring around a process that should change. Sometimes the operation's workflow is habit rather than advantage, and a well-designed product's default is simply better. Encoding a bad process into a new system is a common and expensive way to preserve it.
That last one requires honesty that is difficult to apply to yourself, and it is the main reason our first phase is watching the work rather than collecting requirements.
How we decide what to configure
Our position, from how Truffaire builds software: document the operation as performed, then configure to it — but not indiscriminately.
Three tests we apply to any difference before encoding it:
Is it structural or vocabulary? Vocabulary gets matched, always — it is cheap and it decides adoption. Structural differences get examined properly, because they are what determines whether the architecture fits at all. The four categories that mark a genuine structural difference are in choosing technology for your sector.
Does it exist for a reason anyone can state? Many process steps exist because of a constraint that was removed years ago. If nobody can say why, that is a candidate for deletion rather than configuration.
Would a new employee find it sensible? Long-serving staff stop noticing the strange parts of a process. Someone new is a useful instrument for identifying them.
The aim is not to preserve the operation exactly. It is to preserve what is deliberate and remove what is residue.
Why this produces different systems each time
Truffaire has delivered ten systems on the same underlying architecture — a multi-outlet retail ERP, clinic management, inventory, warehouse, delivery, logistics, production monitoring, factory operations, and billing and operations management.
They are genuinely different systems, and what varied between them was rarely the structure. It was language, which modules existed at all, reporting, and the specific regulatory obligations. Same architecture, ten shapes.
That is the practical argument for the configured middle option: the shared foundation carries the parts every business needs identically, and the configuration carries the parts that are actually specific. Building all of it bespoke pays for the shared parts repeatedly; buying a fixed product pays for the specific parts in daily friction.
Frequently asked questions
How do we know if a product can be configured enough?
Ask the vendor to demonstrate your three most unusual processes on your own data, not the demo set. If they configure it live, you have your answer. If they describe how it could be done, you do not.
Does configuration make upgrades harder?
Behavioural configuration usually survives upgrades. Deep customisation frequently does not, which is one of the strongest arguments for staying within a product's intended configuration surface.
Should we change our process to fit good software?
Sometimes yes. If the process is habit rather than advantage, and the product's default is well designed, adopting it is an improvement rather than a compromise. The judgement is whether the process is why customers choose you.
Who should decide what gets configured?
The people doing the work, with someone able to challenge whether each difference is deliberate. Configuration decided only by management encodes the process as described rather than as performed.
How long does configuration take?
Weeks rather than months in our experience. The variable is how much of the operation is documented versus living in people's heads.
Where to start
List the ways your operation differs from a generic version of your business. For each one, answer two questions: is it structural or vocabulary, and can anyone state why it exists?
Most lists shrink considerably under that pair of questions. What survives is what actually needs configuring — and it is usually specific enough to evaluate a product against.
If you want a read on which of your differences are real, get in touch.