Build or buy software: how to actually decide

Every few months you hit the same fork. There’s a job software could do, and you have to choose: buy something off the shelf, or build something custom. Most people decide it on price, and that’s exactly how they get it wrong in both directions. Buy everything and you end up with a drawer full of subscriptions nobody fully uses. Build everything and you sink half a year into something a thirty-dollar tool already did, better. The price was never the real question.

The real question is one most people never ask, and it settles the decision cleanly once you do. Get it wrong and it’s expensive either way: the average business now runs dozens of separate SaaS tools, and a quarter to a third of those licences sit unused, while on the other side fewer than a third of custom software projects land on time, on budget and doing what they were meant to. This is the decision drawn honestly, by people who build custom software for a living and will still tell you, most of the time, to buy.

The only question that matters: is it your edge?

Forget cost for a second and ask one thing: does this make you different, or is it just plumbing every business needs? That single distinction decides almost everything. The strategist Geoffrey Moore named it core versus context. Core is the work that actually wins you customers, the thing you do better than anyone. Context is everything else: necessary, but not special, and not why anyone chooses you. The rule that falls out of it is simple. Build for core. Buy for context.

The biggest companies live by this without saying it out loud. Netflix builds its own recommendation engine and Google builds its own search, because that is the business, the edge nothing off-the-shelf could match. But both buy their payroll, their email, their accounting like everyone else, because there’s no advantage in processing holiday requests in a special way. McKinsey’s way of putting it is that every company is now a software company, but the ones that win are deliberate about which software is theirs to own and which to rent.

Here’s the uncomfortable bit for a small business. Almost nothing you do is “core” in software terms. Your edge is your craft, your judgement, your relationships, the way you treat people, not the way you log an invoice. So the honest default is to buy nearly everything, and build, at most, the one thing that’s genuinely yours. That’s the whole framework on one grid.

A tool already fits Nothing off-the-shelf fits Your competitive edge Just plumbing

Buy for now Buy it, but keep watch A tool covers it today, yet it is core to you. Rent it to move fast, and revisit building once it clearly pays.

Build Build it, this is your edge Core to what makes you different, and nothing off-the-shelf fits. The one clear case for a custom build.

Buy Buy and move on A commodity a product already does well. Building it would be all cost and no advantage.

Hybrid Buy the closest, bolt on the gap No single tool fits, but it is not your edge. Buy the nearest and wire the missing bit.

Buy is the default, and that’s not settling

For the vast majority of what your business runs on, buying is the right call, not the cheap one. The reason is blunt: a company whose entire existence is one tool will always out-build you on that tool. They have a team on it, they’ve hit every edge case across thousands of customers, and they fix it while you sleep. Your accounting software, your CRM, your scheduler, your email, your invoicing, each one is somebody’s whole life’s work, sold to you for the price of a couple of coffees a month. You will not beat that by building, and you shouldn’t try.

What buying gets you is real: you’re live in days not months, someone else carries the security and the maintenance and the 2am outage, and you never think about the plumbing. For context work, that’s exactly the deal you want. The mistake isn’t buying. It’s buying badly, without counting the real cost, which is almost never the sticker. Per-seat pricing creeps every time you add a person, including the ones who log in twice a month. Subscriptions multiply until you’re paying for ten tools that do overlapping jobs. So buy freely, but buy with your eyes open, and audit what you’re actually using twice a year.

The trap. Phantom seats. You sign up at five users, then the bookkeeper, two managers and a director all need to approve the odd thing, and you’re quietly paying for ten seats to do the work of five. Per-seat pricing is fine until it isn’t, and the bill creeps up so slowly you never notice the day it stopped making sense. Count every login before you judge the price, and again every year after.

What “build” actually means now

Half the fear around building comes from a picture that’s out of date. Building used to mean hiring developers for months and praying. It doesn’t anymore, and that’s the single biggest shift in this whole decision. “Build” now runs across a spectrum, and most of it isn’t scary.

At the easy end, you wire tools you already pay for into each other with no-code platforms like Zapier or Make, or the more powerful n8n, no real code involved. A rung up, you describe what you want to an AI and it writes the thing, which is what people mean by “vibe coding”, and it’s genuinely viable for small internal tools if you know what to check before real people rely on it. The cheapest build of all isn’t a build at all: you connect Claude or ChatGPT straight to your data and just ask, which our guide to using AI in your business walks through. This is why the line moved. Gartner expects most new business apps to be built on low-code tools, mostly by people who aren’t developers. A lot that needed an agency last year is a Tuesday afternoon now.

