Build, Buy, or Rent: The Software Math Just Changed

Every growing business runs the same play. You need a tool, so you go shopping. You find a SaaS platform that does most of what you want, you pay per seat, and you fill the last twenty percent with spreadsheets. Building your own was never on the table, because building meant hiring engineers, and that math never worked.

That was the right call for a long time. It is not automatically the right call anymore.

AI coding changed the cost of building. The option that used to be reserved for companies big enough to staff an engineering team is now open to a small operator with an afternoon. So the old reflex, rent by default, deserves a fresh look. The question is no longer whether you can build. It is what you should build, what you should buy, and what you should rent.

Rent, buy, build

Three ways to get software, and they are not interchangeable.

Rent. A SaaS subscription. You pay monthly, usually per seat, and you never own it. Fast to start, nothing to maintain, someone else handles the updates. The catch: the price scales with your headcount forever, your data lives in their system, and it fits you about eighty percent. You bend your process to match the tool.

Buy. A tool you actually control. Self-hosted software, a platform instance that is yours, a template you own outright. More setup than renting, but the thing belongs to you and it stops charging you to grow.

Build. Custom, end to end, yours. It fits your operation exactly because you shaped it. This used to be the slow, expensive, risky option. AI coding is what moved it back onto the table.

Rent the commodity, build the core

Here is the rule the old math hid.

When building was out of reach, you rented everything, including the parts that are the actual core of your business. You rented your CRM, your operations tracker, your client workflow, even though those are the things that make you you. You did it because the alternative was hiring developers, and that was worse.

Now the alternative is cheap. So the decision splits cleanly.

Rent the commodity. Email, payments, accounting, calendars, video. Things that are hard, regulated, or already solved far better than you ever will. Nobody should build their own mail server or payment processor. Rent those and never think about them again.

Build the core. The workflow that is your business. The thing no SaaS quite fits, the process you keep patching with spreadsheets, the data you would rather not hand to a vendor. That is where building now wins, because it is finally affordable, and because a tool that fits exactly is worth more than one that fits eighty percent.

Buy the in-between. When you need control but not custom logic, a tool you own beats a subscription you rent.

The real cost is opportunity cost

It is tempting to make this a spreadsheet exercise. Total up the subscriptions, compare them to a month of hosting, declare a winner. The dollar math is real: a subscription recurs forever and grows every time you hire, while a tool you build is mostly an upfront cost and then a small hosting line. Over a few years the totals often cross. But the sticker price was never the expensive part.

The expensive part is opportunity cost, the value of what you gave up to make the choice. And in a small business the scarcest resource is not money. It is attention. Every hour your team spends on one thing is an hour it did not spend on another.

That is the real reason to rent a commodity. Not because renting is cheaper in dollars, but because building your own email or payment processing would cost you the one thing you cannot buy back: the attention of the people who understand your business. Renting the commodity buys that attention back and points it at the work only you can do.

It is also the real reason to build the core. When you rent the workflow that is your business, you are not just paying a subscription. You are giving up the compounding advantage of owning it, a tool that fits exactly, improves on your terms, and becomes something a competitor renting the same software cannot copy. That forgone advantage is the true cost of renting your core, and it never shows up on the invoice.

We made this call on our own business. ZLDA runs on tools we built rather than rented: the client pipeline, the content, the systems we operate on day to day. A stack of subscriptions would have been faster to switch on, and at two seats it would have looked cheap. Two things made building the right call anyway. First, our client pipeline is not a commodity, it is how we work, and a general-purpose tool would have made us bend our process to fit it. Second, per-seat pricing that looks cheap at two seats looks very different at twenty. The commodities around the core (email, payments, scheduling) we rent without a second thought. Building the core and renting the rest was not the cheaper option on day one. It was the option with the lower opportunity cost over the life of the business.

Can is not should

Everything so far comes with a caveat. The fact that you can build something useful does not mean you should. Building got cheap, not free, and whether to build any particular thing is an efficiency question, not a capability one. Run it through five honest checks first.

