Buy It Off the Shelf or Have It Built? A Straight Answer

There's a tool for it. Whatever the job is — answering calls, drafting quotes, chasing invoices, sorting your inbox — someone sells a subscription that does roughly that, starting at about £40 a month.

So the sensible instinct is: buy the tool, don't build anything. And most of the time that instinct is right. But "most of the time" hides a specific set of situations where buying is how businesses end up spending more, not less, and it's worth knowing which side of the line you're on before you commit.

Buy, when the job is a standard job

The economics of off-the-shelf software are unbeatable when your requirement genuinely matches what the product was built for. The vendor spreads the development cost across ten thousand customers; you get years of refinement for the price of a phone contract.

The job is the same in your business as in everyone else's. Transcribing a meeting, scheduling social posts, sorting expense receipts, providing a chatbot for FAQ-style questions. These don't vary by industry. Buy them, and don't think about it again.

You can live with the tool's opinion of how the work is done. Every product has a workflow baked in. If yours is close enough that you can adapt, brilliant. If adopting the tool means changing your process, ask whether the change is an improvement — quite often it is, and the tool is doing you a favour.

The data stays inside the tool. If the thing produces its result and you're done — a transcript, a draft, a scheduled post — you're in easy territory. No integration, no plumbing, no ongoing maintenance.

If all three are true, buy. Genuinely. Nobody needs a custom build to summarise meetings.

Build, when the job is your job

The case for building isn't sophistication. It's that some jobs are specific to how your business runs, and a generic tool can only ever get partway.

Your process is the differentiator. If the way you quote, schedule or handle customers is a reason people choose you, a tool that forces you into its standard flow is eroding the thing you're paid for. This is common in trades, specialist manufacturing and professional services.

The job spans three systems that have never spoken. Most real operational wins live in the gaps between tools — the enquiry that has to become a job, which has to become a quote, which has to become an invoice. Off-the-shelf products own one box each. The value is in the joins, and nobody sells the joins.

Your data can't leave, or can't be split. Regulatory constraints, client confidentiality agreements, or simply the fact that the useful context lives across four places at once. Products that require you to upload everything into their world don't fit.

You'd need four subscriptions and a person to glue them. This is the tipping point most businesses miss. Four tools at £80 a month each is £3,840 a year, plus the half-day a week someone spends moving data between them. That half-day is around £6,000 a year of salary. Suddenly a build isn't the expensive option.

The failure mode nobody warns you about

Here's the pattern we're called in to fix most often, and it isn't a bad tool — it's a good tool used for the wrong shape of problem.

A business buys a well-reviewed product. It handles 70% of the cases. The remaining 30% get handled manually, as an exception. Over a year, the exception process becomes a real job that a real person does, with its own spreadsheet. The tool is still being paid for. The manual work never went away; it just stopped being visible, because it's now "how we do the odd ones."

Then someone buys a second tool for a different job, and the two don't talk, so a person copies between them.

None of this shows up in a budget line. It shows up as a business that has six subscriptions, feels busier than it did, and can't work out where the time went. The honest test: if you've bought a tool and you still employ the workaround, you haven't bought a solution — you've bought a partial one and kept the cost.

How to decide, in about twenty minutes

Write down the whole job, end to end. Not the bit you want automated — the whole thing, from the trigger to the finished outcome. Most people write four steps and then realise there are eleven.

Mark which steps a product could do. Be honest. If a step needs context from your CRM plus a rule that only applies to two clients, mark it as a no.

Count the handovers. Every point where information moves between systems or people is a place a subscription can't reach. One or two handovers, buy. Five, and you're looking at a build or a long-term manual habit.

Price the leftovers. Take the steps a product can't do, estimate the hours, and multiply by a loaded hourly cost. This is the real number to compare against a build. It's usually much larger than people expect, because it's spread thinly across several people.

Ask what happens in year three. Subscriptions renew and rise. A build is a capital cost with a maintenance tail. Over three years the arithmetic often flips — and three years is a realistic horizon for anything operational.

The pragmatic middle

Most of our clients end up with a mix, and that's the right answer. Buy the commodity pieces — transcription, scheduling, generic assistants — and build the thin layer that connects them to how your business actually works. That layer is usually far smaller and cheaper than people fear, because it isn't rebuilding a product; it's the twenty percent that makes the eighty percent usable.

What you want to avoid is either extreme: building things that exist for £40 a month, or buying eight things and employing someone to be the glue between them.

If you want a straight answer for your own situation, our free AI-readiness audit will tell you which side of the line your job sits on, and our pricing page shows what a build actually costs so you can compare like for like.

At BuildPulse, we'll happily tell you to buy something instead. It's a shorter conversation, but it's the right one more often than you'd think.