DEV Community: Truffaire

Operational Dashboards People Actually Use

Truffaire — Thu, 05 Nov 2026 04:30:00 +0000

Almost every business software project produces a dashboard. Almost every dashboard is opened enthusiastically for two weeks and then not at all.

The usual diagnosis is that people need training, or that the dashboard needs more data. Both are wrong, and adding more data reliably makes it worse.

Dashboards fail because they answer questions nobody was asking. A screen full of accurate, well-presented numbers that do not change what anyone does is a screen with no reason to be opened. The ones that survive share a single property: every element on them is attached to a decision somebody actually makes.

The test each number should pass

Before a metric appears on a dashboard, it should survive three questions.

Who looks at this, and when? Not "management" — a specific person, at a specific point in their day or week. A number without an owner and a moment is decoration.

What would they do differently? If the figure is high, what happens? If it is low, what happens? If the honest answer is "nothing, it's just useful to know", it does not belong on an operational dashboard.

How quickly do they need it? A figure reviewed monthly does not belong on a screen checked daily. Different cadences want different surfaces.

Most metrics fail the second question. That is the filter that does the work.

Awareness and action are different screens

The most common design error is mixing two purposes.

Awareness answers how are we doing — revenue, volume, trend. It is reviewed periodically, it is interesting, and it rarely triggers an immediate act.

Action answers what needs attention now — stock below reorder, invoices past due, variance beyond threshold, an outlet that has not closed its day.

They belong on different screens because they are consumed differently. Awareness is reviewed on a cadence. Action should be checked whenever there might be something to do — and if action items are buried among charts, they are missed.

The practical consequence: an operational dashboard should mostly be a list of exceptions, not a wall of charts. If nothing needs attention, it should say so and be short.

Why more data makes it worse

When a dashboard is not being used, the instinct is to add to it. This is exactly backwards.

Every additional element costs attention and dilutes the signal. A screen with six numbers where two matter is a screen where the two get missed. A screen with thirty is not opened at all.

Our position is focused screens, not dashboards — every screen shows what a decision needs and nothing else. Decorative analytics cost attention and return nothing. It is one of the three principles that decide what we ship, described in how Truffaire builds software.

The discipline is subtraction. A useful review question is not "what else should we show" but "what could we remove without changing any decision".

What belongs on an operational screen

For most operations, a short list:

Exceptions requiring action today — with enough context to act, not just a count
Yesterday's close — did the day settle, and was there variance
Anything below a threshold — stock, cash position, margin
Anything overdue — receivables, deliveries, follow-ups
A single trend line for the one number the business steers by

Notice what is absent: breakdowns by every dimension, comparisons nobody requested, and charts that exist because the data was available.

Exceptions need context, not just counts

"14 items below reorder level" is a number. It requires the reader to go and find out which, how far below, and whether it matters.

"14 items below reorder — 3 are fast-moving and will stock out this week" is a decision. The work of interpretation has been done by the system rather than deferred to the person.

That difference decides whether a dashboard saves time or creates it.

Where dashboards get abandoned

Stale data. If the numbers are yesterday's and the decision is today's, the screen is worse than useless — it is confidently wrong. This is the strongest argument for a shared record: figures derived from one source are current by construction rather than by a sync schedule. It is the architecture in what a business operating system actually is.

Numbers that disagree with reality. One instance of a dashboard contradicting what someone can see with their own eyes destroys trust in the whole screen, permanently and reasonably.

Requiring interpretation. If reading it needs a mental calculation, it will be skipped when busy.

Built for the buyer, not the user. Dashboards specified by an owner and used by a manager frequently answer the owner's questions. The manager opens it twice.

No mobile reality. Most operational checking happens on a phone, often away from a desk. A dashboard that only works on a large screen is checked far less than one designed for the device it is actually opened on.

What we have seen

Dashboards appear in most of the ten systems we have delivered. The pattern is consistent: what gets used long-term is narrower than what was originally requested.

Clients typically ask for comprehensive visibility. Six months in, the screens still open daily are the exception lists — what needs attention, what did not close, what is below threshold. The comprehensive analytics are reviewed occasionally, if at all, and usually by one person.

The other finding is that the most valuable screen in an operation is frequently the daily close: did yesterday settle, and if not, by how much. It is unglamorous, it is one number with a variance, and it is checked every morning — because it is attached to something the person is accountable for.

That is the whole principle. Attachment to accountability is what makes a number get looked at.

Frequently asked questions

How many metrics should a dashboard have?

Fewer than you think. For a daily operational screen, five to seven elements is generally the ceiling before attention disperses. If more seems necessary, it is usually two screens for two audiences.

Should everyone see the same dashboard?

No. A counter supervisor, an outlet manager and an owner make different decisions and need different screens. One shared dashboard is a compromise that serves nobody particularly well.

Real-time or periodic?

Match the decision. Stock and daily close benefit from being current. Monthly trends do not need real-time and updating them constantly adds noise. Real-time everything is a cost with no corresponding benefit.

What about alerts instead of dashboards?

Often better for the action category — if something needs attention, pushing it is more reliable than hoping someone checks. The risk is volume: alerts that fire too often get muted, and then the important one is muted too.

How do we know if ours is working?

Look at whether it is opened, and by whom. If a screen is not being checked, do not add to it — remove from it, or ask the person what they actually needed to know.

Where to start

Take your existing dashboard and, for each element, name the person who acts on it and what they do differently based on it. Remove anything that fails.

What remains is usually a short list of exceptions and one or two trends. That is the dashboard people will actually open — and it will be more useful than the comprehensive one it replaces.

If nothing survives the filter, the honest conclusion is that the screen was built because dashboards are expected, not because a decision needed support. That is worth knowing before investing further in it.

SPEXA treats dashboards as exception surfaces first. If you want a read on which of your numbers are actually load-bearing, get in touch.

Originally published at truffaire.in.

Systems Thinking: Why the Best Technology Disappears Into the Background

Truffaire — Wed, 04 Nov 2026 04:30:00 +0000

You do not think about the electrical grid. You plug in a device, and it works. You do not think about the water treatment system. You turn on a tap, and the water is clean. You do not think about the GPS satellite network. You enter a destination, and you are guided there.

These systems — electricity distribution, water treatment, satellite positioning — are extraordinarily complex. They represent decades of engineering, millions of components, and the coordinated effort of thousands of institutions. They also share one defining characteristic: they are invisible.

The invisibility is not accidental. It is the achievement.

What Invisibility Means

A system becomes invisible when it reliably does what it is supposed to do, every time, without requiring the user to understand how it works or manage its complexity. The electrical grid is invisible because when you plug something in, you do not need to think about generation, transmission, distribution, or voltage regulation. The system handles all of that. You experience only the outcome: a working device.

This kind of invisibility requires solving a specific set of engineering problems that are distinct from the problems of making a system functional.

Reliability is the first requirement. A system that works ninety percent of the time cannot become invisible. Every failure brings the system into consciousness — the user becomes aware of it in the moment it fails to do what they expected. A power outage makes people acutely aware of the electrical grid. A contamination event makes people acutely aware of the water treatment system. Reliability is what allows a system to fade into the background of daily life.

Simplicity of interface is the second requirement. A system that requires user management and attention cannot become invisible. If using the electrical grid required setting voltage parameters and managing load, nobody would be unaware of it. The interface — the plug socket, the switch — is so simple that the act of using it requires almost no conscious effort.

Appropriate scope is the third requirement. Systems become invisible when they do exactly what they are supposed to do and nothing else. A system that periodically asks users to make decisions they did not expect to make, or that generates outputs they did not ask for, keeps itself in consciousness.

Why Technology Products Fail at Invisibility

Most technology products are designed to be noticed. This is partly a function of the market dynamics of technology — differentiation requires visibility, adoption requires awareness, growth requires attention. But it is also a function of a design culture that conflates complexity with value.

