Custom software vs off-the-shelf: how to decide what to build and what to buy

Buy off-the-shelf software for the work your business does the same way as everyone else, and build custom software only for the work that makes customers choose you. Payroll, email, accounting and most CRM needs are solved problems: a good product will be cheaper, faster to adopt and better maintained than anything you build. Custom software earns its cost when the process it supports is your competitive edge, when no product fits without heavy workarounds, or when licence costs and integration pain at your scale outgrow the cost of owning the code.

That is the short answer. The rest of this guide is the detail that turns it into a decision you can defend to a board or a finance director: what each option really costs over several years, where the hidden lock-in sits on both sides, why most good answers are a mix of the two, and a checklist you can run in a single workshop. It is written for founders, CTOs and operations leads who are weighing a product subscription against a build, and it is honest about the many cases where building is the wrong call.

What counts as off-the-shelf, custom and the middle ground

The debate is often framed as two options, but in practice there are at least four, and most organisations already use all of them. It helps to name them precisely before comparing anything.

• Off-the-shelf (commercial) software: a product built once and sold to many customers, usually as a subscription (SaaS) and sometimes as a licence you install. You configure it, but you do not control its roadmap. Examples: accounting suites, help desks, HR systems, e-commerce platforms.
• Open-source software: code you can use, inspect and modify under a licence, often run yourself or bought as a hosted service. Free to download is not the same as free to run: hosting, upgrades, security patches and expertise still cost time.
• Configurable platforms and low-code tools: products designed to be extended, such as a CRM with custom objects and workflows, a headless commerce engine, or a low-code builder for internal tools. You get a head start but inherit the platform's limits and pricing model.
• Custom (bespoke) software: an application designed and built for your organisation's specific processes, owned by you, and changed whenever you decide. Our custom software development guide covers this route in depth.

Most real systems are combinations. A typical scale-up runs a bought CRM, a bought finance package, a custom customer portal and a set of integrations gluing them together. So the useful question is rarely 'build or buy?' in the abstract. It is 'for this specific capability, which option gives us the best result over the next three to five years?'

The question that decides most cases: is it a utility or a differentiator?

The clearest framework comes from Martin Fowler's utility versus strategic dichotomy. A utility function is one where doing it better than your competitors makes no difference to your customers; payroll is his example. The risk with a utility is a failure, so you want it reliable and cheap. A strategic function is one where how you do it sets you apart. The risk there is being slow, so you want speed and control, and cost matters less than the opportunity you lose by waiting.

Fowler's advice for utilities is blunt: buy a package and change your business process to fit it, rather than paying to bend the package to your habits. For strategic functions, he warns against running the same software as your competitors, because it removes the very thing that differentiates you. He also notes that organisations routinely overestimate how much of their work is strategic, suggesting the split is closer to 95/5 than 80/20.

The UK Government Digital Service reaches the same conclusion from a different direction. Its guidance on whether to build or buy tells teams that their needs are more likely to be common than unique, that heavy customisation of a bought product is costly to maintain, and that building makes sense where a capability is central to the organisation's mission. It also makes a point many vendor comparisons skip: whichever route you take, you cannot outsource the risk.

If every competitor can buy the same tool on the same terms, that tool cannot be the reason customers choose you. Buy it, run it well and spend your build budget where it changes the outcome.

A useful test: imagine a competitor licensed the exact system you are considering tomorrow. If that would not worry you, the capability is a utility and you should buy. If it would, because the way you price, schedule, match, underwrite or serve customers is the business, then it is a candidate for custom software, or at least for a custom layer on top of bought foundations.

Custom vs off-the-shelf at a glance

When off-the-shelf software is the right answer

Buying should be your default. It is the right call far more often than software studios tend to admit, and a good partner will tell you so. Choose a product when most of the following are true:

• The process is common. Accounting, payroll, email, document storage, ticketing, basic CRM and project tracking work much the same everywhere. Products in these categories embody years of other companies' lessons.
• You can live with the product's way of working. If adopting its workflow costs you little, adapt your process rather than the software. That is Fowler's advice, and it is usually the cheapest change you will make.
• You need it working now. A subscription can be live in days. If the business case depends on speed and the capability is not your edge, the months a build takes are a real cost.
• You lack in-house technical ownership. Custom software needs someone accountable for it after launch. If nobody will own its roadmap, a maintained product is safer.
• Compliance is part of the product. Payroll, tax filing and some regulated reporting change every year. A vendor serving thousands of customers absorbs those changes for you.
• The market is mature and competitive. Many credible vendors means fair pricing, good export options and a realistic plan B if your chosen supplier disappoints.

Notice what is not on the list: 'it is cheaper'. A subscription often is cheaper in year one and sometimes for ever, but the comparison has to cover the full life of the system, which we come to below.

When custom software is the right answer

