Bad software purchases are rarely about the wrong product. They come from evaluating products before understanding the process. Here is a framework that avoids that.
Most bad software purchases are not caused by choosing the wrong product. They are caused by evaluating products before understanding the process the software is supposed to support — at which point every demonstration looks impressive, because there is nothing concrete to test it against.
This is a framework for making the decision defensibly, and for avoiding the specific traps that make software expensive after you have signed.
Write the requirements before you look at anything
Follow the process end to end first. Who does what, in what order, which systems are involved, and where information is retyped from one place into another. Those transcription points are usually where the value is, and they are invisible in a vendor demonstration.
Then split what you need into three lists.
Must have — the requirements without which the software is useless to you. Keep this list short and honest. If everything is a must-have, the list is doing no work.
Should have — genuine improvements you would pay something for.
Nice to have — everything else, including the features that impressed you in a demonstration but that nobody would use weekly.
Write this down before your first call. Vendors are skilled at reframing your requirements around what their product does well, and a written list is the only reliable defence.
The questions that actually differentiate products
Feature lists converge — most products in a category do most of the same things. These questions separate them more usefully.
What does it connect to, and how?
A documented API, prebuilt connectors to the tools you already run, and webhook support are worth more than a longer feature list. Software that cannot exchange data with anything else becomes the thing everyone works around, and you end up paying staff to move information by hand. Where a product does most of what you need but will not talk to your other systems, our systems integration team builds the connection rather than replacing the product.
How do we get our data out?
Ask this before you sign, not when you are leaving. Can you export everything — records, attachments, history — in a usable format, on demand, without paying a fee? A vendor who is evasive here is telling you something important about the relationship.
What is the real total cost?
The headline per-user price is frequently a fraction of it. Ask about implementation and configuration, data migration, training, integration or API access, whether it is charged separately or by call volume, support tiers, and — the one that catches people — what happens to the price at renewal after any introductory discount.
Ask specifically how pricing changes as you grow. Per-user pricing that is comfortable at five people can be uncomfortable at twenty-five, and per-transaction pricing that suits low volume can become the largest line in your software budget.
Who is responsible when it breaks?
Response times, escalation, and whether support is included or extra. Also worth asking: what is the maintenance window, and how much notice do you get before changes? A product that updates without warning during your busiest period is a genuine operational risk.
Test it against your actual work
A demonstration shows you the path the vendor has rehearsed. A trial with your own data shows you what your team will experience.
Set up a trial with real records and real cases, including the awkward ones — the customer with an unusual arrangement, the order that needs an exception, the report your accountant insists on. Then have the people who will actually use it daily do their real work in it for a fortnight, not a manager clicking through screens.
Two things to watch for specifically. How many clicks does the most frequent task take? Something done fifty times a day at three extra clicks is a meaningful ongoing cost. And what happens at the exceptions? Software usually handles the standard case well; the difference between products shows up at the edges, which is also where your staff will lose time.
The traps worth naming
Buying for the business you plan to be. Enterprise features purchased in anticipation of growth are paid for now, add complexity now, and are frequently still unused when you eventually reach that size — by which time your requirements have changed anyway.
Letting one enthusiastic person decide. Software chosen by a single champion often fails at adoption, because nobody else was involved in the trade-offs and everyone else experiences it as an imposition.
Assuming migration is included. Getting your existing data in — cleaned, deduplicated, mapped to the new structure — is frequently the largest single cost of a software change, and it is rarely in the quote.
Signing a long contract for a discount. A three-year term at a lower rate is only a saving if the product still suits you in year two. For anything you have not used in production, prefer a shorter term even at a higher price.
Ignoring the exit. Everything ends eventually. Knowing how you would leave — and confirming you can take your data — costs nothing at the point of purchase and a great deal later.
Implementation decides whether it works
The purchase is the smaller half. Software fails at adoption far more often than at capability.
What helps: involving the people who do the work in the decision, so the exceptions they know about are accounted for; cleaning data before migrating rather than importing a mess into a new system; setting a date to retire the old system, because indefinite parallel running guarantees half the team never moves; training a named person in each team so routine questions have a low-friction answer; and expecting a temporary dip in productivity rather than being surprised by it.
Introducing a system during your busiest month is the most reliable way to have it rejected regardless of its merits. Our IT support team can take on the migration and rollout so it does not land entirely on whoever is already busiest.
Frequently asked questions
How long should the evaluation take?
Proportionate to the cost of being wrong. For a tool one team uses, a couple of weeks including a trial is reasonable. For something the whole business depends on, longer — but set a decision date, because evaluations without one drift for months while the original problem persists.
Should we build instead of buy?
Buy where your requirements are conventional; build where the process is genuinely specific to your business and gives you an advantage. The frequent middle answer is to buy the core system and build the integrations between it and what you already run.
How many products should we compare?
Three is usually right. One gives you no basis for comparison; more than four tends to produce spreadsheets rather than decisions. Shortlist on your must-have list, then trial two properly.
What if the team resists?
Resistance is usually information rather than obstinacy — often that the new system does not handle a real case the old one did, and nobody asked. Find out what specifically is not working before treating it as a training problem.
Should we take the vendor's implementation package?
Frequently worth it for complex systems, provided you understand what is included and what remains yours. Ask specifically who is responsible for data migration and data cleaning, which is where these arrangements are most often vaguer than they appear.
A workable sequence
Map the process. Write your must-haves before you speak to anyone. Shortlist three. Trial two with your real data and your real awkward cases. Confirm total cost, integration and data export before signing. Then plan the implementation as carefully as you planned the purchase.
That sequence takes longer than accepting the first demonstration and is considerably cheaper than replacing the wrong system in eighteen months. If you would like an outside view on requirements or on which trade-offs actually matter for your setup, our IT consultancy team does this groundwork — and our digital transformation guide covers the process-mapping side in more detail. Get in touch to talk it through.