A product with many features is visible because navigating the features requires ongoing attention. A product with a complex interface is visible because using it requires conscious effort. A product that frequently asks for user input is visible because it keeps inserting itself into the user's awareness.

This is fine for products where the value is in the complexity — professional tools, creative platforms, analytical software where the user's engagement with the complexity is part of the value. It is a serious problem for systems that are supposed to improve the background conditions of work rather than become work in themselves.

An agricultural diagnostic tool that requires a farmer to navigate multiple menus, enter contextual information, and interpret probabilistic outputs is not a background system. It is another thing the farmer has to manage, in addition to managing their farm. The tool's complexity competes with the farm for attention, and the farm usually wins.

Designing for Invisibility

Designing a system for invisibility requires a specific inversion of the usual technology design question.

The usual question is: what can this system do? The answer to this question tends to expand over time — more features, more capabilities, more surface area.

The question for invisibility is: what does the user need to do, and how can the system do everything except that? The answer to this question tends to contract over time — fewer interactions, simpler interfaces, more of the complexity absorbed by the system rather than delegated to the user.

ARCORA is designed around this inversion. The farmer needs to identify what is wrong with their crop and know what to do about it. Everything else — the image analysis, the disease classification, the treatment protocol lookup, the localisation into the appropriate language — is absorbed by the system. The farmer's interaction is two steps: take a photo, read the protocol. The complexity is real; the interface is not.

This is not simple to build. Absorbing complexity into a system, rather than delegating it to the user, requires that the system be genuinely capable of handling that complexity — which means higher accuracy requirements, more comprehensive training data, more thorough testing. The invisible system is harder to build than the visible one.

But it is the right goal. A tool that a farmer uses without thinking about it is a tool that actually changes how they farm. A tool they have to think about using is a tool they use rarely and eventually stop using entirely.

The best technology disappears. Building the kind of technology that disappears is the work.

Originally published at truffaire.in.

What It Means to Build a System That Endures

Truffaire — Tue, 03 Nov 2026 04:30:00 +0000

The average lifespan of a technology product is three years. Not the company — the product. Most consumer applications, SaaS platforms, and enterprise software tools either undergo such significant changes within three years that they are effectively different products, or they are discontinued.

Three years is not long enough to matter in agriculture. It is not long enough to matter in medicine. It is not long enough to matter in a business that has just rebuilt how it runs.

The systems that govern these domains operate on decade-scale time horizons. A farmer building soil health over twenty years cannot afford to have the diagnostic tool they depend on become unsupported in year four. A distributor that has moved its entire order book, its credit terms, and its stock records onto one system cannot have that system change shape underneath it.

This creates a specific obligation for anyone building technology in these domains. Not the obligation to be innovative — that is easy. The obligation to endure.

What Endurance Requires

A system that is genuinely designed to endure is different in its architecture, its business model, and its organisational philosophy from a system designed for growth and exit.

Architecturally, enduring systems are built with a conservatism about dependencies that fast-moving product teams rarely exercise. Every external dependency — a third-party API, a cloud service, a database provider — is a potential point of failure in ten years. Systems designed for longevity either own their core infrastructure or are designed to be portable across infrastructure providers with minimal friction. They use open standards where open standards exist. They document their internal workings in ways that allow a different team to understand and maintain the system if the original team is no longer available.

In their business model, enduring systems are designed so that the incentives of the builder align with the long-term interests of the user. A system whose revenue depends on users continuously upgrading to new versions has an incentive to make old versions less functional. A system whose revenue comes from genuinely useful ongoing service has an incentive to keep the system working well. The alignment between commercial incentive and user interest is a feature of the business model, not a moral position.

Philosophically, organisations that build enduring systems have made a decision about what they optimise for. They optimise for reliability over novelty, for correctness over speed, for trust accumulated over years rather than attention accumulated over days. These are not natural alignments for a technology company in an industry that rewards growth metrics and exit valuations. They require deliberate choices about what kind of institution to be.

The Failure Mode of Short-Cycle Technology

The failure mode of systems that are not designed to endure is visible throughout the technology landscape in India's critical sectors.

Digital agriculture platforms have launched, attracted farmers to their systems, accumulated data about farming practices and market conditions, and then shut down or pivoted when funding conditions changed. The farmers who had adopted these platforms were not just inconvenient — they were sometimes in a worse position than if they had never adopted the platform, because they had made decisions based on data and advice that was no longer available, and the institutional knowledge they had built around the tool was now useless.

Electronic health record systems in district hospitals have been implemented, under-supported, and eventually abandoned — leaving clinicians with hybrid paper and digital workflows that are worse than either would be alone.

Agricultural input platforms have changed their terms of service, their pricing structures, and their product offerings in ways that made business sense for the company but created operational disruption for the farmers who depended on them.

These failures are not failures of bad actors. They are the predictable outcome of building technology for contexts that require decade-scale commitment with business models and organisational cultures optimised for eighteen-month cycles.

The Truffaire Commitment

When we deploy ARCORA with a farmer producer organisation, we are not deploying a product. We are establishing a relationship with a time horizon that extends well beyond the current growing season.

The data that accumulates through ARCORA — the disease records, the treatment outcomes, the seasonal patterns, the crop-specific knowledge — is not data that we extract for our commercial benefit. It is institutional knowledge that belongs to the FPO and its member farmers. Our obligation is to make that knowledge more accessible and useful over time, not to own it.

When we configure SPEXA for a business, we are building the record that business will reason from — its stock, its ledger, its customer history — for as long as it runs on the system. A figure entered in 2025 has to still mean the same thing when someone reads it back in 2030. That is not a feature request. It is the condition under which the record is worth keeping at all.

This is not a constraint we resent. It is the core of what makes the work meaningful. Building systems that matter means building systems that last. And building systems that last means accepting the disciplines, constraints, and commitments that the technology industry has largely decided are incompatible with fast growth.

We have decided they are not. The two things can coexist. The decision to prioritise permanence is not a decision to grow slowly — it is a decision to grow in a direction that produces something worth keeping.

Originally published at truffaire.in.

What a Business Operating System Actually Is

Truffaire — Mon, 02 Nov 2026 04:30:00 +0000

Most businesses do not choose their software. They accumulate it. A billing app because the old till broke. A spreadsheet because someone needed to track stock that quarter. A WhatsApp group because the supplier preferred it. Each tool solved the problem in front of it, and each one was the right call at the time.

The result is a business running on eight or ten systems that have never been introduced to each other. Nothing is broken, exactly. But the numbers take two days to reconcile at month end, nobody can answer a simple question without opening four tabs, and every one of those handoffs is a place where a figure can quietly drift.

A business operating system is the alternative: one shared record that every part of the operation reads from and writes to. This article explains what that actually means, what it looks like day to day, and — just as importantly — when you do not need one.

What makes it an operating system rather than more software

The phrase gets used loosely, so it is worth being precise. A business operating system is not a bigger app or a bundle of apps sold together. The distinction is architectural: there is one record, and every function operates on it.

Consider a single sale at a counter. In an accumulated stack, that sale touches several systems in sequence:

the billing app records the transaction
someone later decrements the stock spreadsheet
the customer's outstanding balance is updated in a chat thread or a book
the amount is entered into accounting software at month end

Four systems, four entries, four opportunities for the number to differ. Nobody is careless — the work is simply being done four times, by people who have other things to do.

In an operating system, that sale is recorded once. Stock falls, the customer's history updates, the ledger moves, and the day's figures change — because these are not four systems being synchronised. They are four views of the same underlying event.

That is the entire idea. Everything else follows from it.

Integration is not the same thing

Software vendors often answer this problem with integrations: connectors that push data from one tool into another. Integrations are genuinely useful, and for many businesses they are the correct and cheapest answer.

