Skip to content
App development

Build vs buy: custom software or off-the-shelf for SMEs?

Easy Insight Team ·

Buy off-the-shelf when a product covers most of what you need and you can live with its way of working. Build custom software only for the part of your business that is genuinely different, or where no product fits without painful workarounds. For most SMEs the answer is both: buy the standard tools, build the thin layer that joins them.

Why is this decision harder than it looks?

Because the two options fail in different ways, at different times.

A bought product fails slowly. It does most of the job on day one, and the rest gets handled in spreadsheets, copy-and-paste and a person who "just knows" how to make it work. Nobody budgets for that, so nobody sees it.

A custom build fails visibly and early, usually because the scope was larger than anyone admitted. It also carries costs after launch that people forget: hosting, security updates, and someone who understands the code when it needs changing.

Neither is the safe choice; the question is which failure you can better afford.

When should you buy?

The UK government's own technology guidance is a useful, unglamorous benchmark here. Its purchasing strategy guidance (updated September 2026) says buying makes sense when a commercial product meets most of your needs, little customisation is required, and you can support it. It adds a warning worth taking seriously: even small modifications to off-the-shelf software can remove most of the benefits of buying it.

In practice, buy when:

  • The process is standard. Accounting, payroll, email, file storage, HR records and most CRM work are the same for you as for thousands of other businesses. There is no prize for doing them differently.
  • The vendor's way of working is acceptable. If you would need to bend the product significantly, you lose the upgrades, the support and the speed that were the point of buying.
  • Security and compliance are heavy for the size of the problem. A mature vendor spreads the cost of patching, backups and certifications across all its customers.

When should you build?

The same guidance lists the reasons to build: your need is unique or rare, few suppliers can meet it, commercial products cannot be adapted or integrated, or you need to own the technology. Translated for an SME:

  • The process is how you win work. If the way you quote, schedule, report or serve customers is the reason clients pick you, forcing it into a generic tool flattens the advantage.
  • The workarounds already cost more than a build would. If a person spends a large part of every week moving data between systems, that is a running cost, and it is often bigger than it looks because nobody measures it.
  • No product fits without heavy customisation.
  • You need to own it. Software you plan to sell, license or build a business around should not depend on a vendor's roadmap.

If you do build, scope the first release hard. Our guide to scoping an MVP you can actually afford covers how to cut a build down to the part that earns its keep, and what a custom web app actually costs covers the price.

Is there an option between build and buy?

Yes, and in our view it is the one that wins for most SMEs. Buy the standard systems, then build only the thin layer that makes them work together: an integration that stops double entry, an automation that moves data between tools, or a small internal web app that sits on top of what you already pay for.

You keep the vendor upgrades you paid for and spend custom money only where you are different. It is also a cheap test: if the layer keeps growing, that is evidence for a bigger build; if it stays small, you were right to buy. Our post on business process automation for UK SMEs covers where those joins usually are.

How do the three options compare?

Factor Buy (SaaS / off-the-shelf) Buy and extend Build custom
Time to first use Days Weeks Weeks to months
Fit to your process You adapt to it Close, at the joins Exact
Upfront cost Low Moderate Highest
Ongoing cost Subscription, rises with users Subscription plus upkeep of the layer Hosting, updates, support
Who maintains it The vendor Vendor, plus you for the layer You or your supplier
Ownership You rent it You own the layer You can own all of it
Main risk Lock-in and workarounds The layer growing unmanaged Scope creep and orphaned code

The cost rows are deliberately relative. Real numbers depend on scope, users and team; our app development cost guide puts current UK figures against each type of build.

What should you check before you buy?

Most buying regret comes from the exit, not the entry. Four checks before you sign:

  1. Can you get all your data out? In a usable format, not a PDF export, and without a fee. GOV.UK's choosing technology guidance makes the same point for government teams: always have full control of any data you store, and avoid getting locked into long contracts.
  2. How much notice do they give on price and term changes? The NCSC's guidance on choosing a cloud provider suggests checking what a provider can do with your data and how much notice it gives before changing its terms.
  3. Is there a data processing contract? If the product holds personal data, the vendor is usually your processor, and the ICO's guidance on controller and processor contracts says there must be a written contract, including what happens to the data when the contract ends. Reputable vendors publish one.
  4. What is the evidence behind the security badge? The NCSC is blunt: the evidence behind a certification is what matters, not the certification itself. Check its scope and date.

What should you check before you build?

Three things, and the first is the one most often missed.

  1. Who will own the code? Under the Copyright, Designs and Patents Act 1988, section 11, the author owns copyright unless they are your employee. An agency or freelancer owns what they write by default, and section 90 says an assignment only works in writing signed by them. Put the assignment in the contract before work starts.
  2. Who maintains it after launch? Agree hosting, security updates and a support arrangement up front, and make sure the code, documentation and access credentials are handed over so another developer could pick it up.
  3. Is the first release small enough? If the plan only works when everything is built, it is too big. Ship the smallest useful piece, use it, then decide.

This is our view rather than a rule, but it is how we approach it: the people who scope a build should be the people who build it, which is why we work with senior specialists only.

Frequently asked questions

When should an SME buy software rather than build it?

When a product already does most of what you need, needs little customisation and you can support it yourselves. That covers most accounting, payroll, email, CRM and HR needs. Buying gets you running in days, and the vendor carries the upgrades and security patching.

When is custom software worth building?

When the process is what makes you different, when no product fits the way you actually work without heavy workarounds, or when you need to own the system outright. Build the small part that is genuinely yours, and buy or integrate everything around it.

Do we own the code if an agency builds it for us?

Not automatically. Under UK copyright law the author owns the copyright unless they are your employee, so an outside developer or agency owns the code they write by default. Ownership only passes to you through an assignment in writing signed by them, so put it in the contract before work starts.

What should we check before signing up to a SaaS product?

Four things: whether you can export all your data in a usable format, what the notice period is for price and term changes, whether there is a written data processing contract if it holds personal data, and what evidence the vendor offers for its security claims rather than just a badge on the website.

Is there a middle option between building and buying?

Yes, and it is often the right answer: buy the standard tools and build only the thin layer that connects them, such as an integration, an automation or a small internal app on top. You keep the vendor's upgrades and still get a workflow that fits.


Not sure which side of the line you are on? See how we approach apps and custom web apps, or tell us what you are trying to fix.

Easy Insight is a UK consultancy for AI, web, apps and data — senior specialists only, no juniors.

Next step

Have an app or a product in mind?

We build mobile apps and SaaS products end to end, and run two of our own, Manifold and Quarterly, so the advice comes from production, not a pitch. Apps from £6,000, SaaS and MVP builds from £12,000, fixed price in writing.

Keep reading