Build vs Buy Software Decision: My One Rule

The advice everyone gives you is optimizing for the wrong thing

Every consultant who has ever weighed in on a build vs buy software decision gives you the same playbook. Calculate the three-year total cost of ownership. Factor in maintenance, engineering salaries, and the opportunity cost of your developers building something instead of shipping your actual product. Run the numbers, and roughly 90% of the time the spreadsheet tells you to buy.

For a long time, this was correct advice. I gave a version of it myself.

The problem is what the math optimizes for. It optimizes for short-term cost and developer scarcity. When engineers cost $180K a year and there are never enough of them, of course renting someone else's code wins. The spreadsheet was honest about the world it was built for.

But that's not the objective for an operator who actually wants to own and program their stack. My objective is ownership and programmability. Not the lowest three-year cost. Those are different goals, and they produce different answers.

Here is the doctrine I run now, across my DTC fashion brand and every client I build for. I pay gladly for primitives. I refuse third-party business-logic SaaS on principle. Not out of stubbornness, but because the part of the software that encodes how my business works is the part I should never rent.

The old math broke for one reason. AI changed the cost of building. The complexity that used to make buying the obvious choice did not disappear, but it became something one operator with the right tools could own. That single shift moves a lot of line items from the "buy" column to the "build" column, and most people haven't updated their spreadsheet yet.

The line I actually draw: primitives vs logic

The whole decision comes down to one cut. Is this thing a primitive, or is it your business logic?

Primitives vs Logic decision cut

What counts as a primitive worth renting

A primitive is commodity infrastructure. It is hard to build, standardized across the industry, and nobody differentiates by owning it. I pay for these gladly and without guilt.

The list is short and obvious once you see it:

• Database (Postgres, hosted)
• Compute (servers, containers, serverless)
• Managed browsers for automation
• The LLM API itself (Claude, Gemini, the models)
• Banking rails (ACH, card processing, the actual money movement)
• Email delivery infrastructure (the servers and reputation that get mail to the inbox)
• Object storage (S3 and equivalents)

Nobody wins by building their own Postgres. Nobody wins by trying to establish their own email-sending reputation from a cold IP. These are solved, commodity, and renting them is the right answer every time.

What counts as logic worth owning

Logic is anything that encodes how my business works. Tax rules applied to my catalog. My pricing tiers. My fulfillment workflow. My customer segmentation.

This is the part that makes my business mine and not my competitor's. When I rent it, I'm renting someone else's interpretation of my own operation, and paying per seat for the privilege.

Here is the test I use, and you can apply it to any line item in your stack. If the SaaS is mostly a thin layer of business rules wrapped around a primitive I could rent directly, then those business rules are the part I want to own. The vendor is charging me a markup to apply logic I understand better than they do, on top of infrastructure I could pay for at cost.

If you want the deeper version of this, I wrote out my full build vs buy framework for CEOs. The short version is this: rent the commodity, own the part that is actually you.

Why AI changed the math (and the old advice broke)

Let me be honest about why "buy" used to win, because the reason was legitimate.

AI flipped the build vs buy equation

Build complexity was brutal. Tax tables that change by jurisdiction. Labor law edge cases that vary by state and headcount. ACH file formats with their own arcane rules. Retry logic. Reconciliation. The thousand edge cases that only show up at 2am in production. That complexity is real, and it is genuinely hard. The SaaS vendor absorbed it, and you paid them to make it go away.

AI did not make that complexity disappear. The edge cases are still there. What AI changed is that owning the complexity became tractable for one person.

I have built a full double-entry ledger in a weekend. I have written a sales-tax application script in an afternoon. My AI toolkit is now 22,000+ lines of custom Python, and a large chunk of that is the exact kind of work that used to require a small engineering team and a six-month timeline.

That's the force multiplier. The build cost dropped by an order of magnitude. Meanwhile the ownership benefit stayed exactly the same. You still get to control the logic, change it instantly, and stop paying rent on rules you wrote.

When one side of an equation drops 10x and the other side holds, the answer flips. Things that were correctly "buy" three years ago are now correctly "build" for an operator with the right tooling.

But here is the part I won't sell past. AI does not make maintenance free. When you own the logic, you own the edge cases forever. The day a state changes its tax rule, that's your problem now, not a vendor's. That tradeoff doesn't go away. It just becomes a tradeoff you can actually afford to take.

The pattern across five replacements

This isn't theory. I replaced five SaaS subscriptions I deleted this year, and every one followed the same pattern. I kept paying for the primitive. I took back the logic.

Five SaaS replacements pattern

The bookkeeping app

