How to Choose Business Software That Gets Used

Choosing business software usually starts with a feature comparison. That is the wrong first step, and it is the reason so many tools end up unused a year later.

This guide sets out a selection method built around one problem, one metric and a 30-day trial, with the evidence behind each step.

Why business software purchases fail

The failure rate is high and well documented. The Standish Group, CHAOS Report puts the share of software projects that finish on time, on budget and to expectation at roughly 31%. Vietnam’s Ministry of Planning and Investment, in a 2022 survey of 1,300 companies conducted with USAID LinkSME, found that 48.8% of firms had adopted a digital solution and then stopped using it because it did not fit.

Across both figures, the causes are organisational rather than technical:

• The tool was chosen against a feature list instead of a specific problem.
• Nobody was made responsible for keeping the data current.
• The new system did not connect to existing work, so staff maintained a parallel spreadsheet and eventually abandoned the tool.

Spreadsheets are the usual fallback, and they carry their own cost: a review of 13 audits of operational spreadsheets by Raymond Panko found that 94% contained at least one error. The quiet part is that a spreadsheet never reports its own mistakes.

Step 1: define the problem your business software must solve

Write one sentence that names where money is leaking today. Good examples: enquiries go unanswered for a day; staff spend six hours a week re-entering orders; nobody knows which channel produced last month’s revenue.

Then attach a number to it and record today’s value. Response time in hours. Hours of manual entry per week. Repeat purchase rate. Without this baseline, no later discussion about value can be settled with evidence.

If you cannot write that sentence, the honest conclusion is that you do not yet need new business software. That is a legitimate outcome of the exercise and far cheaper than discovering it after a purchase. The 90-day method for measuring software ROI covers the measurement side in more detail.

Step 2: buy or build your business software

Buy when your process matches the market

Accounting, payroll, basic inventory and standard sales pipelines are solved problems. An off-the-shelf tool will be cheaper, faster to adopt and better maintained than anything a small team can build. Accept its workflow rather than bending it.

Build when the process is the advantage

Custom work earns its cost when the way you operate is what differentiates you, when integrations across several systems are the main requirement, or when every available product forces a workflow that costs you customers.

Be realistic about the ongoing cost of building. Stripe’s Developer Coefficient report found developers spend around 42% of their time on maintenance and bad code. Custom software is a standing commitment, not a one-off purchase. Our note on software project estimation explains where budgets usually slip.

Step 3: pilot the business software for 30 days

Shortlist no more than three options. Beyond three, comparison becomes procurement theatre and the decision drifts towards whoever demos best.

• Use real data. Demo data hides every integration problem you will actually face.
• Limit the group. Two or three people, doing their normal work, not a parallel test.
• Cap the parallel running at two weeks. Asking staff to enter everything twice for longer guarantees they pick one system and quietly drop the other.
• Name an owner. One person, not a department, responsible for data quality during the trial.

At the end of the pilot, compare the number you recorded in step 1. If it has not moved, do not scale up on the assumption that it will later. Find out whether the problem was the fit, the training or the choice of problem itself.

Questions to ask any business software vendor

Five questions separate a workable supplier from a costly one:

• Who owns the data, and how do we export it? Ask for the export format, not a reassurance.
• What does migration look like in practice? Who does it, how long, and at what cost.
• What is the support commitment? Response times in writing, not a promise of being helpful.
• What happens at renewal? How price changes, and what happens if you leave.
• Can we speak to a customer of similar size? A vendor used to small clients will have one ready.

For custom development the same questions apply, plus intellectual property and continuity of the team. Published starting rates, such as our own software outsourcing rates in Vietnam, are a useful reference point before any vendor conversation.

A short checklist for choosing business software

• One sentence naming the problem in money terms.
• One metric, with today’s value written down.
• At most three options on the shortlist.
• A 30-day pilot with real data and a named owner.
• A decision rule agreed in advance: what change counts as success.

None of these steps require technical expertise. They require deciding what the software is for before deciding what it should have.

What adoption of business software looks like when it works

A successful rollout is quieter than most people expect. There is no moment where the company switches over and celebrates. Instead, three things happen in sequence over about three months.

In the first weeks output usually dips. People are learning, and the old method still feels faster. Teams that abandon a tool often do so here, mistaking the learning curve for a verdict. The honest response is to hold the line for the agreed pilot length and judge at the end, not during.

By the second month the parallel system disappears. Nobody consults the old spreadsheet because the new place has fresher information. This is the single clearest signal of adoption, and it is easy to check: ask someone about their last conversation with a specific customer and watch where they look for the answer.

By the third month the metric from step one has moved, or it has not. If it has, expand to the next team with the same discipline: baseline, pilot, owner, decision rule. If it has not, the useful question is whether the problem was defined correctly in the first place, rather than whether a different vendor would have done better.

Common objections to new business software

• “The team is too busy right now.” Usually true, and usually permanent. A pilot limited to two or three people exists precisely so the rest of the company is not disrupted.
• “We tried this before and it failed.” Worth taking seriously. Ask what metric was used last time; in most cases there was none, which means the previous attempt produced no evidence either way.
• “It is cheaper to keep doing it manually.” Compare both sides: the monthly fee against the hours spent and the revenue lost to slow responses. Count the cost of doing nothing, not only the cost of acting.

Who should make the business software decision

In a company of twenty people the decision often lands on whoever is most comfortable with technology. That is usually the wrong person. The decision belongs to whoever owns the number the tool is meant to move: the sales lead for response times, operations for manual effort, finance for error costs.

The technically minded colleague is still valuable, but in a different role: checking that data can be exported, that integrations exist, and that the vendor’s claims survive contact with your actual systems. Separating these two roles prevents the most common failure mode, where a tool is chosen because it is interesting rather than because it is needed.

One more rule worth setting in advance: agree who can say no. A pilot without the authority to end it is not a pilot, it is a rollout with extra steps.

Frequently asked questions

How do you choose business software for a small company?

Start from the problem that is costing money, not from a feature comparison. Shortlist at most three options, run a 30-day pilot with real data and a small team, and measure one number before and after.

Should a small business buy off-the-shelf software or build custom?

Buy when your process matches the market: accounting, payroll, basic sales. Build when the process is your competitive advantage, or when every available tool forces your team to work in a way that loses customers.

What are the warning signs that a software purchase will fail?

No baseline metric, no named owner for the data, staff keeping a parallel spreadsheet after a month, and a decision driven by the longest feature list rather than the clearest problem.

In short: good business software decisions start from a problem and a number, not a feature grid. What is the one number you would use to judge your next purchase?