These days, with LLMs like Claude and Codex and tools like Lovable, Bolt, and n8n, it is tempting to build software to handle your day to day work or to run part of your business. The barrier that used to stop you, needing months of a developer's time and tens of thousands of dollars, has mostly fallen away. You can describe an app in plain English and watch a working version appear in an afternoon.
That is genuinely new, and it is genuinely useful. It also makes the build-versus-buy decision more important, not less, because the cost of starting a build has dropped while the cost of finishing and maintaining one has not. A lot of people are now building things they should have bought, and half-building things they cannot keep running. Here is how I think through the decision when a client asks, and how you can think through it before you spin something up yourself.
Is this core to how you compete, or does everyone do it the same way
The first question is whether the software runs a process specific to your business or a process that every business in your category runs identically.
Commodity functions are the ones thousands of companies do the same way: accounting, payroll, email, scheduling, file storage, general CRM, payment processing. Mature products have absorbed years of refinement into these, handle the edge cases you have not thought of yet, and carry the ongoing cost of keeping them working. Buying these is almost always right. Building your own version means rebuilding something that already exists, then maintaining it forever, in exchange for very little.
Bespoke software earns its cost when the process is specific enough that off-the-shelf products force you to work the way the product wants instead of the way you actually work. If a workflow is part of how you win, or it is unusual enough that every product you try fights you, that friction is where custom software pays for itself. The test is not whether a product can technically do the job. Almost any flexible platform can be configured to do almost anything. The test is whether bending your business to fit the product costs you more, day after day, than building something that fits your business.
The cost you can see and the cost you cannot
The price of buying is visible. It is the subscription on the pricing page. The price of building has a visible part and an invisible part, and the invisible part is where people get hurt.
The visible part is the initial build, whether that is a developer's invoice or the credits you burn in an AI builder. The invisible part is everything after. Software is not a thing you finish. It is a thing you maintain. Every dependency that updates, every integration that changes its API, every browser or operating system update, every security patch, and every "small change" six months from now is a cost that lands on whoever owns the software. When you buy, the vendor carries that. When you build, you carry it, or you pay someone to.
This is the specific trap the new AI tools set. They are very good at the first eighty percent, the part that produces the satisfying demo. The last twenty percent, the error handling, the edge cases, the security, and the long maintenance tail, is most of the actual work, and it is the part the demo hides. A weekend build can become a multi-year obligation, and you usually do not find out until you are already depending on it.
The three real options, not two
Build versus buy is usually framed as a binary. There is a third option that has become the most interesting one, especially with AI tooling.
You can buy a product and pay for its built-in AI features, which is the simplest path and the right one when the vendor's version is good enough. You can build something fully custom, which is the heaviest path and right only when nothing fits. Or, increasingly, you can have someone build a thin layer that connects tools you already pay for, rather than replacing them.
That middle path is where a lot of the value is right now. If a product you use has an API, a small custom integration, including an MCP wrapper that lets an AI assistant work directly with that tool, often gets you most of what a full custom build would, at a fraction of the cost and with none of the burden of replacing the underlying product. You keep the mature SaaS doing what it is good at, and you add only the specific connective piece that is missing. The decision there is not build-versus-buy at all. It is buy the product, then build the small bridge.
A quick way to decide
Before committing to a build, run through a short check.
Does a product already do this well enough? If it does, buy it, and resist the urge to build something marginally better, because marginally better is rarely worth owning the maintenance.
Look at whether the thing you need is actually missing or just configured awkwardly in a product you already have, since awkward configuration is usually cheaper to fix than to replace.
If something genuinely needs building, separate the whole thing from just a connector between tools you already use, and build the smallest piece that solves the problem.
And whatever you build, decide now who maintains it in a year. If you do not have an answer, you are not ready to build it yet.
How this shows up in the work
When someone asks me to build software, the first thing I try to do is make the build unnecessary or as small as possible. Sometimes the answer is a product they did not know existed. Sometimes it is open source they can stand up quickly. Sometimes it is a small wrapper around a tool they already pay for. And sometimes the thing they want is genuinely worth building from scratch, no good option exists, and then we build it properly, with the maintenance plan priced in from the start rather than discovered later.
The clients who get the most out of working with me are the ones who let me tell them when the smaller option is the better one.