Ask a mid-market company what software it runs on and you will get a list: Tally, a CRM somebody bought in 2021, Google Workspace, WhatsApp, and — said more quietly — between forty and four hundred spreadsheets. What you will almost never hear named is the thing the business actually operates on. Because in most companies, that thing is not software. It is a person.
Operational software is the system that holds the state of the operation. Not a view of it. Not a report about it. The state itself — what was promised, what was dispatched, what was received, what is owed, what was proved. If it is switched off, work stops, because there is nowhere for work to be recorded.
That is a narrower definition than “business software” and it excludes most of what gets sold under that name. It is worth being precise about the boundary, because the money is on the other side of it.
Three things it is not
It is not a dashboard. A dashboard reads state that already exists somewhere. If the underlying record is wrong, a dashboard renders the wrong number beautifully and on time. Almost every analytics engagement that disappoints was really a data-model problem wearing a visualisation costume.
It is not an ERP you configured. An ERP encodes somebody else’s idea of how your operation runs. Sometimes that idea is close enough and the implementation is a bargain. Often the gap gets absorbed by exactly the people the ERP was supposed to help — who now maintain the ERP and the spreadsheet that holds what the ERP could not. The tell is a company that has an ERP and is still hiring people to reconcile things by hand.
It is not an app. Apps are surfaces. An operation needs a surface, but a surface with no enforced record behind it is a faster way to enter unreliable data.
Four properties, and a company usually has one or two
A system earns the description when it does all four of these. Most companies we walk into have the first, sort of, and none of the rest.
1. It holds the record of truth
There is exactly one place where the answer to “what is the status of this order” lives, and everybody — ops, finance, the customer-facing team — reads the same row. The failure mode is not that people disagree. It is that three people are each correct, according to three different records, and nobody can tell which record the business should act on.
2. It enforces the rules
The constraints that matter are expressed where they cannot be skipped — in the schema, in a database constraint, in a transaction — rather than in a warning dialog somebody can click through at 7pm on a Friday. A rule that lives only in the interface is a suggestion. A rule that lives in the database is a rule.
This is the property most often traded away under deadline pressure, and it is the most expensive one to add back later, because by then the database is full of rows that would violate it.
3. It produces the artefacts
Real operations run on documents: invoices, delivery challans, e-way bills, settlement statements, statutory filings. A system that holds beautiful state and then requires somebody to retype it into a document has not removed the work — it has added a system to the work. The artefact has to come out of the record, in the format the counterparty already accepts, or the old process survives alongside the new one.
4. It leaves a trail
Every change carries who, when, from where, and what it was before. Not for compliance theatre — because the question that eventually gets asked is always “who changed this rate, and when”, and a business that cannot answer it is negotiating from memory against a counterparty holding a printout.
Pick the single most valuable thing your business does — dispatch a shipment, admit a patient, release a batch. Now ask: if the system were down for a day, would that work stop, or would it continue on WhatsApp and paper and get entered later?
If it would continue, you do not have operational software. You have a record-keeping system that the operation reports to. The difference is the entire gap this essay is about.
Why so few companies own one
Not for the reason you would expect. It is rarely budget, and it is almost never that nobody noticed.
It is that the spreadsheet worked. It worked at ten trips a day and at forty. It worked when the founder could hold the exceptions in their head. Every year it kept working, which is exactly the evidence needed to defer replacing it — until the point where the operation is running on a structure that nobody designed, that one person understands, and that fails in ways that are individually small and collectively enormous.
The second reason is that the cost of not having one is invisible by construction. A leak that is visible gets fixed. What survives is the leak that looks like normal business: the rate that was quoted differently to the customer and the owner, the advance that was paid twice because two people were tracking it, the proof of delivery that exists as a photograph on a phone belonging to somebody who left. None of those show up as a line item. They show up as a margin that is lower than it should be, for reasons the P&L cannot resolve.
We have put a number on this once, precisely, because a client had the misfortune of finding out. A freight broker lost ₹85 lakhs over twelve months to internal fraud that was possible because pricing, dispatch, proof and settlement lived in four unconnected places. No single step was obviously wrong. The gaps between the steps were where the money went.
What this implies about how to buy it
Three things follow, and they are unpopular.
The data model is the deliverable. Interfaces get redrawn every few years; the schema outlives them. When we start an engagement, the first artefact is not a wireframe, it is the set of entities and the constraints between them — because that is the part that is expensive to get wrong and cheap to get right at the beginning.
Scope by the operation, not by the feature list. “A dispatch module” is not a scope. “A trip can move from priced to dispatched only when a vehicle and an owner are assigned, and dispatching posts an owner advance and a fuel debit” is a scope. The second one can be built, tested and argued about. The first one becomes whatever anybody wants it to be.
Judge it on what it refuses. Good operational software is mostly a set of things that cannot happen. You will not see that in a demo, which is the honest difficulty with buying it — the value is in the states the system will not enter, and a demo only shows the happy path.
The narrower claim
We are not arguing that every company should build custom software. Plenty should buy the product and get on with their lives, and we say so when it is true.
The claim is narrower and, we think, harder to argue with: if the thing your business does best is not represented anywhere as an enforced record, it is not a process — it is a habit. Habits scale to the limits of the people holding them, and then they stop, usually at the worst possible moment, usually during the growth that made the ceiling matter.
Most of the work we do is the same shape. Find where the operation actually runs, which is never entirely where the org chart says. Write down what must always be true. Build the system that will not let it be false. Produce the documents that come out the other end. Leave a record of every hand that touched it.
It is not glamorous and it does not demo well. It is, nearly always, where the money is.