How big is the problem? Building carries fixed overhead: designing the data, testing it, maintaining it, living with it. A small annoyance never earns that back. The problem has to be big enough, and recurring enough, that a tool which fits pays off the overhead. Small problems get a spreadsheet or a cheap subscription. Big, central, everyday problems get a build.

How comfortable are you with the coding agent? The afternoon build is an afternoon for someone fluent at directing an agent. For someone who is not, it is a frustrating week. Efficiency is personal. The same tool is cheap for one operator to build and expensive for another, and being honest about which one you are is part of the math.

How comfortable are you with everything around the agent? The agent writes code. It does not define your data model, decide what done means, test the edge cases, or keep the thing running next quarter. That scaffolding is yours. If you are not willing to own it, the tool you build becomes a liability you cannot operate, and renting was the efficient answer all along.

What does the off-the-shelf option cost, and how well does it fit? The alternative sets the bar. If a cheap product fits your workflow well, building has to beat already works and already maintained, which is a high bar. If the off-the-shelf option is expensive, bloated, or a poor fit, the value of building climbs. Price what you would otherwise rent before you decide to build.

Custom efficiency versus prebuilt efficiency. A prebuilt product is efficient on day one: instant, maintained, proven. A custom tool is efficient over its life, but only if it fits better and you use it enough for that fit to matter. Judge total efficiency across the tool's life, not day-one speed. Sometimes prebuilt wins even when custom would fit better, because the attention a custom tool demands costs more than the better fit is worth.

Building is a tool, not a virtue. The efficient operator picks whatever clears the job with the least total drag, and often that is a subscription, even for something they could have built themselves.

The two mistakes

Both directions have a failure mode. Building what you should rent is the classic engineer's trap: rebuilding a commodity you will then maintain forever, and badly, instead of the company that does nothing else.

Renting what you should build is the quieter and more expensive mistake, and it is the one most operators make. You rent your core workflow because it is easy, then spend years paying per seat for a tool that never quite fits, molding your operation around someone else's assumptions. The spreadsheets filling the gaps are the tell. They are the shape of the software you should have built.

What we build, what we rent

The rule is easier to show than to argue, so here are our own choices.

We built our own CRM. We rent email from Microsoft. That is not a contradiction, it is the whole rule in one line. Email is a solved commodity: Microsoft runs it more reliably, more securely, and more cheaply than we ever could, and nothing about how we send mail makes us better at our work. Our client pipeline is the opposite. It is how we actually operate, so we built it to fit, and it gets sharper every time we learn something. Same decision, opposite answers, for the same reason.

The rest of the toolchain follows the same logic.

Building it. Most of our development runs through Claude Code, with Codex, VS Code, and GitHub around it. We rent the intelligence and the version control, then spend our time pointing them at the part that has to fit us: the front end, the back end, the logic that is ours.

Where the data lives. Neon and Supabase for most projects, because managed Postgres is cheap, fast, and not something we should be running ourselves. When a project carries HIPAA or FERPA data, it moves to Azure or AWS, where compliance is the whole point. We rent the database. We own the schema.

Hosting. Netlify for most work, Azure or AWS for enterprise and regulated builds. Nobody should run their own datacenter, and regulated records belong only with a provider that will sign a compliance agreement to stand behind them.

The AI layer. We default to Claude and OpenAI for most AI work, and reach for the same models through Azure or AWS when compliance requires it. Rent the model, build the application on top of it.

Every line is the same question answered twice: is this our core, or is it a commodity? We build the core: our pipeline, our product logic, the workflows that are the business. We rent whatever a specialist does better, from email to model weights to the servers under the database. And when the data is regulated, we rent from the providers built to carry it.

Own the first. Rent the second. Know which is which.

The question changed

Build versus buy used to be a question about budget and headcount. That is not the constraint anymore. The real question now is what is core and what is commodity. Rent the commodity so you never think about it. Build the core so it fits you exactly and stops charging you to grow. The businesses that get this right are not the ones that build the most or rent the least. They are the ones that know the difference.

Schedule a call when you want help drawing that line for your own operation.