Ronnie Coleman has a line that has survived far beyond bodybuilding. His own brand site still treats it as one of his defining sayings: "Everybody wants to be a bodybuilder, but don't nobody want to lift no heavy ass weights." You can find some version of it all over the internet, but the point is not the punctuation. The point is that everybody wants the outcome. Everybody wants the trophy, the physique, the proof that they did something serious. Fewer people want the cost structure that comes with it.

That is why I keep thinking about Ronnie when people talk about the coming SaaS apocalypse. The strongest version of that argument is obvious enough to understand. AI coding tools are reducing the cost of creating software. Teams that previously had to buy generic tools can now build more of their own. Internal workflows, dashboards, approval systems, territory tooling, lightweight CRMs, planning surfaces, team-specific copilots, and a hundred thin wrappers around existing systems suddenly look much more achievable than they did two years ago.

That part is real. The weak version is where people jump from there to SaaS is dead, every company will build everything, and the vendors are cooked. I'm not that doomer about SaaS. I think the real shift is more interesting and more durable than that.

AI is changing the cost of creating software much faster than it is changing the cost of owning software. That is the whole essay. If you understand that sentence, the rest of the argument becomes clearer. Creation cost is the cost of getting something working. Ownership cost is the cost of carrying that thing for years. Those are not the same problem, and in software we are about to watch a lot of people confuse them. That is the Ronnie Coleman paradox in software: everybody wants the upside of custom tools, but far fewer people want the maintenance bill that comes with owning them.

Ronnie Was Optimizing for a Different Goal

The easiest way to flatten Ronnie Coleman into a lazy metaphor is to make him the patron saint of bad trade-offs. That would miss the point. Ronnie was not confused. He was optimizing for a specific thing: being the biggest and best bodybuilder in the world.

If the goal is Mr. Olympia, a lot of choices that look insane from the outside start to look coherent inside the system. The volume. The intensity. The repetition. The brutality. The willingness to make tomorrow's joints pay for today's adaptation. He trained for a very specific scoreboard, and he won it eight times. That matters because the lesson is not "hard work is bad." The lesson is that maximum effort only makes sense relative to the goal you are actually optimizing for. If the goal is winning at the highest possible level in a brutally competitive domain, you accept some damage. If the goal is lifting pain-free at sixty-five, you probably make different choices.

That second half matters here too. In Ronnie Coleman: The King, the documentary description frames the story plainly: his body bears the scars of becoming the best in the world. That does not erase the achievement. It clarifies the price. That distinction maps almost perfectly onto how teams are about to behave with AI-assisted software building.

A lot of companies are feeling a new kind of temptation right now: we can build this ourselves. And a surprising amount of the time, they are right. They can generate a first version of the internal tool, stitch together the workflow app, build the reporting layer, create the approval system, wire up the AI summarizer, build the sales copilot, and replace some small SaaS tool that always annoyed them.

What they are less excited to think about is what happens next. Who owns the edge cases? Who stays on call? Who handles the upgrade? Who patches the security issue? Who rebuilds the integration when the upstream API changes? Who explains the weird logic to the next hire? Who cleans up the data model after version three accretes into version nine? Who fixes the thing when the original builder leaves?

That is the heavy-ass weight. The reason Ronnie is the right metaphor is not because software builders are masochists. It is because a lot of them are about to optimize for the wrong scoreboard. The scoreboard they are watching is could we build it. The scoreboard they should be watching is should we own it. Those are wildly different questions, and most of the confusion in the current market comes from collapsing them into one.

Why the SaaSpocalypse Feels True

To be clear, there is a reason the idea has traction. The old world had a very large creation tax. If a company wanted software tailored to its exact workflow, it usually had three bad options: suffer through generic SaaS that almost fit, hire consultants to create a bloated custom system that took forever and nobody wanted to touch later, or staff an internal engineering project and hope the software was important enough to justify the distraction.

That meant a lot of teams bought software not because it was great, but because building was prohibitively expensive. The median company did not lack ideas. It lacked a cheap path from idea to functioning tool. That is what changed.

Claude Code, Codex, Cursor, Windsurf, GitHub Copilot, and the whole broader agentic build-tool universe are shrinking the cost of taking a messy workflow and turning it into a real software object. Not a perfect software object. Not a finished product. But something useful enough to matter.

This is especially true in the exact places where traditional SaaS got lazy:

  • awkward internal workflows that are too specific to justify a full product
  • approval systems with company-specific rules
  • niche sales or recruiting tooling
  • reporting layers that mostly sit on top of existing systems
  • small agent dashboards
  • glue code between two or three applications that were never really designed to work together
  • operational utilities that everyone needs and nobody wants to pay enterprise pricing for