But an integration is a bridge between two sources of truth, and bridges have failure modes. The sync runs late. A field does not map cleanly. One system allows a value the other rejects. Someone edits a record on one side and the change never crosses. When the numbers disagree, you now have a third question to answer — which system is right — on top of the original one.

A shared record removes the question rather than answering it faster. There is no second copy to disagree with.

The test is where the truth lives

If you want to know whether something is genuinely an operating system, ask where a given fact lives and how many places would need updating if it changed.

Change a product's price. In an operating system, you change it once. In an accumulated stack, you change it in the billing app, in the stock sheet, in the price list you send customers, and possibly in the online listing — and for the next few days, some of those will be wrong.

What one is actually made of

In practice, a business operating system covers a small number of functions that nearly every operation needs, regardless of sector. SPEXA, the system Truffaire builds, is organised around six:

Module	What it holds
Billing & sales	Every transaction, as it happens, across counters and outlets
Inventory	Live stock positions, with variance surfaced rather than discovered
CRM	Customer records, purchase history, outstanding balances, follow-ups
Accounting	Ledgers, profit and loss, exports in standard formats
Dashboards	The current state of the operation, and the exceptions worth attention
AI assist	Natural-language search and summaries over the operation's own data

The specific list matters less than the principle: these are not six applications. They are six ways of looking at one record. The CRM knows a customer's balance because it is reading the same transactions the billing module wrote.

Why the module list is shorter than you expect

A common instinct when specifying software is to ask for everything the business might conceivably need. This is usually a mistake, and an expensive one.

Every module added is a module that must be learned, maintained, kept accurate, and — critically — actually used. A module nobody updates is worse than no module, because it presents stale data with the same confidence as fresh data. The strongest deployments we have seen are consistently the narrow ones: fewer functions, all of them genuinely used.

When a business actually needs one

This is where honest advice matters more than a sales case. A business operating system is not universally correct, and the threshold is fairly specific.

You probably do not need one if you run a single location, your stock is simple enough to eyeball, and one person holds the full picture in their head. The accumulated stack is doing its job. Replacing it costs money and disruption to solve a problem you do not yet have.

You probably do need one when one or more of these has become true:

Reconciliation has become a job. Somebody spends days each month making numbers agree that should never have disagreed.
You run more than one location. The moment stock or sales exist in two places, keeping them consistent stops being a memory exercise.
The answer to a simple question takes an hour. "How much did that outlet sell last Tuesday" should not require assembling evidence.
The business is in one person's head. This is the serious one. If the only complete picture lives with an owner or a long-serving manager, the operation cannot grow or survive their absence.
You are making decisions on stale numbers. Acting on last month's stock position is guessing with extra steps.

If none of these apply, the honest recommendation is to wait. We have told prospective clients this.

How Truffaire approaches it

We have delivered ten of these systems, and no two have been the same. That is the part most software categories get wrong, and it is worth explaining why.

A retail chain with thirty-plus outlets, a clinic, a warehouse operation, a logistics business, a factory floor and a wholesale distributor do not do the same work. They do not use the same words for the same things. What one calls a consignment, another calls a dispatch. What one measures in cases, another measures in kilograms. A single product forces all of them into one vocabulary, and every user then performs a small translation, every time, forever.

So our first phase is not building. It is sitting at the counter and documenting how the business already runs — including the parts that live on paper, in chat threads, and in people's heads. The system is then configured in the terminology the staff already use.

Three principles shape what actually gets built:

The counter comes first. The system has to be usable by staff during the busiest hour of the day, not during a calm demo. Usability under pressure decides what ships, not feature count.

Focused screens, not dashboards. Every screen shows what a decision needs. A chart nobody acts on is a chart that costs attention and returns nothing.

Every day must close clean. The measure of operational health is how quickly the day closes and how fast a problem becomes visible. Same day, every day — not a monthly reckoning.

The deployment is the risky part, not the build

Most software failures we have seen are not engineering failures. The system works; the rollout breaks the business.

Our sequence is deliberate: document, build, re-test with the staff who will use it, deploy gradually location by location alongside existing systems, train counter staff in days rather than weeks, and only then switch the legacy tools off. Running both in parallel costs a little duplicated effort for a short period. It is far cheaper than an outage in a live operation.

Where SPEXA fits

SPEXA is the business operating system Truffaire builds — the six modules above, configured per client rather than sold as a fixed product. It has been deployed across ten businesses, the largest being a retail chain of thirty-plus outlets, with typical timelines measured in weeks rather than months.

Those ten deployments are ten genuinely different systems: a custom multi-ERP, clinic management, inventory, warehouse, delivery, logistics, production monitoring, factory operations, and billing and operations management. Same team, same discipline, same underlying architecture — different vocabulary, different modules, different shape.

If you want to see it, SPEXA is live, and the Truffaire systems page covers how it sits alongside our other work.

One point on ownership, because it is the question we are asked most: your data stays exportable in standard formats. A system you cannot leave is a system you are hostage to, and that is not a good basis for a decision.

Frequently asked questions

How long does it take to go live?

Weeks rather than months, for the deployments we have run. The variable is rarely engineering — it is how much of the existing operation lives in undocumented places. A business with clean records moves quickly. A business where the real process lives in one manager's head takes longer, because that has to be documented first.

Is this the same thing as an ERP?

Overlapping but not identical. Traditional ERP systems are comprehensive and expect the business to adapt to the software's model. A business operating system of the kind described here inverts that: fewer modules, configured to the vocabulary and workflow the business already uses. For a large multinational, ERP is usually right. For a thirty-outlet chain, the adaptation cost is often the reason the project fails.

What happens to our existing data?

It gets migrated. Years of transaction history, customer records and stock positions move into the new system before launch — which is a substantial part of the work and a common place for projects to go wrong. Any deployment plan that treats migration as an afterthought is worth questioning.

Do we have to replace everything at once?

No, and you should not. Gradual rollout by location, with legacy systems running in parallel, is how we deploy. The switch-off happens once the new system has been proven in live conditions, not on a planned date.

Will staff actually use it?

This is the right question, and it is decided before a line of code is written. Systems get abandoned when they are designed for the person buying rather than the person at the counter at 7pm. If the staff who will use it every day have not tested it and had the awkward parts redesigned, adoption is a gamble.

Where each part is covered in depth

The components above are treated individually elsewhere, because the decisions inside each one are where most operations actually get stuck.

Deciding what to buy. Off-the-shelf vs custom is the first fork; internal tools: build, buy, or do without covers the smaller version of the same question; and how to evaluate a software partner covers who you commit to.

The problems that prompt it. The real cost of running a business on spreadsheets, and why multi-outlet businesses lose money between systems.

Stock and movement. What actually prevents stock variance, warehouse management for growing distributors, and delivery and logistics software explained.

The counter. Billing and POS: what breaks at peak hour.

Production. Production monitoring for small manufacturers, and factory operations: what to digitise first.

Customers and process. Do you need a CRM, or just a better customer record, and workflow automation: where it pays and where it doesn't.

Seeing it. Operational dashboards that people actually use, and what "AI-powered" should mean in business software.

Getting there. Moving years of records without losing them. For regulated clinical operations specifically, clinic management systems: requirements most vendors miss.

Where to start

A business operating system is worth it when reconciliation has become labour, when the operation spans more than one location, or when the complete picture exists only in someone's head. Below that threshold, an accumulated stack of tools is doing its job and replacing it is a cost without a return.

If you are above it, the first step is not choosing software. It is documenting how the business actually runs — including the parts that live on paper and in habits. That document is what any competent partner should ask for first, and if nobody asks, that tells you something.

Related reading: why most business software breaks at the counter covers the failure mode this article is written against, and why we don't build MVPs explains the engineering position behind it.