Building is justified when the software is the business, or when bought software is actively holding the business back. These are the signals worth taking seriously:

• The capability is your competitive edge. Your pricing engine, your matching algorithm, your patient pathway, your underwriting rules or your customer experience is what customers pay for, and you want it to be hard to copy.
• No product fits without workarounds. Teams keep spreadsheets beside the system, re-key data between tools, or run critical steps outside any software at all. Workarounds are a recurring cost that never shows up on an invoice.
• You are selling the software. If the application is the product, as with a SaaS platform or a customer-facing app, you need to own it. See our SaaS development guide.
• Integration is the real problem. When value comes from joining several systems, devices or data sources in a way no vendor supports, a custom service in the middle is often simpler than forcing products to talk.
• Per-seat or usage pricing breaks at your scale. A tool priced per user can become your largest software cost once you have many occasional users, such as field staff, partners or customers who log in a few times a month.
• Data control is non-negotiable. Regulatory, contractual or strategic reasons require you to decide exactly where data lives, who processes it and how long it is kept.
• The process is still changing fast. If you are inventing how the work is done, you need to change the software weekly. Waiting for a vendor's roadmap is too slow.

One warning sign points the other way: building custom software to fix a process nobody has agreed on. Software encodes decisions. If the decisions are not made, you will pay a development team to discover them slowly. Map and agree the process first, then decide what to buy or build.

The hybrid: buy the foundations, build the edge

The best answer is usually a mix. You buy the commodity layers, such as identity, payments, email delivery, accounting and CRM, and build the thin layer where you differentiate, connected through APIs. Done well, this gives you most of the speed of buying and most of the control of building. Done badly, it gives you the costs of both. The options below are the common shapes.

Configuration is not customisation

The most expensive outcome in this whole debate is a heavily customised off-the-shelf system: a package modified so deeply that every vendor upgrade becomes a project, and nobody can remember why half the changes were made. The GDS guidance draws the line clearly, encouraging teams to configure rather than customise. If you find yourself writing code inside a product to make it do something it was not designed for, stop and ask whether that capability should live in a separate custom service instead.

Total cost of ownership: compare like with like

Most build-versus-buy spreadsheets compare a subscription fee with a development quote. That is not a fair comparison. Each option has costs that do not appear in the headline number, and the honest way to compare them is over the expected life of the system, usually three to five years, with every cost category written down.

What off-the-shelf really costs

• Subscriptions that grow. Fees usually scale with users, usage, records or tier, so they rise as you succeed. They also rise on their own: Zylo's 2025 SaaS Management Index reported average SaaS spend per employee up 21.9% year on year.
• Tier jumps. The single feature you need, such as single sign-on, audit logs or API access, is often only in a higher plan.
• Implementation and configuration. Someone has to set up fields, workflows, permissions and reports, often a consultant or a team member for weeks.
• Data migration and integration. Moving data in and connecting the product to your other systems is usually the largest one-off cost. See our guide to system integration.
• Workarounds. Time staff spend on spreadsheets, double entry and manual steps the product does not cover. Measure it in hours per week; it adds up.
• Administration and training. Licence management, onboarding new staff, keeping configuration tidy.
• Exit. Extracting your data and moving to something else when the product, its price or its owner changes.

What custom software really costs

• Discovery and design. Agreeing the process, the scope of the first release and how it will look and work.
• The build itself. Engineering, testing and project leadership for the first release. Our guide to custom software development cost explains how estimates are built.
• Hosting and third-party services. Cloud infrastructure, monitoring, email delivery, maps or payment APIs.
• Maintenance. Security patches, dependency and framework upgrades, bug fixes, and keeping up with browser and operating-system changes. This never stops while the software is in use.
• Evolution. New features as the business changes. This is the point of owning the software, but it needs a budget.
• Knowledge. Documentation, handover and making sure more than one person understands the system.

A worked example in weeks and team shape

Take a services company that schedules field engineers and wants customers to book and track visits online. The figures below are illustrative, to show the shape of the comparison rather than a quote for any real project.

Buy route. A field-service product is selected after two weeks of trials. One internal administrator spends roughly four to six weeks part-time on configuration, data import and staff training, and an integration specialist spends one to two weeks connecting it to the finance system. Ongoing: a subscription per engineer and per office user, plus a few hours a week of administration. The customer booking page uses the product's standard portal, which looks like everyone else's.

Build route. A small team, one senior engineer leading, one further engineer and a part-time designer, delivers a first release with booking, scheduling rules specific to the company and live visit tracking in roughly ten to fourteen weeks. Ongoing: hosting, plus perhaps two to four days a month of maintenance and a budget for new features.

Hybrid route. Keep a bought field-service product for engineer scheduling and job records, and build only the customer-facing booking and tracking experience on top of its API. Perhaps five to eight weeks with the same small team, and the differentiating part, the experience customers see, is fully owned. For many companies in this position the hybrid wins. To size your own scenario, try the software cost calculator, which works in effort and team shape.

