Buying software means licensing an existing product — Salesforce, HubSpot, Xero, Shopify, Zendesk, or any of the thousands of SaaS products built for specific business functions.

You pay a subscription, configure the product to your needs within its existing parameters, and get something working without a development project.

The advantages are real. The software exists. It works today. The vendor has invested millions in building and maintaining it, ironing out bugs you'll never have to encounter, and adding features based on the needs of thousands of customers. Implementation timelines are measured in days or weeks, not months.

The limitation is equally real. Off-the-shelf software is built for the median customer in a given category. It handles the common cases well, the edge cases with workarounds, and the truly specific cases not at all. You adapt your processes to fit the software as much as the software fits your processes. For businesses that operate like most businesses in their category, this is fine. For businesses whose differentiation comes partly from doing things differently, it's a persistent friction. Many end up having too many tools to manage a full workflow.

Building custom software means commissioning software developed specifically for your business — designed around your processes, your data, your workflows, and your specific requirements.

Nothing is pre-built. Everything reflects the specific way you operate.

The advantage is total fit. Software that's built for your business does exactly what your business needs without workarounds, without unused features cluttering the interface, and without the requirement to change your processes to match the tool's assumptions.

The cost is real. Custom software requires a development project — design, build, testing, deployment — with associated time and budget. It requires ongoing maintenance that a SaaS vendor would otherwise handle. And it requires you to know, with sufficient precision, what you need the software to do before it's built — because changes during development are expensive in ways that subscription changes aren't.

Rather than a formula, the build vs buy decision is better approached through four questions. The answers place most businesses clearly enough on one side that the decision becomes obvious.

1. Is this process a source of competitive advantage?

This is the most important question and the one most frameworks leave out.

Off-the-shelf software is available to every business in your category. Your competitors can buy Salesforce. They can buy the same customer support platform. They can implement the same accounting system. If the process those tools support is one where doing it differently from competitors creates real business value — faster, cheaper, more accurately, with better customer experience — then software built to handle that process the way everyone else handles it is actively working against your differentiation.

Custom software built around the specific way you operate, by contrast, is a competitive asset. It encodes your approach to the process and makes it systematic, scalable, and difficult for competitors to replicate.

If the process is genuinely differentiating: build. If it's infrastructure — important but not where you win or lose — buy.

2. How well does the available software actually fit your requirements?

The gap between "it mostly does what we need" and "it does what we need" is where the real cost of off-the-shelf software lives.

Most SaaS products demonstrate their fit in sales processes, where demos are designed to show the product's capabilities in the best light. The gap usually emerges in implementation — when the specific workflow you need turns out to require a workaround, when the data model doesn't quite match how your business works, when an integration that was described as straightforward turns out to involve significant configuration.

Map your actual requirements against the software's actual capabilities — not the demo, the actual working product. The things you need to do every day. The edge cases that represent a meaningful proportion of your volume. The integrations with other systems you can't change. The reports and views your team actually needs.

If the fit is 90%+: buy is probably right, with eyes open to the 10% you're working around. If the fit is 70-85%: the workarounds add up and build becomes worth evaluating. Below 70%: you're adapting your operations significantly to fit the software, and a custom build is almost certainly the right answer.

3. What does total cost of ownership actually look like?

Build feels expensive because the cost is visible and upfront. Buy feels affordable because the cost is distributed across time. The honest comparison requires looking at the full picture on both sides.

The cost of buying:

Subscription fees that scale with users, usage, or features — often significantly as the business grows. Implementation and configuration cost, which can be substantial for complex platforms. Customisation cost for anything outside the standard configuration, which often requires specialist consultants. Workaround cost — the staff time spent managing the processes the software doesn't quite handle. Integration cost when the platform doesn't connect natively to other systems you use. And the switching cost when you eventually outgrow the platform or it stops meeting your needs.

The cost of building:

The initial development cost — design, development, QA, deployment. Ongoing maintenance — updating dependencies, addressing security issues, extending the product as requirements evolve. Hosting and infrastructure costs. Internal management cost — someone has to own the product and make decisions about its development.

For many businesses, these come closer together than the upfront comparison suggests. A SaaS platform at £500/month sounds affordable against a £40,000 custom build — until you factor in five years of subscriptions, implementation cost, consultant fees for customisation, and the productivity cost of working around its limitations. The total cost of ownership calculation frequently surprises people who do it honestly.

4. How specific and how stable are your requirements?

This question is about risk.

