Custom software vs off-the-shelf: how UK businesses should decide

Buy off-the-shelf software for work that every business does the same way, such as payroll and VAT returns. Pay for custom software only where the way you work is the reason customers pick you, and where a ready-made product would force you to change that. For a firm of 5 to 250 staff, the right answer is usually a mix: a packaged system at the core and a small custom piece that connects to it.

The hard part is telling the two kinds of work apart. From outside, a wholesaler’s ordering rules look standard. Then you find the spreadsheet of customer-specific prices that someone keeps on the side because the current system can’t hold them. If those prices are what keeps trade customers loyal, the rules aren’t standard at all.

The spreadsheet on the side is your best clue

Before comparing products, list the workarounds your team already uses. You’ll recognise some of them: a shared price spreadsheet like that one, the WhatsApp group where drivers confirm deliveries, the notebook by the till. Each one marks a place where your current software doesn’t fit how you work.

Sort those workarounds into two piles. In the first pile go the ones that exist because nobody has set up the existing software properly, or because the team never learned a feature it already has. Fix those with training or configuration; building software to solve them wastes money. The second pile holds workarounds that exist because the process is particular to you: your discount structure, your approval steps, the way you batch orders for a regional route. That second pile is where custom software can pay for itself, and it’s often shorter than people expect.

How the options compare

The choice is rarely all or nothing. There’s a middle option that many firms skip: keep a packaged product and pay for a custom integration or add-on around it.

Factor	Off-the-shelf	Off-the-shelf plus custom integration	Fully custom
Fits your process	You adapt to the product	Core stays standard, your particular steps are built around it	Built around your process
Time to start	Days or weeks	Weeks	Months
Upfront cost	Low, mostly set-up and training	Moderate	Highest
Ongoing cost	Subscription per user or per site	Subscription plus maintenance of the custom part	Hosting, plus paying a developer for every change
Who controls the roadmap	The vendor	The vendor for the core, you for the add-on	You
Tax and compliance updates	Vendor handles them	Vendor handles the regulated core	You pay for every change
Main risk	Price rises, features removed, awkward exports	The integration breaks when either side changes	Overspending on features nobody uses

The compliance row deserves more weight than the others. Rebuilding anything that HMRC or a regulator updates is a poor use of money, because you then own every future rule change.

Three UK checks before you commit

Comparison articles tend to stop at features and price. In the UK, three questions change the answer and come up far less often.

Does it need to talk to HMRC?

HMRC says that all VAT-registered businesses should now be signed up for Making Tax Digital for VAT, and it keeps a list of software that has been tested to connect with its systems. That list is a strong reason to buy your accounting package and never build one. If your custom system holds sales data, connect it to recognised accounting software, or use the bridging software HMRC describes for records kept elsewhere, and let that product handle the submission.

The same logic applies to sole traders and landlords. Since April 2026, those with qualifying income above £50,000 have needed software that works with Making Tax Digital for Income Tax, and HMRC doesn’t supply that software itself. Ask your accountant which rules apply to you; this article isn’t tax advice.

Who will own the code?

This one catches people out with custom work. Under UK copyright law the person who creates a work is normally its first owner, and the government’s guidance on ownership of copyright works explains that commissioning a work doesn’t by itself transfer ownership to the person paying. Section 90 of the Copyright, Designs and Patents Act 1988 says an assignment of copyright has no effect unless it’s in writing and signed by or on behalf of the person assigning it.

In practice, read the intellectual property clause before you sign a development contract. Look for a written assignment of the code to your business on payment, access to the source code repository, and a list of any third-party components the developer reuses under licence. A solicitor can check the wording; the point is to raise it before work starts, when it costs nothing to agree.

Can you get your data back out?

With off-the-shelf software, the equivalent question is about your data. If the product stores customer or staff personal data, the vendor is usually acting as your processor. The ICO says that whenever a controller uses a processor there must be a written contract, and that contract has to cover what happens to the data when the agreement ends, including deleting or returning it on your instruction.

A contract that promises to return your data says nothing about the format. Before you sign, export a sample: a month of orders, your customer list, your price rules. If the file comes out as a PDF or a format no other product reads, you’re more tied in than the contract suggests. The government’s own Technology Code of Practice, written for public bodies, makes the same point from the other side: it asks teams to use open standards so they avoid vendor lock-in, and to consider contractual limitations as part of their purchasing strategy.

A worked example: a 40-person distributor

Take a hypothetical food distributor with 40 staff and 300 trade customers. Orders arrive by phone and email. It uses packaged accounting software and files VAT through it. Every customer has negotiated prices, and two people spend each morning keying orders into the accounts package from their inboxes.

Applying the sorting above, the accounting and VAT side is standard, so the distributor keeps the package it has. Order intake is where the business is particular: customer-specific price lists, cut-off times by delivery route and standing orders that repeat every week. A generic e-commerce plugin would handle the shop front but not the route cut-offs.

The sensible build here is narrow. A trade ordering portal where customers see their own prices, plus an integration that pushes each confirmed order into the accounting package as a sales invoice. The distributor doesn’t touch payroll or stock valuation, which its packaged software already handles. If a ready-made trade ordering product such as EazyOrder Wholesale covers the route cut-offs, that’s worth testing before commissioning anything.

When off-the-shelf is the better call

Start with a packaged product, even an imperfect one, if any of these describe you:

• You can’t yet describe the process you’d want built, step by step, without saying “it depends”. Custom software turns a messy process into a fixed one, so fix the process on paper first.
• The work is regulated and changes yearly.
• You need something running this month.
• Fewer than a handful of people will use it, and the workaround costs them an hour a week. Building rarely pays back on that.

Custom work starts to make sense when the workaround eats hours every day, or when staff type the same data into two systems by hand and customers notice the delays. Even then, keep the first project narrow. Commission custom software for one process and connect it to the tools you already pay for through integrations. Replacing everything at once multiplies the cost and the risk, and you lose the vendor updates on the standard parts.

Frequently asked questions

Can we start off-the-shelf and switch to custom later?

Yes, and it’s a reasonable path. Running a packaged product for six months shows you which features you ignore and which gaps you work around, which makes a later specification much shorter. Keep exporting your data in a usable format while you do, so the move is cheaper when it comes.

What happens to custom software if the developer goes out of business?

If you own the code and have access to the repository, another developer can pick it up, though they’ll need time to learn it. Ask for basic documentation and deployment notes as part of the handover, and check that hosting accounts are in your company’s name, not the developer’s.

Is low-code a third option?

Low-code platforms let you build forms and workflows on top of a vendor’s system with little programming. They suit internal tools with a few users. You still depend on the platform’s pricing and limits, so apply the same data export test before relying on one for anything customer-facing.

How do we get a realistic quote for custom work?

Write down the one process you want to change, who uses it, what goes in and what comes out. A developer can price that far more accurately than a list of features. Our pricing page shows where projects start.

If you have a spreadsheet on the side that you suspect should be a system, book a free call and we’ll tell you whether a packaged product would do, whether a small integration would cover it, or whether it’s worth building, with a fixed price before any work begins.