Buy the standard parts, build the part that is yours

The spreadsheet nobody admits to

Most small and mid-sized businesses I walk into have perfectly sensible software. There is an accounts package, a payroll system, often a CRM, sometimes an ERP. All of it bought off the shelf, all of it doing its job.

Next to it sits a spreadsheet. One person built it, one person understands it, and the whole operation quietly depends on it. It holds the production plan, or the weekly forecast, or the pricing logic that the ERP could never quite handle.

That spreadsheet is where the build-or-buy question actually lives. Nobody is seriously asking whether to write their own accounting system. The real question is what to do about the part of the business that the bought software does not cover.

Most off-the-shelf software works

I build custom tools for a living, so I should say this first: packaged software is usually the right answer.

In 2025 Ipsos surveyed 2,000 UK SMEs for the Department for Business and Trade. Of those using digital technology, 91% said it had a positive effect on the business. Only 2% said it had made operations harder.

Accounting, payroll, invoicing and CRM are solved problems. Thousands of businesses have already found the edge cases, and the vendor has fixed them. Paying someone like me to rebuild any of that would be a waste of your money.

Where packaged software stops fitting

The fit runs out at the process that is specific to you. How you plan production around short shelf life. How you price for a customer with three different rebate agreements. How you decide what to order on a Thursday.

The same Ipsos study found that SMEs strongly prefer technology that can be moulded to their existing processes, instead of the business adapting to the technology. One manufacturer put it plainly: they want technology to fit what they need, not the other way round.

When that fit is missing, it tends to surface late. Panorama Consulting's 2026 ERP report found that the most common cause of a budget overrun was a fit gap discovered after the project had started. And in the Ipsos online survey, 24% of SMEs said they had adopted technology they were not fully using.

That last figure is the spreadsheet again. The system was bought, the awkward process did not fit, and the work moved back into Excel.

The cost of bending the business to the tool

The usual advice from vendors is to change your process to match the software. Sometimes that is right. It is never free.

The licence fee is the visible cost. The rest is paid in staff time: retraining people who were good at the old way, running both systems in parallel, and building workarounds for the cases the new one cannot handle. The Ipsos interviews found implementation often took longer and needed more resources than expected, with staff resistance and integration the recurring problems.

Panorama found the same thing from the other side. The most common cause of an ERP schedule overrun was organisational resistance: delayed sign-offs and pushback on standardising how things are done.

For a business of forty people, that disruption lands on the same handful of staff who also keep the place running. If the process being changed is one that works, you are paying twice: once for the software and once to become worse at something you were good at.

"We're unique" is usually wrong

Here is the uncomfortable part. Most businesses that believe they need bespoke software do not.

The Ipsos researchers noted that some SMEs want custom solutions because they do not know what existing products can do. A 2016 study in the Information Systems Journal followed four SMEs through ERP projects and found they often changed the system to fix misfits that were perceived, not real. In the Ipsos survey, only 8% of SMEs said the software they need is too specialist or does not exist.

So before commissioning anything, put the process through three questions.

1. Does it win you customers or protect your margin? If the way you do it is why you are faster, cheaper or more reliable than competitors, it is worth protecting. If it is just habit, it is not.
2. Would changing it cost more than the software? Count the retraining, the disruption and what you would lose. If the answer is a shrug, change the process.
3. Have you properly tried a packaged option? A demo does not count. Run a real week of work through it and see where it breaks.

If you cannot answer yes to all three, buy the standard product and adapt. You will save money and I will not be offended.

What custom costs you

Custom software has two costs that rarely appear in the quote.

The first is maintenance. Published estimates of how much of a system's lifetime cost comes after the build range from around 60% to over 80%. A small internal tool sits at the gentle end of that, but the principle holds: the build is the deposit, not the price.

The second is dependence. If one person built it and only that person understands it, you have replaced a fragile spreadsheet with a fragile application. That applies to tools built by me as much as anyone.

Both are manageable if they are dealt with at the start.

• Keep it small. Standish Group data puts the success rate of small software projects at 62%, against 6% for large ones. One process, one tool.
• Own everything. The code repository, the data and the hosting account should be in your name from day one.
• Insist on boring technology. Common languages and standard databases, so any competent developer can pick it up.
• Get it written down. Documentation and a handover plan are part of the job, not an optional extra.
• Budget for upkeep. Agree a maintenance arrangement before the build starts, not after something breaks.

The rule

Buy the standard parts. Build the part that is yours.

In practice that means keeping the accounts package, the payroll system and the CRM exactly as they are. Then build one thin layer on top that reads from them and handles the one or two processes that make your business what it is. The planning logic. The forecast. The report that currently takes someone every Monday morning.

You get the reliability of bought software where the work is standard, and a tool shaped around your people where it is not. Nobody has to relearn their job to suit a vendor's idea of how it should be done.

If you have a spreadsheet like the one at the top of this post and are not sure which side of the line it falls on, I am happy to look at it and tell you. Sometimes the answer is a product you can buy this afternoon.