Lock-in, data and exit: the risk on both sides

Vendor lock-in is usually discussed as a weakness of off-the-shelf software, but custom software has its own version. Plan the exit before you sign for either.

With a product, check how you get your data out: in what format, through which API, including attachments, history and audit logs, and whether the export is complete enough to load into a competitor. Read the contract for notice periods, auto-renewals, price-increase clauses and what happens to your data after termination. In the EU, the Data Act has applied since 12 September 2025 and requires providers of cloud and data-processing services, which covers SaaS, to remove obstacles to switching; from 12 January 2027 they can no longer charge for switching, including data egress. That helps, but it does not rebuild your workflows in the new tool for you.

With custom software, lock-in comes from not owning what you paid for. Make sure the contract assigns the intellectual property to you, that the code lives in a repository you control, that the cloud accounts are in your name, and that the system is documented well enough for another team to take over. Watch for proprietary frameworks or platforms that only your supplier knows. If one developer holds all the knowledge, you are locked in to a person, which is worse than being locked in to a company.

• Can we export all our data, in an open format, without the vendor's help?
• Who owns the code, designs and infrastructure accounts, from day one?
• Could a different team run and change this system within a month?
• What does the contract say about price increases, renewals and termination?
• If the supplier were acquired or shut down tomorrow, what would we do on Monday?

Security and compliance: who is responsible for what

A reputable SaaS vendor runs security at a scale few companies can match: dedicated teams, and independent assurance such as SOC 2 reports or ISO/IEC 27001 certification. That is a genuine argument for buying. But the responsibility is shared. You still configure access, manage users, decide what data goes in and vet the vendor, including its sub-processors. Under data-protection laws such as the GDPR, you remain the controller and need a proper data-processing agreement with each vendor that handles personal data.

With custom software, you own the whole stack, so security has to be designed in from the first sprint: authentication, access control, encryption, logging, dependency updates and regular testing. The upside is precision. You can keep data in the region you choose, collect only what you need, and build exactly the audit trail your regulator expects. The cost is that nobody else is doing it for you: budget for security work in every release, not as a one-off test before launch.

A decision checklist you can run in one workshop

Score each capability you are deciding on against the questions below. There is no magic threshold, but if most answers point one way, you have your answer. If they split, look hard at a hybrid.

Common mistakes, and how to avoid them

• Building commodity software out of pride. A custom CRM or ticketing system rarely beats the products that dozens of teams have refined for years. Spend your build budget on the edge, not the plumbing.
• Over-customising a product. Bending a package until upgrades break is the worst of both worlds. If you need that much change, build the capability separately.
• Comparing year-one costs only. Subscriptions rise with headcount and price lists; custom software needs maintenance. Compare over three to five years.
• Forgetting the people cost. Training, change management and the hours lost to workarounds are real, whichever option you pick.
• Choosing a tool before agreeing the process. Both a product and a build will encode whatever process you give them. Agree it first.
• Trusting a demo over a trial. Test products with your own data and your three hardest real scenarios, not the vendor's script.
• No exit plan. Decide on day one how you would leave, and check the contract supports it.
• Building everything at once. Custom software should start with the smallest release that proves value. Our guide on scoping an MVP shows how.

How to make the decision in two to four weeks

1. Map the process. Write down how the work actually happens today, who does it, and where it hurts. Separate the steps that differentiate you from the ones that are routine.
2. Write requirements as outcomes. List must-haves and nice-to-haves as things users need to achieve, not as features copied from a vendor's brochure.
3. Shortlist and trial products. Pick two or three credible products and trial them with real data and your hardest scenarios. Note every workaround.
4. Sketch the custom option. Have an engineer outline what a first release would include, the team it would need and a range of weeks. A short paid discovery is worth it for larger decisions.
5. Compare total cost and risk. Put both options side by side over three to five years, including integration, workarounds, maintenance and exit.
6. Decide per capability. You may buy three things and build one. Record why, so you can revisit the decision as the business grows.
7. Review yearly. A good decision today can become a bad one as you scale, as products improve or as a utility becomes strategic, or the reverse.

How Authect approaches the build-or-buy decision

Authect is a founder-led software development studio, so when you ask us whether to build, you talk to the founders who would build it, not to a salesperson with a target. We often recommend buying, or a hybrid where a bought product does the heavy lifting and we build only the part that sets you apart. When custom software is the right answer, every project is led by a senior engineer, delivery is AI-accelerated with an engineer reviewing every line, and you own the code, infrastructure and designs from day one, with no lock-in.

If you already run bought or custom systems and are not sure whether to keep, replace or extend them, a software audit is a sensible first step. Otherwise, tell us what you are deciding and we will give you a straight answer, including when the answer is a subscription.