These categories are vulnerable because a lot of their historical value came from one fact: software was annoying to make. If making software gets easier, those businesses get pressure from both sides. The buyer can build more, and competing products can be built faster.

That is why the SaaSpocalypse framing feels directionally right. Something real is happening. The frontier between buy and build is moving. More custom software will be written inside companies that did not think of themselves as software companies. More teams will build internal tools instead of buying them. More departments will own a lightweight system tailored exactly to the way they work. More founders will look at a bloated SaaS category and say, with some justification, "that is mostly a workflow and a database."

Again, that part is real. I think the mistake is what comes next. People take a true statement, more software is buildable now, and stretch it into a much weaker one: therefore owning software is no longer expensive. That is where the argument falls apart.

Creation and Ownership Are Different Problems

The first version of a product is not the product. It is the opening bid. This is one of those truths that everybody knows in theory and almost nobody prices correctly in practice. A team can now get to version one much faster than before. That is enormous. But version one is not where software costs go to die. It is where they begin to compound.

Creation cost is front-loaded. Ownership cost is recurring. Creation cost is exciting. Ownership cost is administrative, reputational, operational, and deeply unsexy.

Creation cost gets you the dopamine hit of "we built it." Ownership cost gives you the email at 6:42 a.m. because the cron broke after a dependency update and nobody noticed the stale data for two days. Those are not remotely the same thing.

Ownership means:

  • uptime
  • backups
  • disaster recovery
  • security patches
  • permissions and access control
  • schema migrations
  • integration maintenance
  • observability
  • incident response
  • performance tuning
  • compliance requirements
  • documentation
  • support burden
  • turnover risk
  • domain drift as the business changes

None of that disappears because the code was easy to generate. If anything, some of it becomes more likely, because more people will create more software with less initial friction.

That is the subtle problem hidden inside the current optimism. AI makes it easier to put weight on the bar. It does not automatically give you stronger joints. A lot of executives and operators are about to discover that the cost of custom software was never only typing the code. It was carrying the consequences of owning it.

That is why the real question is not can an agent build this. It is what happens if this becomes important. That second question is where the economics come back. Because the moment something becomes important, you need reliability. The moment you need reliability, you need process. The moment you need process, you need ownership. And ownership is where the maintenance bill starts.

This is not a moral argument against building. It is the opposite. I think more teams should build software than before. I just think they need to stop pretending that the first draft of the code is the whole cost.

We Have Seen This Movie Before

This is one reason I do not believe the "everything will be built in-house" version of the story. We already ran a variation of this experiment under a different name: open source.

For a long time, companies have been fully capable of building and operating serious internal infrastructure. They can run Postgres, Elasticsearch, Kafka, Prometheus, Grafana, authentication systems, and their own queues, caches, search clusters, and observability pipelines. And plenty of companies do.

But a huge number still move toward managed services anyway, not because they are too dumb to self-host, but because the long-term operating burden is real.

One of the most honest engineering lines I have seen on this came from The Guardian's engineering team when they wrote about moving Postgres to Amazon RDS. Their advice was blunt: for technology that is not core to your business, "buy if you can." Their reasoning was not ideological. It was operational. Small teams have limited time. Distributed systems are hard. Managed services can remove work that does not differentiate the company.

That is the right frame. Not that managed services are morally superior, but that some kinds of pain do not buy you advantage.

Jeff Bezos has a great version of this too. In a 2008 talk transcript, he describes visiting a brewery in Luxembourg that used to generate its own electricity before the grid existed. Eventually they stopped, because, as he put it, "that didn't make their beer taste any better." That is the buy-vs-build question in one sentence. Just because something is operationally necessary does not mean it is strategically differentiating.

The same pattern shows up in observability.

Any serious engineering team can stand up some version of ELK, OpenSearch, Prometheus, Grafana, Tempo, Loki, or whatever stack they prefer. And many do, especially early, especially if the team already has the expertise, especially if cost pressure is high.

But running observability at scale becomes its own discipline fast. Data retention. Index tuning. Cardinality explosions. Scaling. Access control. Upgrade pain. Performance cliffs. The whole category exists because telemetry loves to grow faster than good intentions.

That is why managed vendors keep surviving these waves. Not because teams cannot install software. Because installation is not ownership.

Elastic's own pitch for Elastic Observability Serverless is not "you are too weak to use observability." It is that teams do not want to spend their time on node sizing, shard management, scaling mechanics, or backend maintenance when what they actually want is visibility into the system.

