Build vs Buy, for Engineers Who Always Want to Build It

As an engineer, my default answer to almost any problem is "I'll just build it." Give me a weekend and a coffee and I will happily reimplement something that already exists on npm, because building it myself feels like control and buying it feels like admitting defeat.

That instinct has cost me real time. It has also, in a handful of cases, been exactly the right call. After shipping 40+ products with my studio, most of them for businesses deciding whether to buy an off-the-shelf tool or commission a custom build, I have a much more honest framework than "build is cool, buying is giving up." Here is how I actually think about it now, including the part where AI coding agents quietly moved the line.

Horizontal vs vertical, in plain terms

The build-vs-buy question usually shows up as horizontal SaaS versus vertical SaaS.

Horizontal SaaS solves one job for everyone: a CRM, a spreadsheet, a generic accounting package. Vertical SaaS solves the whole job for one kind of business, in that industry's own language, with its real objects and rules baked in.

The difference is not cosmetic. A generic accounting tool knows about invoices and ledgers. An accounting platform built for the fuel trade knows about tankers, suppliers, fuel loads and the specific way money moves in that business. We built one of those, Fyuel, because the people running a fuel business were otherwise stitching that picture together by hand across tools that were never designed for them. Customers, suppliers, tankers, ledgers, banks and reports finally live in one real-time system. Vertical software wins by removing the stitching.

The signals you have outgrown off-the-shelf

You rarely need a study to know you have hit this wall. As a developer working with a client, these are the symptoms I listen for:

• The team lives in exports. People pull data out of one tool, reshape it in a spreadsheet, and feed it into another. That spreadsheet is unowned, unmaintained software running the business.
• The workaround became the process. A manual step that started as a stopgap is now how the work gets done, and onboarding a new hire means teaching them the workaround, not the tool.
• The real process does not fit the software's model. They are paying for a product and then fighting it, forcing their workflow into fields and states that do not match how the job actually runs.
• The data is scattered and never current. The number that matters lives in three places, none of them agree, and by the time someone reconciles them it is stale.
• The thing they do best is the thing no tool supports. When the edge is a process competitors do not have, no off-the-shelf product will have it either, because it is built for the average of the whole industry.

One or two of these is a configuration problem. All of them together is a signal that the generic tool has become the ceiling on how well the business can operate.

The honest trade-off (buying wins more than engineers admit)

Here is the part my build-it instinct does not want to hear: buying wins more often than founders, and engineers, expect. If a mature product already fits the process closely, buy it. Someone else maintains it, fixes it and improves it, and you get value on day one instead of after a build. I talk clients out of custom work regularly, the same way I would tell you not to hand-roll auth when a battle-tested library exists.

Building earns its cost in a narrower but very real set of cases:

• The process is a competitive advantage. If how they operate is part of why they win, encoding it into software they own compounds that edge instead of flattening it to the industry average.
• The integrations are the point. When the value is in making systems that do not natively talk to each other work together in real time, that seam is exactly what off-the-shelf tools leave to you.
• They would be paying to fight the tool forever. If the workarounds are permanent and growing, the "cheap" subscription has a large hidden cost in wasted hours that a fitted system removes.
• They need to own the roadmap. Buying means waiting on someone else's priorities. Building means the next feature is the one their business needs next.

The mistake in both directions is the same: deciding on price tag alone. A subscription that forces ten hours of manual work a week is not cheap, and a custom build that reinvents a solved problem is not an investment. Weigh total cost, including the labor the tool creates or removes.

Custom does not always mean a full platform

This is the reframe that helped me most as an engineer. "Custom software" is not synonymous with "big SaaS system." Some of the most valuable vertical work is narrow and deep.

Raqts, the first racquet-sport wall experience we built, needed computer vision and IoT to let a physical wall respond to how you hit the ball, something no generic product could ever provide. Geonode's cross-platform SDKs let users earn through bandwidth sharing, a capability delivered as infrastructure rather than an app. Neither is a sprawling platform. Each is one specialized capability that no off-the-shelf tool owns.

So scope to the specific thing the business actually needs, not to a category. The right custom build is often a single sharp capability bolted onto tools you bought for everything else.

How AI moved the line

This is the genuinely new part, and it is why I am writing this for a dev audience rather than a buyer one.

For years, "just buy it" won by default because building was slow and expensive enough that only large companies could justify custom software. That gap has narrowed sharply. AI coding agents now handle the mechanical majority of a build: the scaffolding, the integration glue, the tests, the refactors, while I direct the architecture and review everything that ships. That is how we compress months of work into days without the code turning fragile.

The practical effect is that the threshold where building beats buying has dropped. Custom software that was only worth it for enterprises a few years ago can now make sense for a mid-sized business, because the cost of building fell faster than the cost of the problem it solves.

That does not mean build everything. It means the honest comparison is no longer "cheap subscription versus expensive custom project." It is "a tool you fight forever versus a fitted system that now costs far less to build than it used to." If you are the engineer in the room, that is the version of the trade-off to put in front of the decision maker.

How I decide now

Reverse the usual order. Do not start from a price tag; start from the fit.

• Count the workaround hours. Add up the real weekly labor the current tools create. That is the true cost of buying, and it is usually invisible on the invoice.
• Name the edge. If the competitive advantage is a process, lean toward owning it in software. If it is not, a bought tool is probably fine.
• Map the seams. If the pain is data scattered across systems that will not talk, that is a classic build-to-consolidate case.
• Match the reliability bar to the stakes. A system that runs money or operations needs real hardening; a low-stakes internal tool does not. Pay for the bar you actually need.
• Scope the smallest version first. Whether you build or buy, prove the core loop before committing to the whole platform.

My build-it instinct is still there. I have just learned to run it through those five questions before I open the editor. Most of the time it survives them. Sometimes it does not, and the most senior thing I can do is say "buy the tool" and move on to the problem that actually needs me.

If you want the fuller version with the client examples written up, I put it on my studio blog at nullstud.io.