Build vs Buy: The Question That Costs Businesses the Most
There’s a moment in the life of most growing businesses when someone has to answer a deceptively simple question: do we buy this, or do we build it?
The question comes up about a tool, or a platform, or an integration. It looks like a comparison between options. It isn’t. It’s a decision about what kind of business you’re going to be, and most of the cost of getting it wrong doesn’t show up for eighteen months.
I’ve watched businesses spend more on buying wrong than building would have cost. I’ve also watched businesses burn budgets building things that should have been bought in an afternoon. The two failures look nothing alike, but they come from the same mistake: treating build vs buy as a pricing question instead of a fit question.
What the decision actually is
Buying means taking something someone else has already made. A plugin, a SaaS subscription, an off-the-shelf platform. You pay money, you configure it, you live inside the shape of what it allows. The upside is speed and predictability. The downside is that it was designed for a general problem, and yours is specific.
Building means creating something shaped around how your business actually works. The upside is fit. The downside is time and responsibility. You own it, which means you also maintain it.
Most comparisons between the two stop there, usually at a spreadsheet. Cost of subscription versus cost of development. Years to payback. Expected monthly savings. The spreadsheet tells you one thing and the business eventually tells you another.
The reason is that the spreadsheet is comparing the wrong quantities. It’s comparing what both options cost. It should be comparing what happens when each option stops fitting.
When buying is right
Buying is the correct answer more often than developers like to admit. If your need is genuinely common — accepting online payments, sending transactional emails, managing a mailing list, hosting a standard ecommerce catalogue — the tools that exist are extraordinary. Stripe, Mailchimp, Shopify, WordPress, Zapier. These products have had hundreds of millions of dollars and thousands of engineering years poured into them. You are not going to outbuild them in a quarter. You shouldn’t try.
The test for “buying is right” is whether your requirement is genuinely close to the centre of what the product was designed for. Not adjacent to it. Not mostly like it. Actually it. If you sell physical products, take card payments, and ship them domestically — Shopify is built for you. Use it. If your business is a standard membership site with monthly renewals — Paid Memberships Pro or MemberPress exist, and they’re excellent.
Buying is also right when the need is temporary, or when you genuinely don’t know yet what you need. Off-the-shelf tools let you discover your actual requirements by bumping into their limits. That’s valuable. Building too early locks you into assumptions you haven’t tested.
The honest rule is: if an existing product fits your needs well, buy it and stop thinking about it. The money and attention you save are better spent on the parts of your business that aren’t commodity.
When building is right
Building becomes the correct answer when your operation has specificity that no off-the-shelf product can match, and when the cost of working around that mismatch is higher than the cost of building the thing properly.
“Specificity” is the key word. Every business thinks it’s special. Most of them aren’t, in the ways that matter for software. A clothing retailer thinks their inventory management is unique because their products are unique. It isn’t. It’s ordinary retail inventory, and a hundred products handle it well. But a clothing retailer who sells bulk packs that get broken down into sellable units across multiple physical locations, with inter-location transfers and partner store syncing — that’s specific. No plugin handles it. Trying to make one handle it is where businesses lose years and six-figure sums in plugin licences and patching.
The signal that you should be building isn’t that you want something custom. It’s that you’ve tried to buy it and what exists keeps almost-fitting. You find yourself configuring around the product’s assumptions. You’re paying for features you don’t use to get access to one you need. You’re stacking plugins to simulate a workflow that should be native. The duct tape is becoming load-bearing.
That’s the moment. Not before.
The cost nobody calculates
Here’s what the spreadsheet misses.
When you buy the wrong tool, the cost isn’t the subscription. It’s the drag. It’s the extra step your team takes every day because the tool doesn’t handle the thing it almost handles. It’s the data you can’t get out because the tool wasn’t designed to surface it. It’s the integration you have to maintain because two products that don’t naturally talk to each other are now being duct-taped together by a third product. It’s the customer experience that’s two percent worse than it should be because you’re working within someone else’s UX decisions.
None of this shows up on an invoice. All of it compounds. And by the time the business is large enough that this compounding is expensive, unwinding it is a bigger project than building properly would have been in the first place.
The equivalent mistake in the other direction — building when you should have bought — has a different shape but the same root. A business decides to build its own payment processing, its own CRM, its own email platform. They do it because a developer said they could, or because the founder wanted something “just right,” or because a consultant priced the off-the-shelf option against a best-case custom build and the numbers looked close. Two years later, they’re maintaining a piece of software whose core function isn’t their business, using engineering time that should be going into the thing their business actually does. The off-the-shelf product they rejected has added half the features they built and maintains them for less than the cost of one developer.
Building where you should have bought is how businesses end up as software companies by accident. Usually, that wasn’t the plan.
The actual question
The useful version of build vs buy isn’t a cost comparison. It’s this:
What is this software supposed to do, and how close is it to the core of what my business actually is?
If the software is doing something your business must do but doesn’t differentiate on — accept payments, send emails, host a site, manage accounting — you should almost certainly buy. That work is commodity. The market has solved it. Use the solution.
If the software is doing something specific to how your business operates, something that if it changed would change how your business runs, something your competitors can’t easily replicate because it’s built around decisions only you could make — that’s where building earns its keep. Not because custom is better in principle, but because off-the-shelf can’t fit something that’s supposed to be specific to you.
Most businesses need a mix. They should buy the commodity layer — the payment processor, the mailing service, the hosting — and build the layer that reflects their actual operation. The mistake is treating the whole stack as one decision. It isn’t. It’s dozens of decisions, and the right answer to each one depends on where that particular tool sits in relation to the business.
How to tell which one you’re looking at
A few questions, when you’re trying to figure out which side a specific decision falls on:
If we replaced this tool with a competitor tomorrow, would customers notice? If no, it’s commodity. Buy it.
Could I explain what makes this tool’s job specific to my business in one sentence that wouldn’t apply to most businesses in my industry? If no, it’s commodity. Buy it.
Are we routinely paying for features we don’t use, or working around features we need but don’t have? If yes, you’ve outgrown off-the-shelf. Consider building.
Is the tool touching data, decisions, or workflows that are unique to how we operate? If yes, off-the-shelf will always fit imperfectly. Custom earns its keep here.
Is this something our competitors do identically to how we do it? If yes, there’s no advantage in building. Buy.
The decision that compounds
What makes build vs buy the most expensive question most businesses answer is that the answer doesn’t announce itself as wrong for a long time. You save money on day one by choosing the off-the-shelf tool that mostly fits. You save time on day one by choosing to build rather than configure. The savings feel real. The costs arrive later, quietly, as drag. By the time the drag is visible enough to name, you’ve been paying it for years.
Which is why the question is worth slowing down for, every time it comes up. Not because it’s hard — it usually isn’t, if you ask the right version of it. But because it’s the kind of decision where a slightly better answer on day one becomes a dramatically better answer over five years, and a slightly worse answer becomes an expensive one.
Buy the commodity. Build the specific. Know which is which.
That’s the whole game.