What Survives When Anyone Can Build Anything

AI can generate the tool. The real market is still in owning the upkeep, especially for recurring problems nobody wants to operate themselves.

The "is SaaS dead?" debate keeps landing in the wrong place.

It keeps staring at the build step, because the build step used to be the hard part. If AI can generate the app, wire the dashboard, and scaffold the settings page, the old conclusion follows fast: software margins collapse, every product becomes a wrapper, game over.

But maybe you're the kind of builder who has already felt the hole in that logic.

You've got AI helping you ship faster. You've seen how far a motivated non-engineer can get with a one-page app. You've also watched the whole thing get shaky the moment the problem repeats, edge cases pile up, or the stakes climb above this would be nice to have.

A quick test helps here. I'll get to it.

The part people actually buy

People rarely buy software just because it solves a problem once.

They buy software because they want a repeatable solution, but do not want to become the person who now has to watch it, patch it, restore it, answer for it, and quietly carry it in their head.

That is the part the "SaaS is dead" argument keeps skimming past. AI lowers the cost of producing a tool. It helps with parts of upkeep too. But it does not remove the ongoing burden of owning a problem in the real world.

And real world problems are rude. They repeat. They drift. They break on Thursdays. They interact with other systems you forgot existed. They acquire users who click in a different order than you expected. They create one tiny failure at 2:13 a.m. that turns your clever shortcut into an unpaid job.

Software has always had two layers. One layer is visible, the interface, the feature set, the thing a demo shows. The other layer is invisible, the quiet promise that this thing will keep working when reality touches it.

The second layer is where money survives.

Cheap construction changes the buyer's math

When a thing becomes easier to build, people assume buyers will stop paying for it. Sometimes they do. Usually when the problem is shallow, one-off, and low-stakes.

A landing page is close to that. A tiny internal helper is often close to that. A script you run twice a month might be close enough.

And to be fair, some software categories really will get cheaper or disappear. If the workflow is simple, the consequences are low, and the team already has to own the process anyway, AI absolutely makes buying less necessary.

But a repeating problem with consequences follows a different curve.

PostgreSQL is free and open source, with over 35 years of active development behind it.¹ Yet managed Postgres remains a real business because many teams do not want database backups, point-in-time recovery, upgrades, failover, and operational risk to become a side quest. Amazon RDS lists backups and point-in-time restores as part of its managed PostgreSQL offering.² The engine being available did not remove the market. It clarified what the market was paying for.

Same pattern elsewhere.

Deploying code is easier than ever. Vercel still highlights automatic deployments on every branch push, preview deployments for every push, and instant rollbacks.³ Shipping is never the whole job. Recovery is part of the product.

And you can see the same shape outside software. Otis says it maintains around 2.5 million customer units worldwide and emphasizes getting customers back into service faster.⁴ The elevator is the visible object. The dependable business is the standing promise that someone will answer when the object misbehaves.

Software was the strange exception. The build step was so hard for so long that it hid the services business underneath.

AI didn't end SaaS. It stripped the disguise off a pattern the industrial world has been running forever.

Once you see this, the frame changes.

The question stops being "Can AI build the software?" and becomes "who wants to own the maintenance boundary around this problem?"

The Ownership Test

If you're building in the AI era, this is the test I would use.

Call it The Ownership Test.

1. Does the problem come back?
2. Does failure matter when it comes back?
3. Does the buyer want to become the operator?

If the answer is yes, yes, no, there is still room to charge. That third question is the one most people underrate.

Builders overestimate the customer's desire to "have control." What many customers actually want is relief. They want a boundary. They want to pay money and stop thinking about a category of recurring mess.

This is why just works sounds like weak positioning to builders and strong positioning to buyers. Builders hear laziness in that phrase. Buyers hear the removal of a future obligation.

The phrase also gets stronger as the buyer gets busier.

A founder with one painful workflow might enjoy assembling a custom AI stack on a Saturday. A founder with twelve painful workflows and a team depending on outcomes starts valuing a different thing. Less possibility. More certainty. Less authorship. More trust.

The sale shifts from capability to custody.

Pricing will probably follow that shift too. The closer you get to carrying the outcome, the stranger it feels to charge only for access.

The mirror question

There's a fourth question, and it lives on the builder's side of the table.

Do you want to become the operator?

If the answer is yes, and the customer's yes-yes-no lines up with it, you've found a durable business. If not, you've found a business that prints money while it burns you out.

