Build vs Buy Software in the AI Era

Chamath Palihapitiya spent 18 months building a company called 8090 with one goal: rewrite the legacy software of the world. In June 2026 he took the CEO seat, raised 135 million dollars led, of all people, by Salesforce Ventures, and put his “Software Factory” into the wild. One of his customers is using it to shut down a SaaS vendor that was charging them 15 million dollars a year and replace it with their own version at a fraction of the price. Around the same time, an internal Starbucks presentation leaked showing the coffee company, which spends roughly 400 million dollars a year on software, quietly building its own AI-assisted tools to replace systems it rents from Microsoft and IBM.

The takeaway everyone reached for was simple and loud: SaaS is dead, AI makes building cheap, rip out your subscriptions and build your own.

That take is half right, which is the most dangerous kind of right. AI really did collapse the cost of building software. But building was never the expensive part of owning software. I run two companies where AI now writes most of the first draft of everything we ship, and I have watched my own build costs fall off a cliff while my ownership costs sat there, unbothered, waiting to be paid. This is the durable version of the story, the one that will still be true when the Chamath tweet is buried: the build vs buy decision did not disappear, it moved. The number that changed is the small one. The number that matters barely moved at all.

This post gives you the framework I use to decide what to rebuild, what to keep renting, and the third option almost nobody names.

Table of contents

• The rebuild fever and what it gets wrong
• The framework: the Ownership Tail and the Rebuild Line
• What AI actually cut
• The five costs AI does not touch
• The Rebuild Line: a decision matrix
• Wrap, do not rebuild: the missing middle
• A worked example: scoring a real stack
• The one ratio that settles most of it
• The contrarian take: even Klarna blinked
• What to do Monday morning
• FAQ

The rebuild fever and what it gets wrong

The pressure is real, and the numbers are real. Retool’s 2026 Build vs Buy report, based on a survey of 817 builders, found that 35 percent of teams have already replaced the functionality of at least one SaaS tool with something they built, and 78 percent planned to build more custom tools in 2026. Development time and coding cost have dropped somewhere between 20 and 45 percent compared with the 2020 to 2023 baseline. What used to take a quarter now takes a few days. When the cost of the thing you were afraid to build drops by half, the fear drops with it.

There is a specific grievance underneath the fever, and it deserves a name. Call it the 20 percent problem. You buy a broad platform for one job. You bought the CRM to track deals. Over the next three years you adopt three more modules, tolerate a pricing tier you half use, and end up paying for a wide product while touching a narrow slice of it. Every renewal, the gap between what you pay for and what you use gets wider, and the invoice goes up anyway. Multiply that across a stack of 40 or 90 subscriptions and you can feel the money leaking. Of course you want to rebuild. Rebuilding feels like taking back control.

Here is the trap. The rebuild fever quietly assumes that the cost of software is the cost of building it. That assumption was always wrong, and it was wrong long before AI showed up. The reason so many teams rented instead of built was not only that building was expensive up front. It was that owning software is a tax you pay every year for as long as the software lives. AI cut the up-front bill. It did almost nothing to the annual tax. So a decision that was made on the up-front number is now being unmade on the same up-front number, and the annual tax is sitting in the corner of the room that nobody is looking at.

The founders who win the next few years will not be the ones who rebuild the most. They will be the ones who can tell, before they write a line, which subscriptions were expensive because of the build and which were expensive because of the ownership. Those are two completely different bets.

The framework: the Ownership Tail and the Rebuild Line

Start with the one fact that reframes the whole decision. Across four decades of software research, maintenance is not a footnote on the cost of software. It is the majority of it. O’Reilly’s old 60/60 rule put 60 percent of a product’s lifecycle cost into maintenance. The broader benchmarks land between 50 and 80 percent of total ownership cost over a system’s life. Gartner has said organizations spend 55 to 80 percent of their IT budgets just keeping existing systems running. The IEEE puts maintenance at 60 to 80 percent of total software lifecycle cost. Pick your source. They all say the same thing. The build is the small slice.

