Build vs Buy: When Custom Software Is Actually the Right Call

We’re an engineering studio. We make money when people build. Weigh what follows accordingly, and note that we turn down build work regularly, because taking on a project that a forty-dollar-a-month product would have solved better is a bad trade for everyone involved.

Buy, in these four situations

The problem is genuinely commodity. Payroll, accounting, email, video calls, payments. These are solved problems with mature vendors who’ve spent years on the edge cases you haven’t thought of yet. You won’t beat them, and the parts of them you find annoying are usually load-bearing compliance features you’d have to rebuild anyway.

You’re not sure what you actually need. Vague requirements produce expensive software that solves the wrong problem. A subscription is a cheap way to find out what you really require: use the product for six months, note precisely where it fails you, and only then decide, specifying from evidence instead of imagination.

Regulatory burden is the substance of the problem. If the hard part is staying compliant with something that changes every year, buying means someone else’s full-time job is tracking those changes. That’s worth a lot on its own.

You can’t maintain it. Software isn’t a purchase, it’s a commitment. If there’s no plan for who owns this in two years, no in-house engineer, no retained partner, no budget line, don’t build it. Unmaintained custom software turns into a liability faster than most people expect.

Build, in these four situations

The process is your advantage. If how you do the thing is why customers choose you, generic software makes you worse at your own differentiator. This is the strongest case for building, and the one most often missed, because the cost of the workaround gets treated as normal.

Nothing serves your niche. Some markets are too small or too specific for anyone to have built for them: federal contracting for veteran-owned small businesses, planning application monitoring for one particular jurisdiction. The market is real, the software doesn’t exist, and the workaround is a spreadsheet and a browser tab. That’s a build.

The workaround cost has quietly passed the build cost. Count it honestly: re-keying, reconciliation, exports and re-imports, the integration tool bridging two systems, the errors caught late, the person whose job is partly just to be the glue. Annualise it, and it’s frequently a large multiple of what people assumed going in.

You need to own the data model. If your data is your strategic asset and it currently lives inside a vendor’s schema, exportable only as a flattened CSV, that’s an argument for building, regardless of how good the vendor is today.

Run the honest arithmetic

Most build-vs-buy comparisons are dishonest in the same direction: they compare a subscription against a build estimate and stop there.

The real cost of buying includes the subscription, per-seat growth as you hire, the integration tooling needed to connect it to everything else, the manual work it never covers, the workarounds and their error rate, and the switching cost if you ever leave. The real cost of building includes the build itself, plus ongoing maintenance (realistically fifteen to twenty-five percent of the build cost every year), plus the internal time to specify and test it, plus the risk that version one is wrong.

Compare those two over three years, not one. Buying usually wins in year one. The crossover, when it happens, is typically somewhere in year two.

The third option people forget

Buy the commodity layer, build the differentiator on top of it.

Use a vendor for authentication, billing, email, storage, and analytics. Nobody is differentiated by their own auth system, and building one is a security liability, not an advantage. Build only the part that’s specific to how your business actually works.

Almost every good custom system we’ve shipped looks like this. The custom-written code is a fraction of what runs in production, and the rest is well-chosen infrastructure. It’s dramatically cheaper than building everything and dramatically better-fitting than buying a platform whole.

Internal search over your own documents is a good example of the split in practice: the vector database and the model are commodity, and the retrieval quality and citation trail are the part actually worth building. We go into that specific case in retrieval-augmented search for business.

Signals you are about to make a mistake

Building because the vendor annoys you is not a business case on its own. Write down the specific cost of the specific limitation before you commit to anything.

Buying because building feels risky ignores that buying carries its own risks: pricing changes, deprecations, acquisitions, roadmaps that diverge from yours. They’re just less visible, because they’re someone else’s decisions to make.

Building a platform when you needed a tool is how scope inflation kills more internal projects than technical difficulty ever does. The version that solves one problem well ships. The version that anticipates every future need doesn’t.

And buying, then building scripts around it to bridge the gaps, gets you the worst of both: you’re paying for the subscription and absorbing the maintenance of a custom layer on top of it.

How to decide in a week

Write down the process as it actually runs today, including the workarounds people have quietly built into it. Cost those workarounds properly: hours per week, error rate, any tools bought just to bridge a gap, then annualise the total. Trial two vendors for real, with real data, for two weeks, and note exactly where each one fails. Scope the minimum build that would solve those specific failures, not the ideal system, the minimum one. Then compare both paths over three years, maintenance included.

If it’s close, buy. Close means the build isn’t clearly worth it yet, and buying preserves the option to build later with better information in hand.

We do fixed-price discovery that ends in an architecture and a real number, so you can make this call on evidence. See how we build, or look at what we have shipped.