The same logic shows up on the database side. AWS describes RDS in deliberately boring terms: hardware provisioning, database setup, patching, backups, and scaling are automated. That sounds boring because it is. It is also exactly the kind of work that stops feeling romantic the second your business depends on it.

This is the thing the maximalist build-everything crowd consistently misses. They treat the decision as if it is software versus no software, but the real decision is usually differentiate here versus carry maintenance here. That is a much more sober equation, and it explains a lot of market behavior that otherwise looks contradictory.

Yes, teams want more custom software. Yes, teams still keep paying vendors. Those are not opposing behaviors. They are the same behavior under a more accurate cost model.

Build the Differentiator, Buy the Burden

If I had to compress the whole essay into one rule, it would be this: build the differentiator, buy the burden.

That is the rule. Not because buying is virtuous. Not because building is reckless. Because companies are not judged by how many technical chores they own. They are judged by what they do better than everyone else.

The build side should include the places where software encodes real advantage:

  • the exact workflow your team uses to make decisions
  • the internal operating system around a unique process
  • the customer experience that is central to your product
  • the logic that captures your moat
  • the tooling that compresses time inside a genuinely proprietary loop
  • the system that reflects how your organization actually thinks

Those are good reasons to build. Those are reasons to accept maintenance as the price of advantage. I feel this personally in the small systems I build for myself.

Aldo exists because no software vendor should care about the exact way I want branch reviews, health checks, Telegram alerts, remediation patches, and personal continuity glued together across my own projects. That workflow is too specific. Too personal. Too weird in the right way. It should be built, because the entire point is that it matches my operating style instead of some average customer's.

The same basic logic applies inside companies.

If you have a workflow that is actually central to how you sell, recruit, support, price, underwrite, onboard, operate, or make decisions, custom software becomes much more reasonable now than it used to be. Not because every company should cosplay as a software company, but because the cost of making the first useful version has dropped dramatically.

That is exactly where AI should widen the build frontier. Where people go wrong is assuming the same logic extends cleanly into every part of the stack. It does not. There are large categories of software where the burden dominates the differentiation.

Auth is the obvious example.

Can you build login, user management, password resets, MFA, session handling, access controls, audit flows, and enterprise identity integrations yourself?

Of course. Should you? Usually no. Because the burden is the product.

The same is true for payments in many cases. For observability in many cases. For incident tooling in many cases. For the primary data platform in many cases. For infrastructure glue that matters only insofar as it disappears when it works.

This is the distinction I think the market will get better at over the next few years. The interesting future is not one where companies stop buying software. It is one where they buy software more selectively and build software more intentionally. That is not the death of SaaS. That is the end of lazy SaaS.

What Actually Moves In-House

If you want a more practical model, I think the stack starts to separate into layers.

1. Workflow software moves in-house fastest

This is where the explosion happens first. Internal approval flows, planning tools, task routing systems, operational dashboards, sales prep layers, research copilots, decision-support tools, integration glue, agent workbenches, and small internal systems that reflect exactly how a team works are suddenly far more buildable, and a lot of them should be built.

They are close to the user. They encode local context. They change often. They are hard for generic vendors to fit cleanly. This is where "custom software for yourself" becomes a real strategic option instead of a fantasy.

2. The system-of-record layer is mixed

There are cases where the system of record is absolutely core to the business. If you are building the product itself, of course you are going to own large parts of that application layer. If your data model is your moat, you do not outsource the heart of it.

But even here, there is a difference between owning the product logic and owning every piece of the operational substrate beneath it.

My own products are a simple example of this. Tannin is mine. The workflow is mine. The application logic is mine. The knowledge ingestion patterns, scan flow, and user experience are mine.

That does not mean I need to become a full-time database operator, search cluster operator, or infra SRE for every layer beneath it. The reason I use managed surfaces is not lack of conviction. It is focus. I care that the product behaves the way I want. I do not need daily spiritual growth from configuring backups. That is the distinction.

3. Heavy infrastructure often stays bought

This is where the SaaSpocalypse narrative gets weakest.

Most companies do not have a deep desire to own observability, auth, payments, email delivery, CDN configuration, failover logic, backup posture, or incident tooling as durable internal competencies.

They may build around these things. They may customize their use of these things. They may integrate them deeply. They may even switch vendors more often as AI makes the application layer more fluid. But that is not the same as wanting to own the heavy lifting directly.