I call the rest the Ownership Tail: everything you pay for after the software works the first time, for as long as you keep it alive. Maintenance, security patches, the integration plumbing, the endless long tail of edge cases, and the quiet cost of becoming your own vendor with nobody to escalate to. The Tail is where 60 to 80 cents of every software dollar actually goes. And the Tail is the part AI barely touches, because AI is very good at producing a working first version and much less good at carrying a system for five years.

So the real decision is not “is building cheaper now.” It is “for this specific tool, was the expense in the build or in the Tail.” That is the Rebuild Line. AI moved the line, but only in one direction and only for one kind of software: the tools where the build was most of the cost and the Tail is light. For everything with a heavy Tail, the line did not move, no matter how cheap the first version got.

Two terms carry the rest of this piece. The Ownership Tail is the recurring cost of keeping software alive after it works. The Rebuild Line is the threshold where AI-collapsed build cost actually makes rebuilding beat subscribing, which happens only where the Tail is light. Keep both in your head and most of the “should I rebuild this” noise resolves itself.

What AI actually cut

Be precise about the win, because the win is genuine. AI compressed the part of software creation that used to eat the most calendar time up front: scaffolding a project, wiring the boring integrations, writing the first pass of the business logic, generating tests, and getting to a demo that works. That is why teams that used to budget a quarter for an internal tool now ship one in a week. The shift toward writing the spec and letting agents produce the code is real, and it is the reason the build number fell.

Now be equally precise about what did not get cheaper. A working first version is not an owned system. Between “it works in the demo” and “it runs my business for five years” sits a gap that AI does not close, and I have written a whole piece on why AI pilots die before they ship for exactly this reason. The demo is the easy 90 percent. The Tail is the last mile that never ends.

It gets sharper than “AI does not help the Tail.” For a lot of teams, AI-generated code makes the Tail worse. GitClear analyzed 211 million lines of code and found that duplicated code blocks rose eightfold in 2024, that the share of new code being rewritten within two weeks climbed from 5.5 percent in 2020 to 7.9 percent, and that refactoring, the single most Tail-reducing activity there is, fell 60 percent over the same window. Follow-on analysis put code churn in AI-heavy environments up 39 percent. One accounting of full lifecycle cost found first-year costs running 12 percent higher once you add review overhead, extra testing, and rework, and unmanaged AI code pushing maintenance toward four times the traditional level by year two.

Read that back slowly. The tool that cut your build cost can, if you are careless, inflate the exact cost that was already 60 to 80 percent of the total. That is not an argument against building with AI. I build with AI every day. It is an argument against pricing a rebuild on the build alone, because the build is the one number AI made unreliable as a proxy for everything else.

The five costs AI does not touch

When I price a rebuild now, I ignore the build almost entirely and estimate the Tail, because the Tail is where the money lives. It breaks into five costs, and none of them shrink just because the first version was cheap to generate.

Maintenance. Software rots. Dependencies change, APIs you called get deprecated, the business rule you hard-coded stops being true, and a thing that worked in March quietly breaks in September. Somebody has to notice, diagnose, and fix it, forever. This is the 60 percent line from every study, and AI helps you produce the fix faster but does not remove the need to catch the break, understand the blast radius, and take responsibility for the change.

Security and compliance. When you rented, the vendor carried the pager for the next zero-day, ran the SOC 2 audit, and kept the data-processing agreement current. When you own, that is you. Every custom app is a new door into your company, and doors need locks, monitoring, and someone who patches the CVE at 11pm. In regulated corners the Tail is heaviest of all, which is why finance and healthcare land at the 70 to 80 percent end of the maintenance range.

Integration and data plumbing. No internal tool lives alone. It has to talk to your billing, your auth, your warehouse, your other tools. That plumbing is brittle, it is bespoke to you, and it breaks whenever anything on either end moves. The demo never shows the plumbing. The Tail is mostly plumbing.

