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

We are 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.

Buy, in these four situations

The problem is genuinely commodity. Payroll. Accounting. Email. Video calls. Payments. These are solved problems with mature vendors who have spent years on the edge cases you have not thought of yet. You will not beat them, and the parts of them you find annoying are usually load-bearing compliance features.

You are not sure what you need. Vague requirements produce expensive software that solves the wrong problem. A subscription is a cheap way to discover your actual requirements. Use the product for six months, note precisely where it fails you, and then decide — you will be specifying from evidence rather than imagination.

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

You cannot maintain it. Software is not a purchase, it is a commitment. If there is no plan for who owns this in two years — no in-house engineer, no retained partner, no budget line — do not build. Unmaintained custom software becomes 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 differentiator. This is the strongest case for building and it is the one most often missed, because the workaround cost gets treated as normal.

Nothing serves your niche. Some markets are too small or too specific for anyone to have built for. Federal contracting for veteran-owned small businesses. Planning application monitoring for a specific jurisdiction. The market is real, the software does not exist, and the workaround is a spreadsheet and a browser tab. That is a build.

The workaround cost has quietly exceeded 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 to be the glue. Annualise it. It is frequently a large multiple of what people assume.

You need to own the data model. If your data is your strategic asset and it currently lives in a vendor’s schema, exportable only as a flattened CSV, that is 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 to connect it to everything else, the manual work it does not cover, the workarounds and their error rate, and the switching cost if you ever leave.

The real cost of building includes the build, plus ongoing maintenance — realistically fifteen to twenty-five percent of the build cost annually — 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 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.

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 is specific to how your business works.

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

Signals you are about to make a mistake

Building because the vendor annoys you. Frustration is not a business case. Write down the specific cost of the specific limitation before committing.

Buying because building feels risky. Buying has risks too — vendor pricing changes, deprecations, acquisitions, roadmaps that diverge from yours. They are just less visible because they are someone else’s decisions.

Building a platform when you needed a tool. Scope inflation kills more internal projects than technical difficulty. The version that solves one problem well ships. The version that anticipates every future need does not.

Buying and then building around it. If you are already writing scripts to bridge the gaps, you are paying for both and getting the disadvantages of each.

How to decide in a week

1. Write down the process as it actually runs today, including the workarounds.
2. Cost the workarounds. Hours per week, error rate, tools bought to bridge gaps. Annualise it.
3. Trial two vendors properly — genuinely, with real data, for two weeks. Note exactly where each fails.
4. Scope the minimum build that solves the failures. Not the ideal system; the minimum.
5. Compare over three years, including maintenance.

If it is close, buy. Close means the build is not clearly worth it, and buying preserves the option to build later with better information.

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.