Most companies do not want to become database companies. Most companies do not want to become observability companies. Most companies do not want to become identity companies. What they want is leverage. And sometimes the most leveraged move is buying the weight room instead of pouring your own concrete and maintaining the equipment.

4. The agent layer becomes custom on top of managed foundations

This is the part I think people will underrate next. A lot of the most useful agent systems will be custom, but they will not be built from bare metal. They will sit on top of databases, auth systems, model APIs, deployment platforms, logging platforms, and managed search or storage surfaces. That is important because it breaks the false binary.

The future is not buy everything or build everything. The future is build more of the top of the stack, compose aggressively in the middle, and stay selective about what you own at the bottom. That is a much more believable shape.

The Buy/Build Frontier Is Moving, Not Disappearing

This is the line I keep coming back to: AI does not kill SaaS uniformly. It unbundles software by maintenance burden and strategic value. That is a very different prediction than "SaaS dies."

Some categories are in real danger. Thin workflow wrappers with weak differentiation are in danger. Tools that mostly exist because software was annoying to create are in danger. Products whose real value is "we built a UI around a process you could now describe to an agent" are in danger. Those businesses should be worried.

But categories that absorb heavy recurring burden are not dead just because creation got cheaper. In many cases, they become more important. If more companies build software, more companies need observability, databases, auth, delivery infrastructure, search, storage, logs, queues, caching, and incident response.

That is the paradox. The custom software boom does not only pressure vendors. It also creates more demand for the layers that make custom software survivable. That is why I do not think the right mental model is replacement. It is recomposition. The top of the stack gets more custom. The bottom of the stack often gets more important. And the middle gets rearranged over and over as teams decide what is worth owning. That is a much more plausible future than one giant bonfire of every software company.

What Good Vendors Still Do

One reason I think the "SaaS is dead" argument will age badly is that it still underestimates what the best vendors are actually selling. Bad SaaS often sells access to a workflow. Good SaaS usually sells relief from a category of recurring pain. That is a much harder thing to replace.

A mediocre workflow layer can get attacked by custom software fast. A vendor that quietly absorbs operational burden, edge cases, compliance work, recoverability, uptime guarantees, scaling behavior, and ecosystem churn is harder to dislodge, because what it is really selling is not UI. It is amortized suffering.

That is why I think some parts of the software market will get hit hard while others get stronger. The fragile categories are the ones where the product mostly exists because software used to be hard to create. The stronger categories are the ones where the product exists because owning the problem well takes years of focused attention.

Auth is a good example. You can absolutely build authentication yourself. People do. And for a toy app or a narrow internal tool, maybe that is fine. But once the software matters, auth is not just login screens. It is enterprise SSO, SCIM, role mapping, auditability, recovery flows, abuse prevention, session management, secret rotation, policy weirdness, and customer trust. That is a real product category because the pain compounds.

Databases are similar. Anyone can stand one up. Much fewer people want to own uptime, backups, failover, scaling, restore testing, patch windows, and operational expertise forever. Observability is similar. The open-source path is real. The "live with it in production for years" path is where the full bill shows up. Payments are similar. The API is not the whole business. The ugly part is the business.

This is the frame I think founders and operators should use: if a vendor mainly saves me from repeated pain that does not differentiate my business, that vendor is still in a strong category. That does not mean every incumbent wins. Far from it. It means the surviving vendors will not be the ones with the broadest menus. They will be the ones that make a very specific burden disappear reliably.

That is a useful distinction because it tells you what AI actually pressures. It pressures the categories where creation was the moat. It does not pressure the categories where durable, invisible competence was the moat.

Most Companies Already Know Their Real Core Competencies

One reason I am skeptical of the "everyone will build everything" claim is that most companies already know, at least implicitly, where they actually want to spend their energy. A retailer may want to own merchandising logic, pricing experiments, supply chain insight, and customer experience. A bank may want to own underwriting logic, risk models, internal workflow, and customer trust surfaces. A biotech company may want to own the research platform, not the full burden of generic enterprise identity. A software company may want to own the product experience while absolutely not wanting to become a payment processor or an observability vendor.

These are not signs of weakness. They are signs of focus. The language around core competency gets cheesy because people say it too often in strategy decks, but the concept is still right. A company should own the things that make it better than the market, not every adjacent burden that can technically be implemented with enough engineering labor.

AI will tempt people to forget that because it makes the first act of creation feel deceptively cheap. But "can be implemented" is not the same thing as "should become a durable organizational responsibility." That is the distinction executives, product leaders, and technical teams are going to have to get much better at making.