The edge-case long tail. The first 80 percent of a tool is a weekend with an agent. The last 20 percent is the weird customer, the malformed file, the timezone bug, the leap-year case, the state you did not know existed. That last 20 percent is where the real hours go, and it is precisely the part AI is least reliable on, because it lives in the specifics of your business that were never in the training data. I go deeper on this failure surface in why AI agents fall apart in production.

Becoming your own vendor. This is the cost founders forget entirely. When Notion breaks, you file a ticket and go to lunch. When your rebuilt Notion breaks, there is no ticket and no lunch, there is only you. You now own the roadmap, the on-call, the documentation, the “why did this change” institutional memory, and the answer when a teammate asks who supports this. You did not just build a tool. You started a one-customer software company, and you are the only engineer, forever.

The five costs AI does not cut

Cost in the tail	Who carries it when you rent	Who carries it when you own	Does AI shrink it?
Maintenance	The vendor	You, every year	No, and code churn can grow it
Security and compliance	The vendor’s audit and pager	Your pager, your audit	No
Integration and plumbing	Mostly the vendor	You, and it is bespoke	A little
Edge-case long tail	The vendor’s whole customer base	You, alone, in your specifics	No, this is AI’s weak spot
Being your own vendor	Not your problem	Roadmap, on-call, memory	No

The Rebuild Line: a decision matrix

Put the two forces on two axes and the decision becomes a map instead of a mood. On one axis, how much did AI cut the build cost for this specific tool. On the other, how heavy is the Ownership Tail. Where a tool falls tells you what to do with it.

Rebuild now (light tail, big build cut). This is the honest opportunity, and it is real. Simple, stable tools that you use a narrow slice of, where the build was the cost and the ownership burden is low: an internal admin panel, a bespoke workflow tool, a reporting view, the 300-dollar-a-seat SaaS you use for one screen. Here AI genuinely flips the decision. Build it, own it, cancel the subscription.

Wrap, do not rebuild (heavy tail, big build cut). This is the quadrant everyone misfiles as “rebuild.” The build got cheap, but the Tail is brutal: your CRM, your ERP, the system of record with a decade of data, integrations, and compliance baked in. Do not rebuild the engine. Build a thin custom layer on top of the vendor and get the fit you wanted without adopting the Tail. More on this in the next section.

Keep buying (light tail, small build cut). Cheap commodity tools where AI did not really change the math and the subscription is not worth your attention. Email, calendars, the 12-dollar utility. Rebuilding these is a hobby, not a decision. Keep renting and move on.

Buy or stay (heavy tail, small build cut). The tools you should be most grateful to rent: payroll, payments, identity, anything where a mistake is a lawsuit and the vendor’s whole job is carrying that risk. AI did not make these safe to own. The subscription is not a cost, it is insurance.

Wrap, do not rebuild: the missing middle

The loudest version of the SaaS-replacement story only offers two options, rent or rebuild, and that false binary is where most of the money gets wasted. There is a third move that is usually the right one for anything with a heavy Tail, and I want to give it a clear name because naming it changes how often you reach for it: wrap.

Wrapping means you keep the vendor underneath and build a thin custom layer on top that solves your specific grievance. Your team hates the CRM’s interface and the reports do not match how you actually sell. You do not need to rebuild Salesforce and inherit ten years of Tail. You need a custom screen and a couple of workflows that read and write through the CRM’s API, while the vendor keeps carrying the storage, the uptime, the security audit, and the roadmap. You get the fit. They keep the Tail. That is the best trade in the building, and AI made the wrapping layer cheap to build without making the engine underneath cheap to own.

This is the same logic I use for the model layer, where you stay portable enough to survive a vendor change but never bet the business on owning the thing you rent. Own the layer that is specific to you and worth defending. Rent the layer that is generic, heavy, and someone else’s core competence. The 20 percent problem does not require you to replace the platform. It requires you to replace the 20 percent you actually touch, and to do it as a layer, not a teardown.