Custom software built to specific requirements only stays relevant if those requirements remain reasonably stable. A business whose processes are evolving rapidly, whose market is shifting, and whose operational model is changing significantly is taking on risk by locking requirements into a custom build — because every significant change requires development investment.

Off-the-shelf software, by contrast, evolves with its vendor's product roadmap. New features arrive with the subscription. If your requirements are moving in the same direction as the product's development, the fit actually improves over time without additional cost.

If your requirements are well-defined and relatively stable: build risk is manageable and the case for custom is stronger. If your requirements are rapidly evolving: buy and iterate, then evaluate whether custom makes sense once the operation has stabilised.

You need something operational quickly. A SaaS product can be live in days. A custom build takes months. If the operational need is urgent and the software category has mature products, buy.

Your process is genuinely standard. Accounting, email marketing, basic CRM, HR management — the companies that have built software for these processes have done it well, and there's no competitive advantage in rebuilding it. Buy a mature product in the category.

Your business is early-stage and still figuring out its processes. Custom software built before your operational model is settled is expensive to change. Off-the-shelf software is expensive to replace, but cheap to abandon at early scale. Validate your processes before encoding them in custom software.

The category has a dominant, deeply capable solution. Shopify for e-commerce, Xero for accounting, HubSpot for marketing automation — these products have been built over years with enormous investment. The chance that a custom build will materially outperform them on their core use case is low. The chance that the cost of building approaches the cost of using them is also low.

Your process is genuinely unique. If no off-the-shelf product exists that handles your specific workflow — or if the closest options require such significant adaptation that you spend more on workarounds than you would on a build — custom is the right answer.

The software would be the product. For businesses where the software is what customers pay for — a SaaS platform, a marketplace, a consumer app — buying off-the-shelf software is not an option. Nobody is selling your specific product. It has to be built.

You've outgrown the platform you're on. Scaling businesses frequently find that the software that served them well at 50 customers creates operational problems at 500. Data doesn't structure itself the way you need. Workflows that were manageable manually don't automate in the way the platform supports. This is the most common moment where the build decision becomes obvious: when the cost of continuing to work around the platform's limitations exceeds the cost of building something that actually fits.

The platform dependency is becoming a business risk. Vendor pricing changes, acquisition, feature deprecation, new terms of service — all of these have affected businesses that built significant operational dependency on third-party platforms. For processes central to your business, owning the software that runs them is a strategic consideration, not just an operational one.

The build vs buy decision isn't always binary. Many businesses find a middle ground that uses off-the-shelf software for what it does well and custom development to fill the gaps.

A business might use Salesforce for CRM, Xero for accounting, and a custom-built operations portal that connects the two in the specific way their workflow requires, handles the data transformations neither platform does natively, and gives their operations team the specific views and actions they actually need.

This approach — buy for generic functions, build for specific competitive requirements — is often the most commercially sensible answer. It avoids the cost of rebuilding things that existing software does well, while addressing the gaps that no existing software fills.

The integration cost of this approach is real and worth accounting for. Custom software that connects multiple platforms has additional complexity and maintenance requirements. But for many businesses, the alternative — either working around the gaps in off-the-shelf software or rebuilding everything from scratch — is more expensive.

Most build vs buy decisions look like one of three patterns:

Clear buy: Standard process, mature software category, good product fit, no competitive differentiation at stake. Use what exists. Configure it well. Get on with running the business.

Clear build: The software would be the product, or the process is genuinely differentiating, or the gap between available software and actual requirements is too large to bridge with workarounds. Build it properly, own it completely.

Buy then build: Start with off-the-shelf software while the business is early and requirements are evolving. Validate the operational model. When the platform limits become clear — and they usually do — build the custom solution on the foundation of everything you've learned.

That third pattern is, in our experience, where most growing businesses end up. The software that was right at twenty customers isn't right at two hundred. The processes that needed flexibility at the start need reliability at scale. Custom software built on the back of operational experience is almost always better than custom software built on the back of assumptions.

We build custom software for businesses that have reached the "build" side of this decision — either because the software would be the product, because the available options genuinely don't fit, or because they've outgrown the platform that got them here.

We also help businesses figure out which side they're actually on. If you're not sure whether your situation calls for a custom build or a better implementation of something that already exists, that's a useful conversation — and one we'll have honestly, because recommending a build when a SaaS product would serve you better doesn't help either of us.

For the businesses that do need to build: discovery first, always. Design before development. Fixed price. Eight to twelve weeks for a well-scoped product. A codebase you own, on infrastructure you control, built to your requirements rather than the median customer's.

Tell us what you're trying to solve. We'll tell you honestly whether building is the right answer — and what it looks like if it is.