If you want to talk through whether your operation is at that threshold, get in touch. We will tell you if the answer is no.

Originally published at truffaire.in.

Off-the-Shelf or Custom: How to Decide

Truffaire — Sun, 01 Nov 2026 04:30:00 +0000

The question is usually framed as a budget decision: off-the-shelf is cheaper, custom is expensive, choose according to what you can afford.

That framing produces bad outcomes in both directions. Businesses buy a product because it is cheaper, spend two years working around it, and abandon it. Or they commission a custom build because they believe their operation is unusual, and discover eighteen months later they paid to rebuild something they could have configured.

The useful question is not cost. It is where your operation genuinely differs from the assumptions the product makes — and whether that difference is worth owning software over.

There are three options, not two

The framing hides a middle option that is frequently the right answer.

Off-the-shelf. A finished product. You adapt to its model of how the work is done.

Configured. A capable platform shaped to your vocabulary, workflow and module set. The architecture is shared; the fit is specific.

Custom. Software written for your operation. You own it, including forever.

Most decisions presented as a binary are actually a choice between the first and the second, with custom brought up as leverage. Recognising the middle option changes the economics considerably.

The real cost of off-the-shelf is not the licence

Product pricing is visible and comparable, which is why it dominates the evaluation. The costs that matter are the ones that do not appear on the quote.

Process adaptation. Every product encodes an opinion about how work should be done. Where yours differs, someone changes — and it is not the software. That change has a cost paid in retraining, in exceptions, and in the workarounds that reappear within a year.

Permanent translation. If the product's vocabulary differs from your team's, every user translates on every interaction, indefinitely. This is invisible in a demo and corrosive in production.

Capability you do not use. Products are built for the widest viable market, so most businesses pay for substantial functionality they never touch — and navigate around it daily.

The gap at the edges. Products are strong in their core and weak at the boundaries. A product excellent at appointments may be poor at stock, and the gap gets filled by a spreadsheet, which reintroduces the exact problem the purchase was meant to solve.

None of this argues against off-the-shelf. It argues for pricing it honestly.

The real cost of custom is not the build

Custom is quoted as a project and lived as an obligation.

You own maintenance forever. Dependencies age, platforms change, security patches are required. Nobody else is doing this for you.

You own the knowledge. If the people who understand the system leave — yours or the vendor's — the cost of the next change rises sharply. This is the most common way custom software becomes a liability.

You own every change. Every adjustment is a small project with a cost and a queue. Products ship improvements you did not pay for; custom software improves only when you fund it.

You lose the shared road. A product used by thousands has had its bugs found by thousands. Your custom system has been tested by you.

The correct reason to accept those costs is that the process is the advantage and encoding it compounds. "We are different" is not sufficient. Almost every business believes that.

The four questions that decide it

Answer these about your operation before evaluating any vendor.

Is the difference structural or vocabulary?

This is the decisive one. Structural difference means the shape of the work is genuinely unlike the product's model — a different transaction lifecycle, a regulatory obligation, a unit conversion running through everything.

Vocabulary difference means you do the same things with different words. That feels significant from inside and is solved by configuration, not by a build.

Most businesses that commission custom software had a vocabulary problem.

Is the process a competitive advantage or just a habit?

If how you do the work is why customers choose you, encoding it in software is defensible. If it is how you have always done it, adopting a well-designed product's process is frequently an improvement rather than a compromise.

Being honest here is difficult and worth the discomfort.

What happens at the edges?

Map what the product does not cover. If the answer is "we'll use a spreadsheet for that", you have not eliminated your reconciliation problem — you have renamed it. Why multi-system operations leak money is the same failure in another form.

Can you leave?

Ask about export before you buy anything, product or custom. A system whose data cannot leave in standard formats is a system with a rising switching cost, and that cost becomes a negotiating position against you at every renewal.

What we have actually seen

We have delivered ten systems, and the pattern is consistent: the businesses that came to us convinced they needed something entirely bespoke usually needed the middle option — a shared architecture configured to their vocabulary and module set.

Those ten deployments are genuinely different systems: a multi-outlet retail ERP, clinic management, inventory, warehouse, delivery, logistics, production monitoring, factory operations, and billing and operations management. What varied was rarely the underlying structure. It was language, reporting, regulatory obligation, and which modules were needed at all.

That is why our first phase is documenting how the operation actually runs rather than collecting requirements. You cannot tell whether a difference is structural or vocabulary from a specification document — but you can usually tell within a day of watching the work. The full method is in how Truffaire builds software.

When we say buy the product

Where a sector has a genuinely unusual regulatory structure and a mature vertical product already encodes years of that domain, buying it is often the better decision. Choosing between vertical, general and custom by sector covers how to tell.

Where a business is single-location with simple stock and one person holding the full picture, the honest answer is usually to change nothing yet.

Frequently asked questions

Is custom software always more expensive?

Over the first year, usually yes. Over five, not necessarily — a product requiring constant workarounds, paid seats you do not use, and a spreadsheet filling its gaps has a real cost that never appears on an invoice. Compare total cost over a realistic horizon.

Can we start off-the-shelf and move to custom later?

Yes, and it is often sensible — provided you confirm export before you start. Businesses that discover at migration time that their data cannot leave cleanly end up paying twice.

How do we know if a vendor is selling us custom unnecessarily?

Ask them what they would configure rather than build, and why. A partner who cannot identify anything reusable in your requirements is either not looking or is billing by the hour.

What about low-code platforms?

They sit near the configured option and suit well-understood, low-complexity workflows. The failure mode is that as complexity grows, you end up maintaining something with the constraints of a product and the obligations of custom.

Does configured software cost more than off-the-shelf?

Upfront, generally yes, because configuration is work. The comparison that matters is against the adaptation cost of the product — retraining, workarounds, and the spreadsheets filling its gaps.

Where to start

Do not begin with vendors. Begin by classifying your own difference: structural or vocabulary. Almost everything follows from that answer.

If it is structural and legally binding, a specialist product or a build is justified. If it is vocabulary and workflow, configuration will fit better and cost less to live with. If the process is genuinely your advantage, custom may be right — with clear eyes about owning it for years.

The expensive mistake is not picking wrong. It is picking before you know which category you are in.

What a business operating system actually is covers the architecture behind the middle option, and SPEXA is our implementation of it. If you want a straight read on which category your operation falls into, get in touch — including if the answer is to buy something other than ours.

Originally published at truffaire.in.

Configuring Software to a Business, Not the Reverse

Truffaire — Sat, 31 Oct 2026 04:30:00 +0000

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.

Originally published at truffaire.in.

Internal Tools: Build, Buy, or Do Without

Truffaire — Fri, 30 Oct 2026 04:30:00 +0000

Internal tools accumulate the same way business software does: one at a time, each solving a real problem, none of them planned. A small app to track something. A form someone built. A script that runs weekly and only one person knows about.

Individually they are sensible. Collectively they become an unmapped layer of the business that nobody owns, nobody documents, and everybody depends on.

The question is not whether to build internal tools. Most operations need some. It is which ones justify existing, and that turns out to be a smaller set than the request list suggests.

The request is usually not the requirement

When someone asks for an internal tool, they are describing a solution. The useful move is to work backwards to the problem, because the stated solution is frequently the wrong shape.

"We need a tool to track which orders are pending approval" might mean:

Approvals take too long → a routing problem
Nobody knows what is pending → a visibility problem
Approvals happen in chat and get lost → a record problem
Too many things need approval → a policy problem

Only two of those are solved by a tool. The fourth is solved by changing the policy, and building software for it makes an unnecessary process permanent and harder to remove later.

Ask what happens if the tool is not built. If the answer is "we keep doing it manually", you have a candidate. If it is "we would have to fix the underlying process", the tool is a way of avoiding that fix.

Three tests before building anything

