Build, buy or configure: choosing before you spend
The most expensive technology mistakes in small firms are made before anyone writes a line of code. Here is how I decide between configuring what you have, buying a product or building something new.
By Gary Kellett6 min read
For owners and directors facing a software decision with real money attached.
When a business decides it needs 'a system' for something, the conversation usually jumps straight to products and demos. By the time anyone asks what problem the system is meant to solve, a favourite has been chosen. I have seen this end in expensive software that half the team works around with spreadsheets.
There are really four options for any technology problem: fix the process, configure what you already have, buy a product, or build something. Adding AI is a fifth choice that can sit inside any of the last three. The order matters.
Over 80%
of AI projects fail, and misunderstanding the problem is the most common root cause the researchers found
Option one: fix the process
Before any software, ask whether the steps themselves make sense. I regularly find approvals nobody needs, data typed twice because two teams do not talk, and reports produced every week that nobody reads. Removing a step costs nothing and often solves half the problem.
Option two: configure what you have
Most SMEs use a fraction of what their ERP, CRM, accounts package or Microsoft 365 licence can do. Workflow rules, approval routing, automatic matching and built-in AI features are often already paid for and switched off. Configuration is the cheapest and lowest-risk option, and it should always be checked first.
A question worth asking your supplier
'If we described this problem to your best consultant, how would they solve it using only what we already have?' The answer is frequently better than the one in the sales deck for the next module.
Option three: buy a product
Buy when the job is common to every business like yours: payroll, accounts, a standard CRM, an expenses tool. Thousands of firms share the requirement, so a product will be cheaper and better maintained than anything you could build. The risks are fit and lock-in. Check how your data gets out, what happens to price at renewal, and how much you would have to change your way of working to fit the product.
Ask for a trial on your own data rather than a demo on theirs, and involve the people who will use it every day. A product that looks perfect in a sales presentation can feel very different when it meets your real customers, your real product codes and your real exceptions. If a supplier will not let you try it properly, treat that as information.
Option four: build
Build when the job is what makes you different: the way you quote, the way you schedule, a service your competitors cannot offer. Building used to be the slow, expensive option. With an agentic delivery process I now build in days what was estimated in team-weeks, which changes the sums for small firms. It does not change the rule that you should only build what is genuinely yours.
If you build, insist on owning the code and the documentation. A build you cannot take elsewhere is just a different kind of lock-in.
Plan for the years after the build, too. Software needs looking after: security updates, changes when a connected system changes, and small improvements as the business learns. Agree who will do that, what it costs each month, and how quickly problems get fixed, before you start. A build that nobody maintains slowly becomes the next legacy system.
A five-step way to choose
Step 1: Write the problem in one paragraph
What happens today, who it affects, what it costs, and what 'better' would look like in numbers.
Step 2: Check the process
Walk through the steps with the people who do the work. Remove anything that does not need to happen.
Step 3: Check what you already own
Ask your existing suppliers how they would solve it with what you have.
Step 4: Compare like for like
For each remaining option, estimate the three-year cost: set-up, licences or hosting, support, internal time and the cost to leave.
Step 5: Decide, then prove it small
Try the chosen option on one team or one process before you roll it out.
Where AI fits
AI is not a separate option so much as an ingredient. It can be switched on inside a product you buy, configured inside a platform you already own, or built into a custom tool. The question is the same in each case: which step of the process does it improve, and how will you know? In regulated industries, the right answer is often a properly implemented workflow or ERP system with AI used in a few narrow, checked places, rather than AI at the centre.
If you want a structured way through this decision, the build or buy tool walks you through the questions above and gives you a reasoned recommendation to take into your next board meeting.
Questions directors ask
Is it cheaper to build or buy software for a small business?
For jobs every business shares, such as accounts or payroll, buying is almost always cheaper. For work that makes your business different, building can be cheaper over three years, especially now that delivery takes days rather than months. Compare total cost, including running costs and the cost of leaving.
What should I check before buying new software?
Check whether your existing systems can already do the job, how your data gets out if you leave, what happens to price at renewal, and how much you would need to change your process to fit the product.