Wrapping also fails gracefully. If your custom layer breaks, the underlying system of record is still intact and the vendor is still there. If your full rebuild breaks, you are the vendor, at 11pm, with your company’s payroll or pipeline inside a codebase an agent wrote in a hurry. Choose the failure mode you can survive.

A worked example: scoring a real stack

Let me make this concrete with a stack that looks like a lot of small companies. Say you spend on four things: a broad CRM at 1,500 dollars a month, a niche reporting tool at 400 dollars a month that you use for exactly one dashboard, a payroll and HR platform at 800 dollars a month, and email plus calendar at 200 dollars a month. Twenty-nine hundred dollars a month, about 35,000 dollars a year, and rising every renewal. The rebuild fever says burn it all down. The Rebuild Line says score each one.

The reporting tool is the clean rebuild. The Tail is light, it is a read-only view over data you already own, and you use a sliver of what you pay for. A rough public benchmark for this kind of tool is that a mid-priced SaaS seat around 150 dollars a month can be matched by a custom build in the low tens of thousands that pays for itself in under a year and costs about a third as much by year three. On a 400-dollar-a-month single-dashboard tool the math is even friendlier. Rebuild it, own it, cancel it.

The CRM is the trap. The build got cheap, but the Tail is enormous: years of data, the integrations into everything, the pipeline your revenue depends on. This is a wrap, not a rebuild. Build the custom screen and the two workflows your team actually wants, keep the vendor underneath, and stop there.

Payroll is a “stay,” full stop. Heavy Tail, real legal risk, and a vendor whose entire job is absorbing that risk. AI did not change this. Email and calendar are a “keep buying.” The subscription is 200 dollars and rebuilding it would be a vanity project. Out of a 35,000-dollar stack, exactly one line item crosses the Rebuild Line cleanly, one is a wrap, and two stay rented. That is what a real answer looks like, and it is a very different answer from “SaaS is dead.”

I have run this exact play. In one of my companies we owned a reporting dashboard that a vendor wanted about 5,000 dollars a year for, and we used exactly one screen of it. We rebuilt it in a few days, cancelled the subscription, and it has needed maybe an hour of attention since, because the tail really was that light. In the same quarter we got ambitious and started rebuilding a piece of our billing flow. The tail arrived inside two weeks, in the form of edge cases and a compliance question I did not want to own, and we retreated to a thin wrap on top of the existing provider. Two rebuilds, two honest verdicts, and the tail called both of them before we had written much code.

Scoring a 35,000 dollar stack on the Rebuild Line

Tool	Build cut by AI?	Ownership tail	Verdict
Reporting tool, 400/mo, one dashboard	A lot	Light	Rebuild now
CRM, 1,500/mo, system of record	A lot	Heavy	Wrap, do not rebuild
Payroll and HR, 800/mo	A little	Heavy, legal risk	Stay
Email and calendar, 200/mo	A little	Light	Keep buying

Notice what the scoring did. It turned a 35,000-dollar emotional decision into four small, unemotional ones, and it protected you from the two failure modes at once: paying the ownership tax on payroll that you never should have taken on, and leaving 4,800 dollars a year on the table for a dashboard you should obviously own. This is the same posture I bring to the internal AI stack, where the rule is build the control layer and buy the plumbing, and to the hire-versus-automate decision, where you unbundle a role instead of answering yes or no to the whole thing.

The one ratio that settles most of it

If you want a single number to carry into the room, use the tail-to-build ratio: estimate five years of ownership cost for a tool, then divide it by the cost to build the first version. When the ratio is low, say the tail is one or two times the build, you are mostly deciding whether to build, and AI made that part easy, so build. When the ratio is high, say the tail is five or ten times the build, you are not really deciding to build at all. You are deciding to maintain, secure, and carry a system for five years, and the build cost is a rounding error inside that larger decision. A free build does not help you when the build was never the number that mattered.