Does the data already exist somewhere? Most internal tool requests are visibility problems, not capability problems. The information exists — it is in the operations system, or in an export — but it is not where the person needs it. Surfacing existing data is much cheaper than building a new place to enter it.

Will it need maintaining? Anything that reads from another system breaks when that system changes. Anything with a login needs access management. Anything holding data needs backup. A tool nobody maintains becomes a tool nobody trusts, and then a tool that quietly reports stale figures.

Who owns it when the author leaves? The most common failure mode for internal tools. Someone builds it, it becomes load-bearing, they move on, and nobody can change or fix it. If a tool cannot survive its author leaving, it is a liability wearing the costume of an asset.

What is usually worth building

Things that surface existing data in a decision-shaped way. A screen showing exactly what a specific role needs to act on. Cheap, low-risk, high-value — because the underlying record already exists and stays authoritative.

Things that remove duplicate entry. If staff enter the same information in two places, closing that is worth real effort. It removes a category of error rather than a task.

Things that enforce a rule that matters. Preventing an order that breaches credit limit, or a discount beyond authority. Where the cost of the mistake is high and the rule is unambiguous, encoding it pays.

What is usually not

A better view of a bad process. Making a slow approval chain visible does not shorten it. Fix the chain.

Something one person wants. A tool used by one person, requested by that person, maintained by that person, is a personal script. That is fine — call it that, and do not treat it as infrastructure the business depends on.

Replicating something you already pay for. Common with reporting: teams build a custom report because the existing system's export is inconvenient, and now maintain a parallel version that will eventually disagree with the source.

Anything you cannot staff. If nobody will own it in six months, the honest answer is not to build it.

The hidden cost is fragmentation

Each internal tool adds a place where truth can live. Two tools reporting the same number will eventually disagree, and when they do, the business gains a new question — which one is right — on top of the original one.

This is the same failure as the accumulated software stack, at smaller scale: many sources of truth, reconciled by people. The structural answer is that internal tools should read from the operational record rather than maintain their own copy of it. That is the architecture argument in what a business operating system actually is.

A tool that reads is cheap and safe. A tool that stores is a second database with all the obligations of the first.

Low-code and the two-year problem

Low-code platforms have made building internal tools genuinely accessible, and for narrow, stable, well-understood needs they are frequently the right answer.

The failure mode is specific and worth naming: after two years, an organisation has thirty small automations and apps built by people who have moved on, with no documentation, no test coverage, and unclear ownership. Each was cheap. The aggregate is a maintenance obligation nobody scoped.

If you use them, keep a register: what exists, who owns it, what it reads from, and what breaks if it stops. That single document prevents most of the pain.

What we have seen

Across the ten systems we have delivered, the recurring pattern is that businesses arrive with a list of tools they believe they need, and the list shrinks substantially once we watch the actual work.

Most requests turn out to be one of three things: information that exists but is in the wrong place, duplicate entry that a shared record removes, or a process step that should not exist. Genuinely novel capability is the smallest category.

This is why our first phase documents the operation as performed rather than as described — including the tools people have quietly built for themselves. Those homemade tools are the most honest specification available, because each one marks a place where the official system failed someone enough that they built around it. The method is in how Truffaire builds software.

The related judgement — whether to configure, buy, or build at all — is in off-the-shelf or custom.

Frequently asked questions

Should we build internal tools ourselves or hire?

If it is small, stable and one team uses it, building internally is often right — provided ownership is assigned rather than assumed. Anything load-bearing across the business deserves the same scrutiny as bought software, including who maintains it in two years.

How do we stop internal tools proliferating?

Keep a register and require an owner before anything is built. Most proliferation happens because there is no cost to creating one and no record that it exists.

Is it worth replacing our internal tools with one system?

Only where they overlap or disagree. Tools doing genuinely distinct jobs, with clear owners, that read from the operational record, are fine as they are. Consolidation for its own sake is expensive.

What about tools built by staff who have left?

Audit them: what it does, what it reads, who depends on it. Then either assign an owner or retire it. The worst state is a tool everyone uses and nobody maintains, because it will fail eventually and nobody will know why.

Can AI help build internal tools faster?

It can make building faster, which makes the discipline above more important rather than less. The constraint on internal tools was never build speed — it is maintenance and ownership, and those do not get cheaper.

Where to start

List every internal tool that currently exists — including spreadsheets with formulas, scripts, and forms. For each, record who owns it, who depends on it, and what it reads from.

That list usually answers the question. Tools with no owner and real dependency are your risk. Tools that duplicate the operational record are your future disagreement. Tools that surface existing data cleanly are the ones worth keeping and extending.

Then, for any new request, work backwards from the stated solution to the actual problem — and check whether the honest answer is a change to the process rather than software.

If you want a read on which of your tools are load-bearing, get in touch.

Originally published at truffaire.in.

Deploying Without Stopping the Business

Truffaire — Thu, 29 Oct 2026 04:30:00 +0000

A business that has been running for years does not stop while its systems are replaced. Customers still arrive, stock still moves, bills still have to be raised, and the day the new system goes live is a normal trading day for everyone except the people deploying it.

That is the actual constraint, and it is the part of a software project most likely to go wrong. The build happens in a controlled environment where mistakes are cheap. The cutover happens once, on a specific day, in a live operation, in front of customers.

Almost all of the risk in that day is removed before it, by decisions that look procedural at the time.

Why the switch is where projects fail

Three things converge at cutover that were separate until then.

The data becomes real. Years of records move from a spreadsheet, an older system, or a register into the new one — and whatever was inconsistent about them becomes visible immediately. The considerations are in moving years of records without losing them.

The users are new. Everyone using the system on day one is using it for the first time under real pressure, which is a different exercise from training.

There is no fallback unless one was built. If the old system has been switched off, every problem is now urgent.

The projects that go badly are the ones where all three arrive on the same morning.

Choosing how to switch

There are three shapes, and the choice should be made deliberately rather than by default.

Parallel running. Both systems operate for a period, and the outputs are compared. It is the safest option and it doubles the work for the staff doing it, which means it can only be sustained for weeks rather than months. Best where the cost of an undetected error is high — billing, stock valuation, anything financial.

Phased. One location, one department or one function moves first. The rest follow once it is proven. This is usually the right answer for multi-site operations, because the second site benefits from the first site's problems, and support can be concentrated where it is actually needed.

Direct cutover. Everything switches on a date. Fastest, cheapest, and it concentrates all risk into a single day. Defensible for small operations, for a system with no predecessor, or where parallel running is genuinely impossible.

The wrong choice is usually direct cutover selected because it was never discussed — chosen by the calendar rather than by the risk.

What has to exist before the date

A rollback that has been tested. Not a plan describing rollback — an actual rehearsal. An untested rollback plan is an assumption, and it will be discovered to be wrong at the worst moment.

A defined moment for the go/no-go decision. Named person, stated criteria, decided in advance. Without it, the decision gets made under pressure by whoever is in the room, and the answer is always to proceed.

The data migrated and verified, before the day rather than on it. Verification means checking specific known records, not confirming that row counts match.

People trained and available. Not a session weeks earlier — the people who will use it, present, with someone alongside them, as described in training staff on a system they didn't ask for.

A manual fallback for the critical path. If billing cannot happen, the business stops. A written procedure for taking orders on paper for two hours is unglamorous and it is what keeps the doors open.

Choosing the day

The date is a real decision and it is frequently made badly.

Avoid peak. Avoid month end and financial period boundaries. Avoid the day before a holiday, when a problem sits unresolved for a week. Avoid a day when the people who know the system are travelling.

The best cutover days are boring ones — low volume, full staffing, a clear week afterwards. A retailer switching the week before a festival has chosen the single worst available date, and it happens regularly because the project ran late and the date was inherited rather than chosen.