Just works is a promise that someone, somewhere, is carrying the weight when reality refuses to behave. AI lowered the cost of building. It did not lower the cost of being responsible. The founder who sells relief is often the person staring at a laptop on a Thursday night, trying to figure out why one integration changed its response shape.

The durable builders pick categories where custody suits them. The rest of us should notice when just works means I'll be the one who never sleeps through a Saturday again.

AI widens the gap between demos and responsibility

AI makes demos cheap.

Agents may make the interface thinner too. That still leaves the question of who is accountable when the work crosses real systems. That matters. It means more competitors, more feature parity, and far less protection from "we built this too."

It also helps with some maintenance work. AI can draft migrations, explain logs, write monitoring queries, and patch small failures faster than before.

And yet the gap between something that looks solved and something a customer is comfortable depending on still holds. In some categories it may even get more obvious, because the visible layer got easier faster than the invisible one.

You can feel it when someone shows you a slick AI-generated prototype that works beautifully in the happy path, then gets weird the moment you ask about audit trails, permissions, billing edge cases, retries, monitoring, or what happens after the third integration changes its API.

In other words, AI compresses the distance between idea and artifact. It does not compress the distance between artifact and reliability nearly as much.

That changes where the margin hides. Less in raw feature creation. More in taste, trust, ongoing care, and narrowing the failure surface for the customer.

Which sounds almost boring.

Good.

Boring is where durable businesses often live. Especially when the alternative is a custom stack with nobody clearly responsible for what happens after launch.

What buyers are really outsourcing

People say they want software. A lot of the time they are outsourcing four quieter things:

1. Judgment about defaults
2. Maintenance of the moving parts
3. Accountability when something breaks
4. The mental freedom of not owning the category anymore

This is why a product can survive even when a smart customer knows they could build a version themselves.

They are not comparing your monthly price to the cost of generating some code. They are comparing it to the cost of becoming the caretaker.

That cost is usually mispriced because most people only count the obvious part. They count setup time. They forget ongoing decisions. They forget error handling. They forget what context-switching does to a week. They forget the moment a custom solution becomes important enough that it starts asking for standards, documentation, and handoff.

The first version of a custom tool feels like freedom. Version seven feels like ownership, and those are different emotional products.

The winners will define smaller promises

I do not think the future belongs to undifferentiated SaaS, broad dashboards with loose promises and interchangeable features.

I do think curated software with sharp scope, especially when it carries infrastructure, compliance, payments, medical data, or other operational burden the customer does not want to own, can stay extremely valuable.

That usually means a smaller promise.

Cleaner scope. Fewer edge cases exposed to the user. Tighter positioning around one repeating pain. More obvious responsibility. Less "platform." More "this category of problem leaves your head when you hire us."

AI actually helps here.

It makes it cheaper to build the visible layer. That gives founders more room to invest in the invisible layer, the operations, the defaults, the support logic, the recovery paths, the careful opinion about what happens when reality refuses to behave.

The founders who keep arguing about whether SaaS is alive may miss the more useful question. Where, exactly, are people still desperate to stop owning the upkeep? And then, quieter: are you the one who wants to pick it up?

That is where just works stops sounding generic and starts sounding expensive. On both sides.

The durable business in the AI era is the one that removes a recurring responsibility the customer no longer wants to carry.

Build for that, if you can carry it.

Rabbit hole

If this angle resonates, keep going with Pay per result might be the unit test for pricing AI SaaS, Software companies are becoming staffing agencies, and Go ahead, build what already exists.

Footnotes

1. PostgreSQL describes itself as a free, open source database system with over 35 years of active development. That supports the point here: the core engine is mature and available, but many teams still prefer not to operate it themselves. Source: PostgreSQL.
2. Amazon RDS for PostgreSQL documentation lists backups and point-in-time restores among the managed capabilities. I used that as evidence for the broader claim that buyers often pay to avoid the operational surface area around a tool. Source: Amazon RDS for PostgreSQL.
3. Vercel's Git deployment docs say it supports automatic deployments on every branch push, preview deployments for every push, and instant rollbacks. That makes it a clean example of a company selling smoother operation around an already easier build pipeline. Source: Vercel Git deployments.
4. Otis says it maintains around 2.5 million customer units worldwide, and on its main site it emphasizes service teams that ensure a faster return to service. I used this as a grounded industrial example of the ongoing-value argument, without making the stronger profit-mix claim from the earlier draft. Source: Otis.