This is why the reporting dashboard and the payroll platform get opposite answers even though AI cut the build on both. The dashboard has a low ratio, cheap to build and cheap to keep, so the build discount decides it. Payroll has a brutal ratio, where whatever the build costs, the tail of compliance and liability and change-management dwarfs it, so the discount changes nothing. Same build cut, opposite verdict, and the ratio is what separates them. Before you let a cheap first version seduce you, write down the five-year tail and hold it up against the build. If that number is large, close the laptop and go wrap or keep renting. The ratio, not the demo, is the honest input.

The contrarian take: even Klarna blinked

Here is what most people get wrong, and it is worth sitting with because the loudest voices are the ones getting it wrong at scale.

The reigning story is “AI made building cheap, so the build vs buy decision now favors building, across the board.” The receipts get waved around as proof. But look at the most famous receipt of all. Klarna announced it would shut down its SaaS providers, walk away from Salesforce and Workday, and replace them with internally built AI. It was the headline that launched a thousand “SaaS is dead” posts. And then reporting caught up with the reality: Klarna did not replace those systems with pure in-house AI. It largely replaced them with different SaaS. The poster child for burning down the subscription stack quietly ended up renting again, just from someone else. Salesforce’s CEO publicly doubted they could manage without those systems, and on the specific claim of full in-house replacement, the doubt aged well.

That is not a story about Klarna being foolish. It is a story about the Ownership Tail being heavier than the build-cost headline lets you feel. When a company with Klarna’s engineering depth points at its heaviest systems of record and blinks, the lesson is not “they lacked nerve.” The lesson is that the Tail on payroll, HR, and the customer system of record is exactly the kind that does not get cheaper because the first version was fast to generate.

Notice, too, who funded the loudest SaaS-killer. Chamath’s Software Factory raised its round led by Salesforce Ventures. The incumbent SaaS giant is investing in the tool that is supposed to end SaaS, because the incumbents understand something the fever forgets: most of what they sell is not the build, it is the carrying of the Tail, and that business is not going anywhere. And the market agrees in its own numbers. Gartner still expects enterprise software spend to grow double digits, with much of it flowing into price increases and AI features inside the tools you already rent. SaaS is not dying. It is repricing. The founders who treat “repricing” as “dying” are going to rebuild a pile of Tail they did not need to own, and discover the tax the hard way, one 11pm outage at a time.

The sober version is less exciting and much more useful. AI cut the cheapest part of software. The expensive part is exactly where it always was, and for a lot of your stack it is heavier than ever. Build where the build was the cost. Rent where the ownership is the cost. Almost everything interesting is in learning to tell those two apart before you write code, not after.

What to do Monday morning

Do not rebuild anything on impulse. Do this instead.

Pull the list. Export every software subscription you pay for, with the annual cost next to it. Most founders have never seen this list in one place, and the list alone is worth the hour.

Find your 20 percent tools. For each line, write down roughly what fraction of the product you actually use. Circle the ones where you pay for a platform and touch a sliver. Those are your rebuild and wrap candidates. Everything else, leave alone.

Score the circled ones on two axes. For each, ask how much AI actually cut the build, and how heavy the Ownership Tail is. Be honest about the Tail. Include maintenance, security, integration, edge cases, and the fact that you become the vendor. Place each tool in one of the four boxes.

Pick exactly one rebuild. Take the single tool that sits cleanest in the bottom-right, light tail and high spend and narrow use, and make that your first and only rebuild candidate this quarter. One. The discipline is the point. If AI-native building is going to help you, it will prove it on one contained tool before you trust it with your stack. This is the same one-tool-first restraint I argue for across the AI-native founder playbook.

Price the tail, not the build. Before you commit, write down who is on call when it breaks, who patches the security hole, who owns the roadmap, and what happens when that person is on vacation. If you cannot answer those, you are not ready to own it, and the honest move is to wrap or keep renting. Budget the running cost the way I argue for in the metered-cost discipline of the AI efficiency trap, because the Tail has a monthly bill too.

