Build, Don't Buy: When to Make It Yourself

A quick note since this is early, seed writing for the site: this is one of the ideas I come back to most, so it felt right to put it out first. The short version is that the old advice about building versus buying software is quietly out of date, and acting on the old advice now costs you money and leverage.

The old rule, and why it is breaking

For years the sensible default was: do not build it yourself. Building software was slow, expensive, and risky, so unless the thing was your actual competitive edge, you subscribed to a tool that already did it. That was good advice, because the cost of building was genuinely high.

AI-assisted building changed the math. I am not a traditional engineer, and I ship real, working software now, because tools like Cursor, Claude, Replit, and Lovable collapsed the time and skill it used to take. When the cost of building drops by an order of magnitude, the line between build and buy moves with it. A lot of things that were clearly "buy" five years ago are now genuinely "build."

"Build, don't buy" does not mean never pay for anything. I happily pay for infrastructure I would be foolish to run myself. It means: stop reaching for a subscription by reflex when the thing is now cheap to make and better when it fits you exactly.

The framework I actually use

When I hit the fork, I ask five questions.

1. Is this our edge, or plumbing? If the thing is close to what makes you different, building it is how you get a system a competitor cannot simply buy off a shelf. If it is pure plumbing, lean toward buying.
2. How well does the off-the-shelf option actually fit? Not the demo. The real fit. Most tools are built for the average of everyone, which means they fit almost nobody exactly. Count the workarounds you would live with forever.
3. What does building really cost now? With AI in the loop, be honest about how much smaller that number has gotten. It is usually far less than your instinct says.
4. What is the ongoing cost of the subscription, times years? Per-seat pricing compounds. A tool that is cheap for three people is a tax at thirty.
5. Who maintains it if we build? This is the honest catch. Building is cheaper than ever, but something you own is something you keep alive. If nobody can, that is a real point for buying.

If it is your edge, the fit is poor, building is now cheap, the subscription compounds, and you can maintain it, build. If it is plumbing, the fit is fine, and you would rather not own it, buy. Most real decisions are a clear lean once you answer honestly.

The trap on both sides

There is a failure mode at each extreme.

Buy everything and you end up renting your own operations. A dozen tools that each almost fit, none that talk to each other cleanly, and a stack you do not control. That is the state most teams are quietly in.

Build everything and you drown in maintenance. Every custom thing is a small ongoing promise, and promises add up. The goal is not to build the maximum. It is to build the few things that genuinely deserve it and buy the rest without guilt.

Where I land

The reason this matters more now is not ideology. It is that the cost of building fell far enough to change what the sensible default should be, and defaults are sticky. People keep reaching for the subscription because that used to be the smart move.

So the next time you are about to add a tool to the stack, run the five questions first. You will be surprised how often "build it" is now the boring, sensible answer instead of the reckless one.

If you want the hands-on version, the Build, Don't Buy course walks the framework with real cases, and Vibe Coding 101 is where you learn to actually make the thing.