Build vs buy software comes down to one distinction: build the part that makes you different, and buy the part that does not. If the capability is a solved commodity that thousands of businesses run the same way, a mature product will almost always be cheaper, faster, and more reliable than anything you build. If the software is the thing your business actually competes on, or no product fits the way you work without forcing you to change how you operate, that is when building earns its cost. Most companies get this wrong in the same direction: they build what they should have bought, and they squeeze their one genuine advantage into a one-size tool that was never meant to hold it.
So the useful question is not "build or buy" in the abstract. It is which parts of what you need are commodity and which part is your edge, and then matching each to the right answer. Once that split is clear, most of the decision makes itself.
What does build vs buy actually mean?
Buying means licensing software someone else made and maintains: a subscription, an account, and a product that improves without you paying for the engineering. Building means commissioning software made for you, which you then own and are responsible for keeping alive. The two are often framed as opposites, and for most businesses the real answer is a mix of both, which is the part the framing hides.
The instinct to treat it as a single yes-or-no decision is where the money gets wasted. A company rarely needs to build everything or buy everything. It needs to buy the parts that are the same for everyone and build the part that is not, and the skill is telling those two apart honestly, before a vendor or a builder tells you for you.
When should you buy?
Buy when the capability is a solved problem. Email, accounting, payroll, calendars, a standard customer record: thousands of companies need exactly these, run them in much the same way, and a mature product has already absorbed years of edge cases you would otherwise discover one painful bug at a time. Building your own version of a commodity tool is paying a premium to end up behind where the market already is.
Buy, too, when speed matters more than fit. A bought tool is live this week; a build is live in months. If the need is urgent and the product is good enough, the right move is usually to buy now, get running, and revisit later if the fit becomes a real constraint. The honest test for buying is simple: is this something every business in your position needs, done roughly the same way? If yes, someone has already built it better than you will, and renting it is the cheaper path.
When should you build?
Build when the software is your edge. If the way you do a particular thing is the reason customers choose you, handing that process to an off-the-shelf product flattens the exact thing that makes you different, because the product was designed for the average of everyone, not for you. The capability you compete on is worth owning outright.
Build, too, when no product actually fits and the cost of bending the business to the tool is higher than the cost of the tool fitting the business. Every off-the-shelf product asks you to work its way. For commodity work that is a fair trade. For the work that is core to how you operate, the accumulated cost of those compromises, the workarounds, the manual steps the tool cannot do, the reports it will not produce, can quietly exceed what a fitted build would have cost. When the question stops being "who should build the software" and becomes "should we build it at all," an independent read from someone with no stake in the answer is the cleanest first move, which is what an advisory engagement is for.
Build vs buy, side by side
The two paths line up cleanly once you separate what you are paying for from what you end up owning.
| Consideration | Build | Buy |
|---|---|---|
| Best when | The capability is your edge, the thing you compete on | The capability is a solved commodity everyone runs the same way |
| Upfront cost | Higher: the engineering to make it | Lower: a subscription you start paying now |
| The hidden cost | Maintenance, hosting, and patching, every month after launch | Per-seat fees that climb, renewal increases, and integration work |
| Speed to live | Months | This week |
| Fit | Shaped to how you actually work | You adapt your process to the tool |
| You end up owning | The system, and the advantage built into it | An account and a license, improved without you paying for it |
| Main risk | An unmaintained build becomes the legacy system you replace | The vendor raises prices, is acquired, or shuts the product down |
The costs each side hides
Both options cost more than the number on the proposal, and the hidden costs sit on opposite sides. Buying hides its cost in the future: per-seat fees that climb as you grow, the price increase at renewal, the integration work to make the tool talk to everything else, and the standing risk that the vendor is acquired, pivots, or shuts the product down and takes your workflow with it. The subscription is the visible part of a cost that keeps arriving.
Building hides its cost after launch. The quote covers the build; it rarely makes the running cost as loud. A system has to be maintained, patched, hosted, and understood by someone, every month, for as long as it runs, and a build that nobody budgets to keep alive is exactly how a company ends up with a platform that quietly costs it money. The build is the down payment. The operating cost is the mortgage.
Buying hides its cost in the future. Building hides its cost after launch. Neither price is the number on the proposal.
How do you make the call?
Three questions settle most of it. First, is this capability a commodity that most businesses run the same way, or is it the thing you actually compete on? Commodity points to buy; edge points to build. Second, if you bought the best product available, how much would the business have to change to fit it, and what would that compromise cost you over a few years? A small cost favours buying; a large one favours building. Third, can you carry the running cost of a build, not just the build itself, for as long as it has to run? If the honest answer is no, buy, because an unmaintained build is more expensive than the subscription you were avoiding.
The most expensive mistakes here come from deciding by instinct or by whoever is selling. A vendor will tell you to buy; a builder will tell you to build; both are answering the question in the shape of their own invoice. Asking a builder whether you should build is asking a barber whether you need a haircut. The decision is worth a year of budget, which is exactly why it is worth an independent read before committing to either path, from someone whose only stake is that you decide well. If you do decide to build, the next question is who should do it, which is its own choice between a freelancer, an agency, and a firm.
The honest version of build vs buy is not a doctrine. It is a split: buy the commodity, build the edge, and be ruthless about telling which is which. The engagement below is that decision made for real, where an owner facing two confident, contradictory proposals got a written, independent read instead, and could defend the choice to a board afterward.