Default everything heavy to wrap. For any circled tool with a heavy Tail, do not rebuild and do not just accept the pain. Build the thin custom layer on top and stop there. The judgment call underneath all of this, the one AI cannot make for you, is the theme of how founders should actually think about AI, and it comes down to knowing which costs you are grateful to hand to someone else.

FAQ

Is SaaS dead?

No. SaaS is repricing, not dying. Gartner still projects double-digit growth in enterprise software spend, with much of it going to AI features embedded in the tools you already rent. What is changing is that the narrow, light-maintenance tools you use a sliver of are now cheap enough to rebuild, so the low end of SaaS is under real pressure. The systems of record with heavy ownership tails are not going anywhere.

Doesn’t AI make building software basically free?

AI made the build cheap, not the ownership. Across decades of research, maintenance runs 50 to 80 percent of a software system’s lifetime cost, and Gartner has pegged 55 to 80 percent of IT budgets as spend on keeping existing systems alive. AI compressed the small slice, the build, and left the large slice, the tail, mostly untouched. Pricing a rebuild on the build alone is the core mistake.

What is the ownership tail?

It is everything you pay for after software works the first time, for as long as you keep it: maintenance, security and compliance, integration plumbing, the long tail of edge cases, and the cost of becoming your own vendor with no one to escalate to. When you rent, the vendor carries the tail. When you build, you carry it forever. It is 60 to 80 cents of every software dollar, and it is where rebuild decisions actually live or die.

When does rebuilding actually win?

When the build was most of the cost and the ownership tail is light. In practice that means simple, stable tools you use a narrow slice of, with low security and compliance burden and few integrations: internal admin panels, single-dashboard reporting, bespoke workflow tools, the expensive per-seat SaaS you use for one screen. That is the bottom-right box of the Rebuild Line. It is a real opportunity, and it is a smaller box than the fever suggests.

Should I rebuild my CRM or ERP with AI?

Almost never rebuild it. The build got cheap but the tail is brutal: years of data, deep integrations, compliance, and revenue depending on it. Wrap it instead. Build a thin custom layer on top that fixes your specific grievance, and let the vendor keep carrying storage, uptime, security, and the roadmap. You get the fit without adopting the tail, and if your layer breaks the system of record is still intact.

Does AI-generated code lower maintenance cost?

Often the opposite, if you are not careful. GitClear’s analysis of 211 million lines of code found duplicated blocks rising eightfold, code being rewritten within two weeks climbing from 5.5 to 7.9 percent, and refactoring falling 60 percent. Follow-on work put churn in AI-heavy environments up 39 percent and unmanaged AI code pushing maintenance toward four times normal by year two. AI can inflate the exact cost that was already the majority of the total. Build with AI, but treat the tail as the thing you are actually managing.

What does “wrap, do not rebuild” mean?

It is the third option between renting and rebuilding. You keep the SaaS vendor underneath and build a thin custom layer on top, usually through their API, that solves the specific thing your team hates. You own the layer that is specific to you and worth defending, and you rent the heavy, generic engine underneath. It is almost always the right move for anything with a heavy ownership tail, and AI made the wrapping layer cheap without making the engine cheap to own.

How do I decide across my whole stack?

Export every subscription with its annual cost, mark the fraction of each product you actually use, and circle the tools where you pay for a platform and touch a sliver. Score only the circled ones on two axes, how much AI cut the build and how heavy the tail is, and place each in the Rebuild Line matrix. Pick exactly one clean rebuild candidate for the quarter, wrap anything heavy, and keep renting the rest. One contained rebuild teaches you more than a stack-wide teardown ever will.

If this was useful, the deeper argument for which layers to own and which to rent runs through the AI opportunity map for 2026, the economics of what AI actually costs to run, and the gap between a working demo and a shipped system. Own the layer that is yours. Rent the tail.