Most software projects do not fail because the engineering was wrong. They fail because the system was built against a description of the business rather than the business itself, or because a working system was introduced in a way the operation could not absorb.
This article documents how Truffaire actually builds — the sequence, the principles behind it, and the parts that are unglamorous and decide the outcome anyway. It is written for anyone evaluating whether to work with us, and for anyone who wants to use the method without us.
Requirements documents describe intentions, not operations
The standard opening move in software delivery is to gather requirements: meet the stakeholders, write down what the system should do, get it signed off.
The problem is that a requirements document records what people believe happens. Operations run on something else — habits, workarounds, undocumented exceptions, and knowledge held in individual heads. The gap between the two is where projects die.
A manager will describe a stock process that is accurate as an intention. The person actually doing it has a workaround for the case the process does not cover, and that case is a third of the volume. Nobody is lying. The workaround simply became invisible through repetition.
So the first phase is watching, not asking
We begin by sitting in the operation and documenting how it currently runs — including paper, chat threads, and the exceptions people stopped noticing. What we are looking for specifically:
- Where the same information is entered more than once
- What people do when the official process does not fit
- Which numbers are trusted, and which are quietly re-checked
- What actually happens at the busiest hour, not the calm one
- Which knowledge exists in exactly one person
That last one is usually the most valuable finding, and it is never in a requirements document.
Configuration in the vocabulary that already exists
A system that uses different words than the staff do imposes a translation on every user, on every interaction, permanently.
It seems minor in a demo. In production it decides adoption. What one business calls a consignment another calls a dispatch; what one measures in cases another measures in kilograms. Forcing a shared vocabulary onto an operation is a cost paid every day by the people least able to refuse it.
So we configure to the terms already in use. This is also why we have built ten systems that are genuinely different rather than one product deployed ten times — a multi-outlet retail ERP, clinic management, inventory, warehouse, delivery, logistics, production monitoring, factory operations, and billing and operations management. Same architecture underneath, different language and shape on top.
Fewer modules, actually used
The instinct when specifying software is to ask for everything the business might eventually need. We push against this consistently.
A module nobody updates is worse than no module, because it displays stale data with the same confidence as fresh data — and people make decisions on it. The strongest deployments we have run are the narrow ones: fewer functions, all of them genuinely used, all of them trusted.
Three principles that decide what ships
The counter comes first. The system must be usable by staff during the busiest hour, not during a calm evaluation. Usability under pressure decides what ships, not feature count. A feature that cannot be operated at peak will be bypassed, and a bypassed system produces data nobody trusts.
Focused screens, not dashboards. Every screen shows what a decision needs and nothing else. Decorative analytics cost attention and return nothing. If nobody acts on a chart, it should not be there.
Every day must close clean. Operational health is measured by how fast the day closes and how quickly a problem becomes visible. Same day, every day — not a monthly reckoning that discovers a three-week-old error.
Deployment is the risky part
Most failures we have seen are not engineering failures. The software works and the rollout breaks the business.
Our sequence is deliberate:
- Document the operation as it actually runs
- Build configured to that operation, with only the needed modules
- Re-test with the staff who will use it, and redesign what is awkward before launch
- Deploy gradually, location by location, alongside existing systems
- Train counter staff in days rather than weeks, in their own terminology
- Switch off legacy systems only once the new one has been proven live
Steps four and six are the ones under commercial pressure to skip. Running both systems in parallel costs duplicated effort for a short period. An outage in a live operation costs considerably more, and the trust does not come back on the same timeline as the software.
Migration is not an afterthought
Years of transaction history, customer records and stock positions have to move before launch. This is a substantial share of the work and a common place for projects to fail quietly — the system goes live, and then someone discovers the historical data did not come across cleanly.
Any deployment plan that treats migration as a final step is worth questioning.
Why we do not build MVPs
We have written about this at length elsewhere, and it follows directly from the above.
An MVP is a reasonable instrument for testing whether a market exists. It is a poor instrument for a business that already has an operation running, because the thing being tested is not demand — it is whether the system can carry real work. A minimum version deployed into a live operation does not produce learning. It produces an outage with a hypothesis attached.
What we tell people not to buy
If a business is single-location, with simple stock, and one person holds the complete picture, we say the accumulated stack of tools is doing its job and replacing it is a cost without a return. We have told prospective clients this.
Where a sector has a genuinely unusual regulatory structure and a mature vertical product already encodes it, buying that product is often the better decision than configuring a general one. Choosing between vertical, general and custom covers how to tell.
Data stays exportable in standard formats. A system you cannot leave is a system you are hostage to.
Where this shows up
The method above is what produced SPEXA, the business operating system behind those ten deployments, and it is the same discipline applied in ARCORA and SYNTAX — different domains, same refusal to ship something we would not depend on ourselves.
The underlying position is in what it means to build a system that endures, and the failure mode we build against is in why most business software breaks at the counter. The systems page covers the products themselves.
Frequently asked questions
How long does a typical engagement take?
Weeks rather than months for the deployments we have run. The variable is rarely engineering — it is how much of the operation is documented versus living in people's heads. A business with clean records moves quickly.
Do you work on existing systems or only new builds?
Both. Frequently the correct answer is not a new system but fixing the handoffs between existing ones. If an integration solves the problem, that is a cheaper and better recommendation than a rebuild.
Who owns the code and the data?
The data is yours and stays exportable in standard formats. Ownership terms for the software are agreed per engagement, and we recommend settling them before work starts rather than at renewal.
What happens after launch?
Continuous adaptation. An operation changes, and a system that cannot change with it becomes the next legacy tool. Maintenance is a phase of the work, not an add-on to it.
Will you say no to a project?
Yes, and we do. If the operation does not need the system, or a vertical product fits better, or the timeline forces skipping the deployment steps above, the honest answer is no.
Where to start
If you take one thing from this: document how the work actually happens before anyone specifies software. Not the process as described — the process as performed, including the workarounds.
That document is what any competent partner should ask for first. If nobody asks for it, that tells you something about how the project will go.
If you want to talk through an operation, get in touch.