The first two weeks

Go-live is the start of the risky period, not the end of it.

What matters through it: someone present where the work happens rather than reachable by email; small irritations fixed within days, because that is what establishes the system as responsive; the old system available but not actively used, so a genuine failure has somewhere to fall back to; and a daily check on the numbers that matter, to catch a silent divergence before it becomes a month of bad data.

That last one is the failure nobody plans for. Systems rarely fail loudly at cutover; they fail by producing plausible numbers that are subtly wrong, and the sooner someone compares them to reality the cheaper the correction.

Why we treat this as part of the build

Truffaire has delivered ten systems across ten clients — retail, clinical, inventory, warehouse, delivery, logistics, production monitoring, factory operations and billing — into businesses that were already trading.

Every one of those was a replacement of something, and the position that follows is that deployment is a phase of the engineering work rather than a handover event. A system designed without regard for how it will be introduced tends to require a hard switch, because nothing in it was built to coexist with what it replaces.

That is the reasoning in how Truffaire builds software, and the reason the configuration layer matters here too: a system that can be adapted after go-live can absorb the first fortnight's discoveries, which is the subject of configuring software to the business.

Frequently asked questions

How long should parallel running last?

Long enough to cover a full cycle — usually a month, so that period-end processes are exercised. Longer than that and staff sustaining double entry begin to abandon one side.

Can we go live over a weekend?

For the technical switch, yes. For the first day of real use, no — going live on a Monday with full staffing beats going live on a Saturday when the people who can help are unavailable.

What if the old system cannot run in parallel?

Then phasing or a tested rollback carries the risk instead. The requirement is that some fallback exists, not that it is specifically parallel running.

Who decides whether to proceed?

One named person, against criteria written down before the week of the cutover. Committees under time pressure approve.

What does a failed cutover actually look like?

Rarely a crash. Usually a business trading normally on numbers that are quietly wrong for three weeks — which is why the daily reconciliation in the first fortnight matters more than the switch itself.

Where to start

Before any go-live date is agreed, ask one question: if this does not work by eleven in the morning, what happens.

If the answer is a plan nobody has rehearsed, that rehearsal is the next piece of work — and it is considerably cheaper than discovering the gap on the day.

If you are replacing a system in a business that cannot stop, get in touch.

Originally published at truffaire.in.

Moving Years of Records Without Losing Them

Truffaire — Wed, 28 Oct 2026 04:30:00 +0000

Migration is the part of a software project that gets a line in the plan and a third of the effort.

It is also where projects fail in the least visible way. A system goes live, everyone is pleased, and six weeks later someone tries to answer a question about last year and discovers the history is incomplete, or duplicated, or subtly wrong in a way that has been quietly informing decisions since launch.

The failure is rarely technical. Moving data between systems is a solved engineering problem. The difficulty is that years of accumulated records contain decisions, exceptions and inconsistencies that nobody documented, and migration is the first time anyone has to look at all of it at once.

What migration actually surfaces

The first honest run of any migration produces a list of problems that existed all along and were invisible because nothing forced them into the open.

The same entity recorded several ways. One customer as "Kumar Traders", "Kumar Traders." and "kumar traders" — three records, three balances, one business. Every operation with a few years of history has this, and nobody knows how many.

Fields used for something other than their name. A notes field holding delivery instructions. A reference field holding a second phone number. These conventions grew because the system lacked a place for something, and they are invisible until you try to map the field.

Records nobody can explain. Transactions with no counterpart, adjustments with no reason, entries from a person who left. Somebody has to decide what happens to them.

Balances that do not reconcile. Ledger totals that differ from the sum of transactions. Almost always present at some scale, and migration is when it becomes undeniable.

None of this is a reason to postpone. It is a reason to schedule properly, because every one of these needs a decision from someone in the business, not from whoever is writing the migration.

Decide what actually needs to move

The instinct is to move everything. It is usually wrong, and it is expensive.

Three categories, and they deserve different treatment:

Operational data — open orders, current stock, live customer balances, active records. This must move, must be complete, and must be correct on day one. The system cannot run without it.

Reference data — customers, suppliers, products, price lists. Must move, and is the category most needing cleaning first, because errors here propagate into everything.

Historical data — closed transactions from previous years. Must be accessible, not necessarily migrated. Frequently the better answer is to move a defined recent period and keep older records queryable in an export or the old system in read-only form.

That last distinction saves a great deal of money. Businesses ask for ten years of history and, in practice, look at eighteen months. Ask what questions people actually ask of old data before deciding to migrate all of it.

Clean before, not during

The temptation is to clean data as part of the migration. This produces a bad outcome, because the migration then has two jobs and its correctness becomes hard to verify.

The better sequence:

Extract the current data as it is
Profile it — duplicates, missing fields, inconsistent formats, orphans
Decide the rules, with the business, not the developer
Clean in the source or in a staging copy, with those decisions applied
Migrate the cleaned data
Reconcile against the original

Step three is the one that gets skipped, and it is the only one that requires the business. Whether two similar customer records are the same customer is not a technical question.

Reconciliation is the whole test

A migration is not finished when data has moved. It is finished when you have proved it moved correctly.

At minimum:

Counts. Number of customers, products, open orders, transactions in a period. They should match exactly, and where they do not, the difference should be explained rather than accepted.

Totals. Sum of outstanding receivables, stock valuation, ledger balances. These are the figures that will be noticed if wrong, and noticed late.

Spot checks on the awkward cases. Not random records — the difficult ones. The customer with a credit note and a partial payment. The product sold in two units. The order that was partly delivered. If those are right, the ordinary cases are almost certainly right.

Run reconciliation before switching off the old system, not after. This is the step that pressure removes from a timeline and the one that makes the difference.

Run both in parallel

For a short period, keep the old system updated alongside the new one and compare.

It duplicates effort for a few weeks and it is the cheapest insurance available. A gap discovered while both systems are live is a correction. The same gap discovered after the old system is decommissioned is a reconstruction from bank statements and memory.

This is the same principle as deploying location by location rather than switching everything at once, described in how Truffaire builds software.

What we have seen

Migration is consistently the largest source of timeline risk across the ten systems we have delivered — more than any technical requirement.

The specific pattern: a business estimates its data is broadly clean, the first extract shows several thousand near-duplicate entities, and resolving them requires decisions only the business can make, from people who are also doing their normal jobs.

The related finding is that undocumented spreadsheet logic is the hardest thing to migrate, because the rules live in formulas and in one person's judgement rather than in data. The real cost of running on spreadsheets covers why that logic is effectively the specification.

Where a business has clean, consistent records, migration is fast. That is rarer than most expect, and knowing which case you are in is worth establishing early.

Frequently asked questions

How long does migration take?

The extract and load are fast. Profiling, deciding cleaning rules and reconciling take the time, and they depend on your data rather than on the software. A first extract in week one tells you far more about the timeline than any estimate.

Can we migrate everything from day one?

You can, and it is often unnecessary. Operational and reference data must be complete. Historical data can frequently be accessible rather than migrated, which is faster and cheaper.

What if the old system will not export cleanly?

Ask this before buying anything, not at migration. Export capability is a purchasing criterion — a system whose data cannot leave in standard formats has a rising switching cost that becomes a negotiating position against you.

Who decides how to resolve duplicates?

The business, not the developer. Whether two similar records are one customer is a commercial judgement. The most useful preparation is naming who will make those calls before the work starts.

Should we clean the data first or move it first?

Clean first, in a staging copy, with rules the business agreed. Cleaning during migration makes it impossible to tell whether a discrepancy came from the data or the process.

Where to start

Do one thing before committing to any project: take a full export of your current data and look at it.

Count the customers. Sort them alphabetically and look for near-duplicates. Check whether every product has a consistent unit. Total the outstanding balances and compare against your ledger.

