Bespoke or off the shelf?

Build or buy is one of the more consequential technology decisions a business makes. Get it right and you have a system that fits how you work and grows with you. Get it wrong and you’ve either spent a lot of money building something you could have subscribed to, or you’re locked into a product that doesn’t fit and gets more painful every year.

It’s also a decision that’s usually made by people with a stake in the answer. Developers earn money building things, so developers recommend building. Software vendors earn money from subscriptions, so vendors are relaxed about the limitations of their products. Genuinely independent advice on this question is rare.

A note on bias. I build bespoke software. I have an obvious interest in recommending it. What follows includes the cases where it’s the wrong answer, and I’d rather you factored in the context than took my word for anything.

The honest answer to “bespoke or off the shelf?” is “it depends” - but it depends on specific things you can actually check, and working through them gets you to a defensible decision rather than a feeling.

What we’re comparing

Off-the-shelf software is built for a market rather than for you. It runs from completely generic (a word processor) to tightly specialised (practice management software for vets). Most business software sits in between: built for a sector, designed to flex around the different ways firms in that sector work. You buy access to it as it is, with whatever settings the vendor provides. You don’t own it and you can’t change what it fundamentally does.

Bespoke software is built for one organisation. It’s designed around your workflows, your data and your users, and you own it - the source code, the database and the intellectual property.

The middle ground gets forgotten. Plenty of established platforms allow serious configuration and custom development on top of them. If a well-supported product covers seventy or eighty per cent of what you need and lets you build the rest, that can be cheaper than building from scratch and more flexible than taking the product as it comes. It’s a good deal of what I end up doing on bespoke projects, and it’s worth pricing before you commit either way.

The case for off the shelf

This part matters. If you only read the case for building, you’ll build.

It’s cheaper, because you’re splitting the bill. A product sold to thousands of businesses spreads its development cost across all of them. For common functions - accounting, email, payroll, project management - building your own is almost never justified. Matching an established accounting package would cost a fortune. Subscribing to one costs very little.

It’s available now. Sign up, configure, move your data across, start working. Days or weeks, against months for a build. For a young business that needs something working rather than something perfect, that’s usually the deciding factor.

It keeps improving without you paying for it. There’s a team whose whole job is making the product better, and the features, fixes and security patches arrive in the subscription. That advantage compounds. In five years a well-funded product will be noticeably more capable; your bespoke system will be exactly as capable as the last time you invested in it.

It’s more reliable than anything used by one company. Thousands of organisations using the same software find bugs and security holes that a system used by one business never would. That matters most for the sensitive parts - logins, payments, anything handling money or personal data.

It’s lower risk. You can try it, read reviews, and speak to people already using it before you spend anything. Software projects have a long and well-documented history of running over on time and budget. Buying something that already exists removes most of that risk.

The case for bespoke

Your workflows are genuinely different. Off-the-shelf software is built for the typical business in your sector. If you aren’t typical, you’ll spend your days working around it. The test is whether the workarounds are occasional and minor, or systematic and daily. Everyone has the first kind. The second kind is a bad fit.

You need to own it. With a product you’re a tenant. The vendor sets the roadmap, the price, the data format and the terms. If they put prices up, drop a feature you depend on, get acquired or close, your options are limited. Owning the code removes that dependency entirely.

The software is the product. If you’re selling the software itself, building on someone else’s product puts a ceiling on how far you can differentiate. Low-code platforms can carry a simple product a surprisingly long way, but anything that has to be meaningfully better than a competitor needs its own foundations.

Your data has particular requirements. Products store your data their way, under their privacy policy, in their region. If you have data sovereignty obligations, unusual data relationships, or a real need to get your data out and analyse it on your terms, that’s a constraint worth costing.

Your integrations are complicated. Most businesses run several systems that need to share information. Products integrate with each other as far as their vendors have chosen to support, and no further. Older systems that predate modern integration standards usually need custom work regardless of what else you choose.

