Six Times Not to Buy Operations Software
Six situations where the honest answer is not to buy anything — from a software company that would rather tell you now than have you cancel in month four. Including the one where a better spreadsheet is genuinely the right tool.
Every vendor has a version of this page and most of them are performances — a list of situations nobody is actually in, positioned to make the reader feel qualified. This one is meant literally. All six are situations we have watched go badly, and in four of them we were the vendor.
A cancelled subscription in month four is a worse outcome for us than a conversation that ends without one, because the second costs an hour and the first costs a reference.
One: nobody can be freed up to own it
Not "nobody is interested" — nobody has twelve to fifteen days to give across a quarter. This is the most common disqualifier and the one most often argued past, usually with a promise that the MD will handle it personally.
If the honest answer is that everyone is fully committed for the next quarter, wait for the quarter. The software will still exist and the rollout will cost half as much when there is someone to run it. Starting anyway produces the specific failure where configuration is done by a vendor, decisions are made by whoever is nearest, and the system is 60% set up forever.
Two: the process does not exist yet
Software enforces a process. It cannot invent one. If there is currently no answer to "who approves a purchase above KES 50,000", installing a system does not produce an answer — it produces a screen waiting for one, and then a workflow rule set to whatever seemed reasonable on the day, which nobody defends because nobody chose it.
The fix is cheap and takes a week: decide the three thresholds, decide who receives and who adjusts, decide what happens to a short delivery. Write them on a page. Then buy something to enforce them. In that order, the software configuration is a transcription; in the other order, it is a negotiation conducted through a settings screen.
Three: you are under about five people and one location
At this size the coordination problem software solves does not exist yet. Everyone knows what happened because everyone was there. A well-built spreadsheet, one person maintaining it, and a shared drive is genuinely the right tool, and it will stay the right tool until roughly the point where two people need to know the same thing at the same time and are not in the same room.
When the coordination problem actually starts
Under 5 staff, one site
A spreadsheet and a shared drive. Buying software here adds process cost and removes nothing.
5–10 staff, one site
The boundary. Usually triggered by stock rather than headcount — a few hundred item lines is the real threshold.
10–25 staff
Software clearly wins. Two people now need the same figure and one of them is wrong.
Two locations, any size
The single strongest trigger. A second store makes stock invisible immediately, regardless of headcount.
Any size with approvals
The moment money leaves on somebody's say-so and you cannot see it, the argument is over.
Note that the strongest trigger is not size — it is a second location or a delegated spending decision. A six-person business with two branches needs this more than a twenty-person business in one room.
Four: your real problem is somewhere else
Some problems present as information problems and are not. A business that cannot collect from customers has a collections problem, and better ageing reports make it visible without making it better. A business losing money on every job has a pricing problem, and job costing tells you accurately how much you are losing.
Visibility is worth having and it is worth being clear that visibility is what you are buying. The test: if you already knew the number the system would tell you, and the situation has not changed, then the constraint is not knowing — and software will not touch it.
Five: the specific thing you need does not exist
This one requires a vendor to be honest about their own product, so here is ours. If your requirement is genuinely one of these, do not buy from us — or buy knowing you will still be doing it by hand.
- A bill of materials or recipe. No BOM entity, no production order, no yield or consumption variance. This is the one that rules out most real manufacturing and all theoretical-versus-actual food costing.
- Work orders. No work order entity, so property maintenance and equipment servicing as a managed process are not here — maintenance exists as movements on an asset.
- Bank reconciliation. No statement feed, no import, no auto-matching. If that is the pain you are buying to solve, this is not the product.
- A student, patient, tenant, member or vehicle record. None of those entities exist. Schools, clinics, property managers, SACCOs and fleets run the generic modules here, which works for some of what they do and not for the vertical core.
- Manual journal entries and a statutory chart. Accounts have no code column and there is no hand-posted journal, so this is not a statutory book of account.
- Inbound messaging. No WhatsApp helpdesk, no email-to-ticket, no conversation view.
The corollary
Several of those are gaps we know about and would scope for a client who asked in writing. What none of them is, is a thing to discover in month three. If one of them is a condition of your buying, say so in the first meeting — it is a useful conversation rather than an awkward one.
Six: you are mid-crisis
A rollout during a cash crisis, an acquisition, a court case or a peak season is a rollout that will not get the attention it needs and will be blamed for the distraction. The instinct to fix the systems while everything is already broken is understandable and the timing is the worst available.
The exception, and it is real: if the crisis is specifically that you cannot see what you have committed to spend, and orders are being placed that nobody can account for, then that is the fire and software is the extinguisher. Start with procurement, accept the harder rollout, and do not attempt anything else at the same time.
What to do instead, in each case
| Situation | Do this instead | Revisit when |
|---|---|---|
| No owner available | Wait. Genuinely wait. | Somebody has 2 half-days a week for six weeks. |
| No process yet | One week: write down three thresholds and who does what. | The page exists and people have seen it. |
| Under 5 staff, one site | One well-built spreadsheet, one maintainer, a shared drive. | A second location, or a few hundred item lines. |
| Real problem is elsewhere | Fix the pricing, the collections, the hiring. | The constraint is genuinely that nobody can see. |
| Needed thing does not exist | Ask three vendors the same specific question. | Somebody says yes and can show it on screen. |
| Mid-crisis | Handle the crisis. Unless the crisis is invisible spend. | The quarter after. |
Our take
The two disqualifiers worth taking most seriously are no available owner and no existing process, because both are cheap to fix by waiting and expensive to ignore. And be specific with every vendor about the one capability that would make the system worthless to you without it — ask it in the first meeting, ask for it on screen, and treat a confident yes with no demonstration as a no.
Ask us the disqualifying question first
Tell us the one thing that would make this worthless to you and we will answer it plainly in the first conversation. If the answer is that we do not do it, that is an hour well spent for both of us.
See plans & pricingFrequently asked questions
When should a business not buy operations software?
Six situations: nobody can be freed up to own the rollout; the process it would enforce does not exist yet; you are under about five staff on one site; your real problem is pricing or collections rather than visibility; the specific capability you need genuinely is not built; or you are mid-crisis. The first two are the most common and both are fixed cheaply by waiting a quarter.
Is a spreadsheet ever the right answer?
Yes — under about five staff on one site, where everyone knows what happened because everyone was there. One well-built spreadsheet with one maintainer and a shared drive is genuinely correct until two people need the same figure at the same time from different rooms. The strongest trigger to move is a second location or a delegated spending decision, not headcount.
What capabilities are missing that would rule you out?
A bill of materials or recipe with production orders and yield variance; work orders; bank reconciliation against a statement feed; a student, patient, tenant, member or vehicle entity; manual journal entries and a numbered statutory chart; and inbound messaging of any kind. If one of those is a condition of buying, raise it in the first meeting — several are gaps we would scope for a client who asked, and none of them should be discovered in month three.
Should we roll out during a busy period or a crisis?
No, with one exception. A rollout during a cash crisis, an acquisition or a peak season will not get the attention it needs and will then be blamed for the distraction. The exception is when the crisis itself is invisible committed spend — orders being placed that nobody can account for. Then start with procurement, accept the harder rollout, and attempt nothing else simultaneously.
How can we tell whether our problem is really an information problem?
Ask whether you already know the number the system would show you. A business that cannot collect from customers has a collections problem, and better ageing reports make it visible without making it better; a business losing money on every job has a pricing problem, and job costing reports the loss accurately. If you already knew and nothing changed, the constraint is not knowing.
