Jay Did We regularly see companies abandon software six months after buying it. Rarely because it was bad. Almost always because it was designed for a context that is not theirs.
Here are the five gaps we encounter most often.
1. The software assumes a permanent connection
Many modern applications depend entirely on the network: without a connection, the screen freezes. That is a defensible choice in an office on redundant fibre. It is far less so for a shop, a warehouse or a hotel where the link drops several times a week.
The question to ask during a demo is not "does it work offline?" — the sales answer is always yes. Ask instead: what exactly happens if I cut the connection mid-entry? Then do it, during the demo.
2. Local payment methods are not supported
A point-of-sale system that only handles bank cards is unusable where most transactions are cash and mobile money. Adding these afterwards is rarely a simple configuration: it touches accounting, reconciliation and closing statements.
Check how the CFA franc is handled too: rounding, the common absence of decimals, and amount formatting. Software that forces two decimals everywhere produces receipts nobody reads correctly.
3. Support is in another time zone
A vendor whose support opens at 9 a.m. Central European Time answers from 8 a.m. in Lomé — which remains workable. A North American vendor answers from 2 or 3 p.m. If your till goes down on a busy Saturday morning, the difference is not theoretical.
Ask for actual hours, the contractual response commitment, and above all: in which language and through which channel? Support via a web form with a 48-hour reply is not support for a production system.
4. The data model does not match actual practice
This is the costliest gap, because it only appears after deployment. Some real examples:
- hotel software that accepts only one holder per booking, in a market where family group bookings are the norm;
- an invoicing system that requires a VAT number for every customer, when a large share of the clientele is informal;
- stock management that refuses decimal quantities, unusable for anything sold by weight or volume.
These constraints are baked into the data model. Working around them requires changing the core of the software, which a foreign vendor will not do for one isolated client.
5. Nobody planned the data migration
Your data already exists: in a spreadsheet, in the old software, in notebooks. The cost and time of migrating it are almost always underestimated, and this is the step that derails schedules.
Before signing, insist on a test migration using a real sample — your actual data, not a demo set. You will discover in a few hours what you would otherwise discover in three months.
How we run this decision
We systematically ask for a demo run with the client's data and by the end users, not by the salesperson. A cashier entering ten real sales reveals in twenty minutes what no requirements document captures.
And when no product on the market fits, the alternative is not necessarily full custom development: often an existing tool plus one specific module costs three times less and deploys twice as fast.