That afternoon of work will tell you more about the real timeline than any vendor estimate, and it moves the unpleasant discoveries to before the decision rather than after.

Migration is one component of a larger picture; what a business operating system actually is sets out the rest.

If you want help profiling what you have, get in touch.

Originally published at truffaire.in.

Why Software Performance Is a Business Decision

Truffaire — Tue, 27 Oct 2026 04:30:00 +0000

Performance gets treated as a technical concern — something engineers care about, discussed in milliseconds, of no obvious interest to the person paying for the system.

That framing survives because the cost is distributed. Two seconds on a screen is nothing to anyone watching it once. Two seconds on a screen used four hundred times a day, by six operators, is over five hours a week, absorbed invisibly by people who assume the wait is normal.

Nobody decided to spend that. It accumulated, and it goes on accumulating until someone measures it.

The arithmetic nobody runs

Take the most-used screen in an operational system — a product lookup, a bill entry, a customer search — and count how many times a day it is opened across the business.

A retail counter might do it several hundred times. A warehouse might scan more. A clinic might load a patient record a hundred times a day across its desks.

At those volumes, a second is not a second. It is a recurring tax on every transaction, paid in staff time, and it is comparable in size to decisions businesses agonise over — because it is the same shape as a staffing decision, made by default rather than deliberately.

The second cost, which is larger

The direct time is measurable. The behavioural effect is bigger and harder to see.

People stop checking. If verifying stock takes four seconds, an operator under pressure guesses. The system had the answer and was too slow to be asked, so a decision gets made on memory.

People batch. Slow entry gets deferred to a quiet moment, which means the record is stale during the period when it matters most, and entered later from notes.

People work around it. A parallel note, a spreadsheet, a WhatsApp message. The workaround is invented under pressure and becomes permanent, which is where a system's data quietly stops being complete.

Each of these is a data integrity failure caused by latency, and none of them appear in a performance report. They appear as variance, as stale figures, as a system nobody quite trusts — the adoption failure described in training staff on a system they didn't ask for.

Where slowness actually comes from

In business systems, the causes are consistent and rarely exotic.

Loading everything to show a little. A screen that fetches a full record set to display twelve rows. The most common cause and the most easily fixed.

Queries that grow with the data. Fast at launch with a thousand records, slow at fifty thousand. This is why a system that was fine for two years becomes intolerable in year three — nothing changed except volume.

Round trips. Each one adds latency, and a screen making eight sequential requests waits for all of them.

Doing work at the wrong time. Calculating a summary on every page load rather than when the underlying data changes.

Connectivity assumed. A system designed for a stable connection behaves very differently at a warehouse edge or a rural outlet. This is a design decision rather than an infrastructure problem.

None of these are mysteries. They persist because nobody measured the screen that matters.

Measuring the right thing

Aggregate performance figures conceal exactly what matters.

Average response time is dominated by fast trivial requests. The screen your counter uses four hundred times a day is one line in it.

Measure the specific operations that matter, named: bill entry, product lookup, patient record open. Those are the business's actual performance, and they are the ones to hold a number against.

Measure on real devices, on the real connection. A system tested on an office network behaves differently on a warehouse floor.

Measure at realistic data volume. Testing against a small dataset hides every scaling problem, and those surface a year later when they are expensive.

Watch the worst cases, not the average. The slowest few percent of requests are what users remember, and they are frequently the ones under load — which is to say, at the busiest hour.

The decision to make explicitly

Performance is a budget, and the useful version of the conversation is not "make it fast". It is: for these specific operations, what is the acceptable response time, and what are we willing to spend to hold it there?

Stated that way it becomes a business decision with a comparison — the engineering cost of holding a lookup under half a second, against the staff time and data quality cost of not doing so.

Most operations do not need to be fast. A monthly report can take a minute. The handful of interactions that happen hundreds of times a day are where the entire return is, and identifying that handful is the first step.

The same reasoning applies to public-facing sites, where the cost appears as lost visitors rather than staff time: website performance is an SEO feature.

Why it decays without attention

A system that was fast at launch does not stay fast.

Data grows. Features are added, each one adding a little to a screen that was already loaded. Reports get attached to pages that did not have them. None of these individually is noticeable, and cumulatively the system becomes something staff describe as "slow these days" without anyone being able to say when it changed.

This is the maintenance pattern generally — nothing visibly breaks, so nothing gets attention until it is expensive. That argument is in what it takes to maintain software for years, and the practical protection is the same: measure the key operations on a cadence, so drift is visible while it is still small.

Our position on this is stated in how Truffaire builds software — that the operations happening hundreds of times a day are the ones held to a standard, and everything else is negotiable.

Frequently asked questions

What response time should we target?

For interactions repeated constantly, fast enough that an operator does not wait — which in practice means well under a second. For occasional operations, considerably more is acceptable.

Is this a hosting problem?

Occasionally. More often it is what the application does per request, and moving a badly-structured query to a larger server buys a little time at recurring cost.

How do we know if performance is costing us?

Watch for the behaviours: staff guessing instead of checking, batching entry, keeping parallel notes. Each is a symptom of an interaction that is too slow to use in the moment.

Should we optimise everything?

No. Identify the handful of operations that dominate daily use and hold those to a standard. Optimising rarely-used screens is effort with no return.

Our system was fine and got slower. Why?

Almost always data volume meeting a query that scales with it, sometimes combined with features accumulating on a heavily-used screen. Both are findable by measuring the specific operation rather than the system.

Where to start

Time your most-used screen with a stopwatch, then multiply by how many times a day it is opened across the business.

That number is what performance is currently costing you, expressed in the only unit that makes it a decision rather than a technical detail.

If you want a system measured against the operations that actually repeat, get in touch.

Originally published at truffaire.in.

What It Takes to Maintain Software for Years

Truffaire — Mon, 26 Oct 2026 04:30:00 +0000

Software is sold as a project with an end date and lived as an obligation with none.

The build is the visible part and frequently the smaller part. A system that runs an operation for a decade will spend most of that decade being maintained — patched, adjusted as the business changes, kept working as the platforms underneath it move. Whether that decade is manageable or steadily worsening is largely decided during the build, by choices that look like details at the time.

Software does not decay, but its surroundings move

A system left untouched does not break by itself. Everything around it moves, and the gap accumulates.

Dependencies age. Libraries stop being maintained, and the security fixes stop with them.

Platforms change. Operating systems, browsers, runtimes and hosting all move, and eventually something the system assumed is no longer true.

Obligations change. Tax rules, reporting formats, regulatory requirements. These arrive with deadlines and no regard for your roadmap.

The business changes. New locations, new products, a different way of pricing. A system that cannot follow becomes the constraint on the operation it was built to serve.

The last is the one that decides a system's fate. Technical decay is manageable. A system that prevents the business changing gets replaced regardless of how well it runs.

The three things that decide maintainability

Whether anyone understands it

The most common way a system becomes unmaintainable is that the people who understood it left.

This is not primarily about documentation, which ages and is rarely read. It is about whether the system is comprehensible — whether a competent engineer encountering it can work out what it does and why, from the code and its structure.

Systems accrete undocumented rules over years: an exception for one customer, a workaround for a supplier's format, a condition nobody can explain. Each was reasonable. Collectively they become knowledge held by one person, and when that person leaves, every subsequent change becomes an archaeology exercise first.

The practical protection is keeping the number of special cases small, and recording why whenever one is added. The reason matters more than the mechanism — the mechanism is visible in the code, the reason never is.

Whether changes can be made safely

The question that determines cost per change: if I alter this, how do I know I have not broken something else?

Where the answer is "we test it manually and hope", every change carries risk, and risk makes people reluctant. Reluctance means changes are batched into large infrequent releases, which are more dangerous than small frequent ones — the opposite of what caution intends.