The long-term arithmetic favours it. Subscriptions are lower upfront and continue forever. Bespoke is higher upfront and cheaper to keep. At some point the cumulative subscription passes the build cost. For a cheap tool that crossover may be a decade away and irrelevant. For enterprise software with high per-user pricing, it can be inside a normal planning horizon - but only if you’re comparing genuinely equivalent functionality, which is where this argument is usually abused.

Six questions that settle it

Work through these honestly - ideally with someone who has no stake in the answer - and the decision usually makes itself.

The mistakes I see most

Choosing bespoke to avoid evaluating products. Comparing off-the-shelf options is tedious: you have to make judgements, accept nothing is perfect, and commit to a vendor. Building promises a perfect fit and defers all of that. It’s an expensive way to avoid an afternoon’s work, and it doesn’t deliver a perfect fit either - that depends entirely on how well the requirements are defined.

Choosing a product to avoid the upfront cost, when the fit is genuinely poor. Three years of workarounds, manual processes and frustrated staff, followed by building it anyway, costs more than building it at the start.

Underestimating integration. Off-the-shelf rarely sits on its own. It has to exchange data with everything else you run, and that cost is routinely left out of the vendor’s pricing. Occasionally it approaches the cost of building the thing outright.

Ignoring what the workarounds cost. They never arrive as an invoice. They’re spread across your team’s time, which is exactly why they get left out of the comparison.

Deciding without the people who’ll use it. The people doing the work every day are the best judges of whether a product fits. Decisions made above them produce software that demos well and frustrates everyone by the second week.

It varies by sector

Financial services often has regulatory, reporting and data residency requirements that rule out most products for the core functions, while the administrative side is well served by established ones. The decision tends to be function by function rather than one organisation-wide answer.

E-gaming usually needs heavily customised back-office systems, because the regulatory requirements, payment flows and player management vary by jurisdiction and get complicated quickly. Player-facing content is typically a mix of licensed games and bespoke platform work.

Professional services - law, accountancy, consultancy - are generally well served by established practice and document management software. The case for building is strongest where the firm has a proprietary method that could be turned into software.

Manufacturing has complex scheduling, inventory and quality requirements that established systems handle reasonably well, with substantial implementation effort. Building is most justified where operations are genuinely unusual or tied to specific machinery.

Early-stage businesses should nearly always buy. The priority is moving quickly with limited money, and products let you do that. The exception is when the software is the thing you’re selling. Building bespoke before you’ve validated the business model is almost always premature.

Starting with one and moving to the other

Plenty of businesses start on off-the-shelf software and move to bespoke later. That’s a sensible path, not a failure of planning - use the product while it fits, build when it doesn’t.

The signals that the moment has arrived are usually some of these: the workarounds are eating real time and causing errors; the vendor’s roadmap doesn’t address the limitations that matter to you; the subscription has grown until building looks competitive; your requirements have moved past what any product covers; or something strategic needs capability no product offers.

One practical note, worth checking early rather than late: make sure whatever you’re using now will let you export your data in a format you can actually use. That’s the part of the transition that catches people out.

So, which one?

Define your requirements clearly enough to judge anything against them. Evaluate the two or three strongest products properly - trials and reference calls, not vendor demos. Assess the fit honestly and price the workarounds. Get a real estimate for building, from a proper scoping conversation rather than a guess. Compare the whole cost over three to five years. Then weigh the things that don’t go in a spreadsheet: vendor risk, competitive advantage, ownership.

Is bespoke always better? No - and anyone who tells you otherwise is selling it. Off-the-shelf is usually right for common business functions, for tight budgets, where speed matters, and wherever building would cost far more than the problem is worth. Bespoke is right when the fit is genuinely poor, when the software is central to what makes you competitive, or when the long-term numbers favour it.

If you’ve worked through all that and you’re still not sure, that’s usually a sign the honest answer is “buy something and revisit in two years”. I’ll tell you if that’s what I think.