I replaced the bookkeeping app with a Postgres ledger I own. The primitive I kept was the database itself, hosted Postgres, the most commodity infrastructure there is. The logic I took back was the chart of accounts and the reconciliation rules. That's the part that encodes how my business actually accounts for things, and it was never the vendor's to define. I was paying a monthly fee for a UI on top of a ledger I could model better myself.

The sales-tax service

I killed a sales-tax SaaS and replaced it with a script. I still pay for the rate data feed, because keeping current tax rates across thousands of jurisdictions is a genuine primitive and I'm not maintaining that. But the application of those rates to my specific catalog and the filing prep is owned code now. The vendor was charging me a per-transaction fee to apply numbers to my products. The numbers were the primitive. The application was mine.

The bank aggregator

I pay the bank, and I pay for raw API access to my accounts. That's the primitive, the actual connection to my money. What I stopped paying for was the aggregator's interpretation layer, a recurring monthly fee for transaction categorization and cash-flow logic. My categorization rules know my business. Theirs guessed. I took the logic, kept the rails.

The email-marketing platform

This one is the clearest illustration of the line. I pay for email delivery infrastructure, because deliverability is a real primitive. Sender reputation takes years to build and getting mail to the inbox is genuinely hard. I would never try to own that.

But campaign design, audience segmentation, and send scoring are pure business logic. Those decisions are about my customers, and I understand them better than any platform charging me per contact. The delivery is rented. The strategy is owned.

The 3PL workflow

The warehouse and the freight are the primitive I rent. I am not building warehouses. What I took back was the orchestration on top, the logic that decides how orders route, how exceptions get handled, when something gets flagged. That orchestration is where my fulfillment standards live, and it now runs as owned code that talks to the 3PL's API rather than living inside their workflow tool.

Five replacements, one pattern. Name the primitive, keep paying for it. Name the logic, take it back.

When you should still just buy it

The doctrine is not "build everything." That would be just as dumb as "buy everything." So let me draw the limits honestly, because knowing when not to build is what makes the framework trustworthy.

Decision tree for build vs buy

Buy when the thing is genuinely a primitive. Do not build your own Postgres. Do not try to establish your own email-sending reputation. Do not write your own card-processing rails. These are commodity, they're hard, and there is zero upside in owning them. Pay for infrastructure, not for logic you could write.

Buy when the logic isn't yours to differentiate on and the regulatory liability is high and changing fast. Some compliance tooling falls here. If a specialized vendor carries legal liability and updates their rules the day regulations change, that's a service worth renting. You're not buying software, you're buying someone else's responsibility for getting it wrong.

Buy when you don't have a force multiplier yet. This is the honest one. If you can't direct AI to build and maintain a thing, then the old TCO math still applies to you exactly as written. The whole argument for building rests on having the capability to own it cheaply. Without that, buying is still correct. Don't take the lesson and skip the prerequisite.

Buy when the SaaS genuinely is the product. Some tools aren't a thin wrapper around a primitive. They're deep, defensible products solving something hard end to end. Pay for those.

The doctrine isn't "build everything." It's "know which half is the commodity and which half is your business." That's the same skepticism any smart CEO should bring to a vendor pitch. When someone wants a recurring fee, ask what part is the primitive and what part is just your own rules with a markup.

How to apply this to your own stack this quarter

Here is the exercise. It takes an afternoon and it pays for itself.

List every SaaS subscription you have. All of them, with the monthly cost next to each. Then for each line item, ask one question: is this a primitive, or is this business logic wrapped around a primitive I could rent directly?

Most stacks have three to five line items where the answer is obvious the moment you ask. The vendor is charging you per seat for rules you understand better than they do, sitting on top of a database or an API you could rent at cost. Those are your candidates. Circle them.

Then run the honest gate, the same one I drew in the buy section. Do you have the capacity to own the maintenance? Because owning the logic means owning the edge cases forever. If you can direct AI to build and maintain the replacement, the math has flipped in your favor. If you can't, the old math still holds and you should leave the subscription alone for now.

That gate is exactly where a Chief AI Officer who actually builds matters, and not someone who hands you a slide deck and a roadmap. The decision is only as good as the capability behind it.

This is the precise work I run for clients. I draw the primitive/logic line across their entire stack, identify the wrappers worth replacing, and build the owned pieces myself. The result for my own brand was 3,000+ hours saved a year and 42% less manual operations time, mostly from refusing to rent logic I could own.

You can run the first pass yourself this quarter. The candidates will be obvious. The build is where it gets real.

Want to explore what AI could do for your business?

Book a free 30-minute strategy call. No pitch deck, no sales team, just a real conversation about your operations and where AI actually fits.

Book a Discovery Call