But be honest about the other end of that spectrum. A real custom system that runs a chunk of your business is still a project, not a setup, and projects fail. Fewer than a third of software builds fully succeed, and about one in five collapse outright, usually because nobody scoped them properly. And whatever you build, you own forever: the rule of thumb is 15 to 25% of the build cost every year just to keep it patched and alive as the tools around it change.

The maturity call. Building is a commitment, not a purchase. The afternoon in Zapier is low-risk and reversible. A custom system is neither: it needs an owner, it breaks when a supplier changes a format or an API shifts, and the small-business version is barely documented because few people write theirs down. Start at the cheap, reversible end. Earn your way up to a real build only once you’ve proven the thing is worth owning.

The three things that flip it from buy to build

If buying is the default, you need to know exactly when to override it. There are three triggers, and if none of them is true for the job in front of you, stop reading and go buy something.

The first is the one from the top: it’s your edge. If a process is genuinely how you win, where off-the-shelf would make you the same as every competitor, that’s the thing to own. It’s rare for a small business, but when it’s real, it’s the clearest reason to build there is.

The second is fit. Every product models the world the way its designers imagined a business works. If yours matches, brilliant, buy it. If it genuinely doesn’t, because you run several entities, or your approval rules are unusual, or your workflow is its own animal, you get two bad options inside a bought tool: bend your business to suit the software, or pay up to an enterprise tier built to cope. When bending hurts more, and keeps hurting every week, building the thing that actually fits starts to win.

The third is per-seat pricing that punishes growth. Most tools charge per user per month, which is fine at three users and brutal at fifteen who each touch it occasionally. You end up paying full freight for people who barely log in. You’re not imagining it: ApprovalMax is moving its whole base off per-seat to usage-based pricing, admitting a customer processing 20 invoices a month was paying the same as one processing 2,000. When the vendors themselves call the pricing shape broken, do your own sum.

Run the actual numbers, not the sticker

Once a trigger fires, don’t argue it on vibes, argue it on a three-year total, because both sides hide half their cost. The sticker on the software and the quote on the build are each only the visible part.

For buying, the real figure is seats times the monthly fee times thirty-six months, and then the quiet bit: the workaround tax, the hours your team loses every week wrestling a tool that doesn’t quite fit. Five people on a $55-a-month-per-user tool like Bill is around $9,900 over three years before you add a sixth login, and that’s before the friction. For building, the real figure is the one-off cost plus that 15 to 25% a year of upkeep, plus the honest risk it ships late or not at all. A few thousand to commission a focused build, plus a few hundred a year to keep it running, can quietly undercut a per-seat subscription that climbs every time you hire. Run both totals properly and the answer usually stops being a debate.

The trap. Comparing the build’s quote to the software’s monthly fee and stopping there. Both have a hidden half. The build’s is upkeep, the cost everyone forgets until it breaks. The software’s is the workaround tax plus every seat you’ll add later. Price both sides in full or you’ll talk yourself into the wrong one with a straight face.

The answer is almost always both

For most businesses the real answer isn’t pure buy or pure build, it’s buy the boring 90% and build the one bit that’s yours. The jobs aren’t equally worth building. The commodities, accounting, payments, capture, scheduling, are cheap, proven and supported off the shelf, and rebuilding them is all cost and no edge. What pushes people toward building is usually a single step where their business genuinely doesn’t fit the mould.

So don’t throw out the whole bought stack to fix one misfit. Buy the infrastructure where it’s cheap and solid, then build only the step that doesn’t fit and bolt it on through the tool’s API. Accounts payable is the textbook case: buy the capture and the payment rails, and build only the odd approval logic that’s actually yours, which is exactly the line our accounts payable playbook draws. You keep the support, security and audit trail of bought tools for the easy nine-tenths, and you get the exact fit of a build for the tenth that was the problem. For how this plays out across the whole back office, the back-office automation map lays it out.

Do it yourself, buy, or get help

Do it yourself for the simple, reversible end. Wiring two or three tools together, or pointing an AI at your data to answer questions, is within reach of a non-technical operator for the price of a subscription, and you’ll understand your own business better for it. Our guide to using AI in your business and the explainer on AI agents are the place to start. Don’t hire out an afternoon’s work.

Buy off the shelf for everything that’s context, which is most things. If a finished product does the job, a custom build is a worse deal in every direction: more expensive, more to maintain, no advantage. Reach for a build only when one of the three triggers genuinely fires.

Get help when the build is real: your actual edge, several systems that have to stay in sync, something you can’t babysit. That’s worth paying for, and the one thing to insist on is ownership. Get it built on open tools and your own accounts, get it handed over, and own it, so you’re never renting back the very thing that makes you different. The questions to ask an automation agency will keep you from getting burned, because the whole point of building your edge is that it stays yours.