Where changes can be verified quickly, they stay small, and small changes are how a system keeps up with a business rather than falling behind and being replaced.

Whether it can be left

Exportability is usually discussed as a commercial protection. It is also a maintenance property.

A system whose data can leave in standard formats can be replaced incrementally — one function at a time, as needs change. One whose data is locked in has to be replaced all at once, which is expensive enough that businesses defer it, which means running an inadequate system for years longer than they should.

Our position is that data stays exportable in standard formats, and the maintenance argument is part of why. It is covered alongside the other requirements in security and data ownership in client systems.

The deferral trap

Maintenance is uniquely easy to postpone, because nothing visibly breaks when you do.

Skipping a dependency update this quarter has no consequence. Skipping it for three years means the eventual update is not an update — it is a migration across several major versions, with breaking changes, done under pressure because a security issue forced it.

The cost curve is not linear. Small regular maintenance is substantially cheaper than the same work accumulated, and the accumulated version arrives at a moment you did not choose.

The practical version for a business: a modest recurring maintenance budget is not overhead. It is what prevents a much larger unplanned expense arriving at the worst time.

What to establish before a system is built

The decisions that matter are made early, and they are commercial as much as technical:

Who maintains it, and at what cost. Get the ongoing figure before signing, not at renewal.

What a change costs, and how long it takes. Rate and lead time, so that adapting the system is a normal activity rather than a negotiation.

What happens if the people who built it leave — on their side and yours.

Whether another firm could take it on. If the answer requires the original team, you have a dependency rather than an asset.

How you get everything out. Immediate, unqualified answer expected.

These are the same questions in how to evaluate a software partner, and they matter more over years than any feature comparison.

What we build to

Truffaire has delivered ten systems on a shared architecture, and the reason we do it that way is partly maintenance: a shared foundation is maintained once rather than ten times, and an engineer who knows one deployment can work on another.

Two positions that follow directly:

Fewer modules, actually used. Every module is a maintenance obligation. Anything not genuinely used is cost with no return, and it is also a place stale data misleads someone.

Continuous adaptation rather than periodic overhaul. 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 — which is the position in what it means to build a system that endures.

Frequently asked questions

What should maintenance cost annually?

It varies with complexity, and the important thing is that it is a known figure agreed before you commit rather than discovered later. A vendor vague about ongoing cost is planning to tell you afterwards.

Can we maintain it ourselves?

If it is comprehensible and you have the capability, yes — and confirm that another firm could also take it on. Self-maintenance that depends on one internal person reproduces the same risk in a different place.

How do we know if our system is becoming unmaintainable?

Three signals: changes take longer than they used to, only one person can make them, and people have started working around the system rather than asking for changes. The third is the clearest.

Is it cheaper to rebuild than maintain?

Occasionally, and less often than it is proposed. Rebuilding discards accumulated business logic — including the undocumented rules that turn out to matter — and reintroduces every migration risk. Rebuild when the architecture genuinely blocks the business.

What about software we bought rather than built?

The same questions apply, with less control. Ask about the vendor's own upgrade path, what happens on change of control, and — again — how you export everything.

Where to start

Ask two questions about your current systems. If the person who knows this best left tomorrow, what would happen? And when was the last time anything underneath it was updated?

If the answers are "we would struggle" and "we are not sure", that is not an emergency today and it is a cost accumulating quietly. Both are cheaper to address now than at the moment something forces them.

The engineering positions this follows from are set out in how Truffaire builds software.

If you want a read on where your systems stand, get in touch.

Originally published at truffaire.in.

Why Truffaire Doesn't Build MVPs

Truffaire — Sun, 25 Oct 2026 11:33:17 +0000

The minimum viable product is one of the most influential ideas in modern technology. The logic is compelling: rather than spending years building a complete system before getting feedback, build the smallest thing that tests your hypothesis, release it, learn from real users, and iterate. Fail fast. Fail cheap. Find product-market fit before you run out of money.

This is good advice for a consumer application. For a farmer in Karnataka who is depending on your crop disease diagnosis to decide whether to spend ₹4,000 on a fungicide treatment, it is the wrong frame entirely.

What MVP Logic Assumes

The minimum viable product framework rests on several assumptions that are true in consumer software and false in the domains Truffaire operates in.

The first assumption is that failure is cheap. In consumer software, this is largely true. If a social media app has a bug that causes it to crash, the user is annoyed. They switch to a competitor. The company loses a user. These are recoverable situations.

In agricultural diagnostics, failure is not cheap. An incorrect disease diagnosis leads to incorrect treatment. The farmer spends money on the wrong product, the disease progresses while the treatment does nothing, and by the time the correct diagnosis is made, the intervention window has closed. The cost of that failure is not a lost user — it is a damaged crop and the debt that comes with it.

In business operations, an MVP billing system that miscounts stock produces a ledger the business then plans against. The error does not announce itself; it compounds quietly through reorders, pricing, and accounts until a reconciliation months later exposes it. The cost of that failure is not a lost user — it is a year of decisions made on numbers that were wrong.

In healthcare, the consequences are self-evident.

The second assumption is that users can meaningfully evaluate an MVP and give you useful feedback. This assumes a level of domain expertise and evaluation capacity that exists in some user populations and not in others. A startup's early adopters in the consumer technology space are typically technically sophisticated, understand that they are using an early product, and provide feedback that reflects their genuine experience.

A farmer in a rural district who is using a crop disease diagnosis tool for the first time is not in a position to evaluate whether the diagnosis they received is accurate. They lack the specialist knowledge to assess accuracy. They will act on the diagnosis. If the diagnosis is wrong, they will not immediately know it — they will know it weeks later, when the treatment fails and the crop is already severely affected.

The feedback loop that MVP logic depends on is broken in contexts where users cannot evaluate the quality of the output they receive.

The third assumption is that the cost of learning is borne by the company, not the user. In consumer software, a bad user experience costs the company a user. In the domains we work in, a bad system experience costs the user something they cannot recover — a crop, a case, a patient outcome.

What We Build Instead

We build what we call minimum sufficient systems — systems that meet the full performance requirements for the context they are deployed in before they are deployed.

Minimum sufficient is a different standard from minimum viable. Minimum viable asks: what is the smallest thing we can build that tests our hypothesis? Minimum sufficient asks: what is the smallest thing we can build that is genuinely adequate for the use case?

For ARCORA, minimum sufficient meant building a diagnostic model validated against expert agronomist assessments before deploying to farmers. It meant testing across the full range of crops and disease presentations that Karnataka farmers encounter, not just the most common ones. It meant building a treatment protocol layer that is medically accurate before giving farmers the capacity to act on it.

This takes longer than building an MVP. It costs more upfront. It produces a first release that is later and smaller than an MVP approach would produce.

What it does not produce is a version of the system that a farmer relies on, receives incorrect advice from, and suffers a crop loss because of. That outcome is not recoverable with a patch or an update. The trust once lost in this kind of context does not return.

The Right Kind of Speed

The argument against MVP thinking in critical domains is sometimes read as an argument for slowness. It is not.

Speed matters enormously. A farmer's crop disease is progressing right now. A crime scene's integrity is degrading right now. A medical student's clinical training is happening right now, in whatever form it is happening in.

The right kind of speed in these contexts is the speed of getting something that works into deployment, not the speed of getting something to market before it is ready. These are different things. They require different approaches to development, to testing, and to the definition of "done."

A system is done when it is ready to use, not when it is ready to test. The testing happens internally, under conditions that replicate real deployment without the real-world consequences of failure. The deployment happens after the system has demonstrated that it is adequate for the purpose.

This is how we build. It is slower in the early stages. It is faster in the long run, because we do not spend time managing the consequences of deploying systems that were not ready.

And it is the only approach that respects the people who depend on what we build.

Originally published at truffaire.in.