Not every thing you can build should become part of your permanent metabolic load. Some things should remain rented. Some things should remain managed. Some things should remain someone else's full-time problem. That is not cowardice. That is intelligent allocation of attention.

A Five-Question Test for Build vs Buy

One reason this conversation gets muddy is that people treat buy-vs-build like a personality test. Builders think building is virtuous. Finance people think buying is prudent. Operators think both sides are underestimating the pager. The cleaner way to do it is to ask a short set of questions.

1. Does owning this make us meaningfully better?

Not slightly more customized. Not a little more aesthetically pleasing. Meaningfully better. Does this software encode a workflow, insight, or experience that actually improves how the company competes? If not, you should be skeptical of owning it for long.

2. If this breaks at 2 a.m., do we want that page?

This is one of the most clarifying questions in all of software. If the answer is "absolutely not," there is a good chance you are looking at a burden category rather than a differentiator category. People say they want control until they imagine the actual control surface. Control means the page. Control means the restore. Control means the audit trail. Control means the postmortem.

3. Will this need constant adaptation?

Some systems are expensive because they are deep. Others are expensive because they never stop changing. If the workflow is local, political, team-specific, and moving all the time, custom software becomes more attractive because vendors will always lag your reality. If the problem is stable but operationally ugly, buying gets more attractive because stability favors specialization.

4. If the original builder leaves, are we still fine?

This is the hidden tax almost everyone ignores at first. Some internal tools are one-person miracles. That is not the same thing as being healthy systems. If the value of the software depends on one builder's private memory, then the organization does not own the tool yet. It is borrowing it from a person. That can still be worth it, but it should be named honestly in the decision.

5. Are we saving money, or just moving the bill?

This is the question that kills a lot of shallow cost arguments. Cutting a SaaS contract can look like savings. Sometimes it is. Sometimes it is just converting a visible invoice into invisible labor, future maintenance, and organizational fragility. That can still be the right move if the upside is strategic enough, but it is not free.

If you run those five questions honestly, the answer gets clearer surprisingly fast. Build when the software captures something specific and valuable about how you operate. Buy when the real work is carrying a burden you do not need to turn into an internal competency.

The New Skill Is Architectural Taste

If I had to name the capability this era rewards most, it is not coding speed. It is architectural taste. Not in the abstract, snobby sense. In the concrete sense of being able to answer:

  • where do we actually differentiate?
  • where will software help us compress time or increase quality in a unique way?
  • which tools are strategically worth owning?
  • which systems become long-term injuries if we own them unnecessarily?
  • where is custom logic an advantage?
  • where is custom logic just unpaid future maintenance?

That is the new managerial and technical taste test. And honestly, it is one of the reasons I am more bullish on good engineering judgment in the age of agents than I am on naive "everyone can build anything now" narratives. Because once the barrier to basic creation falls, the real separator becomes decision quality.

Where do you apply the leverage? Where do you stop? Where do you accept a vendor because what they sell is exactly the pain you do not need to own? Where do you reject a vendor because the workflow is specific enough that generic software will always fight you?

This is where I think the best teams will quietly pull away. Not by building the most. By choosing well. The old bragging rights in software were often about how much complexity you could absorb. I think the new bragging rights should be about how cleanly you can decide which complexity is worth absorbing in the first place. That is a much healthier game.

The Ronnie Coleman Paradox

Here is the paradox. Ronnie's approach made sense for the thing he wanted. That is why it is such a useful metaphor. He was not confused about effort. He was willing to pay a price most people only admire from a distance. A lot of software teams are about to volunteer for a similar mismatch.

They want the upside of custom software:

faster workflows better fit less vendor tax more internal leverage more control more speed

All of that is reasonable. But they do not always want the thing that comes with it:

maintenance durability work operator burden security exposure on-call responsibility weird system knowledge the slow rehab of a codebase after the original adrenaline wears off

That is the part people skip. Everybody wants custom software. Don't nobody want to maintain no heavy-ass codebase.

The mature response is not to swear off building. The mature response is to pick your weight class. Build where the software actually expresses your advantage. Buy where the burden dominates the differentiation. Use AI to move faster into the things that are truly yours. Do not use AI as an excuse to inherit five years of maintenance debt in categories you never wanted to own. That is the real discipline this era asks for.

The Takeaway

I do not think SaaS is dead. I think lazy assumptions about what should be bought are dead. I think lazy assumptions about what should be built are dead too.

More companies will build software for themselves. That is real. More companies will discover that software ownership still has weight. That is real too.

The winners will not be the companies that build everything. They will be the companies that know which weight is worth lifting themselves.