The robot built the house. Note who still built the foundation.
Last week Pieter Levels posted a list of fourteen SaaS services he'd replaced with software he built himself. Weather APIs, image resizing, NSFW detection, video streaming, screenshot generation, error monitoring, uptime checks, maps, scraping, his blog platform, his photo editor. Human moderators replaced by a model. Most of tier-one support replaced by a bot. Total: roughly $25,000 a month, gone. He has since written up the full breakdown, service by service. The post did half a million views in a few days, which tells you it landed on a nerve.
The original post, 9 September 2026. Source
The obvious reading is the triumphant one: AI killed SaaS, build everything yourself, cancel your subscriptions. That reading is wrong, and the evidence is in the same post. Because he also listed what he kept: Cloudflare for domains, email and R2, Backblaze B2, Hetzner for servers, and a frontier lab for the models. Six services he had no interest in rebuilding, sitting right next to fourteen he killed without much ceremony.
That split is the actual story. Something now separates software you pay for from software you replace on a Saturday, and it isn't category, price tier, or quality. It's a threshold, and the threshold moved.
This isn't one guy with unusual habits
It's easy to dismiss a solo founder running lean as an outlier. He isn't one, he's just early and loud about it. The tools that lose this argument are consistent: workflow automation, internal admin panels, dashboards, form builders. Anything where a company touches maybe 20% of the feature surface and pays per seat as though it used all of it. That was a perfectly good business model when rebuilding the 20% cost six engineer-months.
Three ways a SaaS product dies
Every tool your company pays for is now being quietly evaluated against a new alternative: an afternoon with a coding agent. It has to clear three gates to survive that comparison, and failing any one of them is fatal.
Gate one: legibility to agents
Work is moving into the agent loop. If your product can't be reached from inside that loop (no MCP server, no coherent API, authentication that assumes a browser session and a human clicking "Approve"), then you are outside the place where the work now happens. MCP went from a launch announcement in late 2024 to something every serious tool now ships support for, and it got there in about eighteen months. It has stopped being an early-adopter curiosity and started being plumbing.
Being unreachable from an agent used to be a minor integration gap. Now it's an existential one, because nobody integrates manually any more. They ask the agent to build the part they need, which it can reach by definition.
Gate two: the comprehension tax
This is the one most founders still misread. For twenty years, complexity was a moat. Deep configuration, a certification program, a partner ecosystem, an implementation consultant: all of it made you harder to leave. Switching costs were the business model.
That logic inverts the moment rebuilding is cheap. If it takes me three days to understand your permissions model and two hours to have an agent build the slice of it I actually use, your depth stopped being a moat and became an eviction notice. Complexity is no longer a cost of leaving. It's a cost of staying, paid up front, and it is now directly comparable against a build estimate.
And the two paths don't even end in the same place. Reading the documentation is not a shortcut to what you wanted. It's a negotiation with what the vendor decided to support. You spend an afternoon in configuration screens, you learn which of your requirements the product has opinions about, you give up on two of them, you find a workaround for a third, and you arrive at something that partially does the job. Building takes about the same afternoon and arrives at the thing you actually described, because the requirement was the input rather than something to be bargained down.
Put those side by side and the subscription looks strange. You are paying every month for the compromise. Not for the software, for the gap between what you needed and what the product was willing to do, maintained in perpetuity, with a price increase every renewal.
Gate three: price against the rebuild, not the market
Pricing pages are still written as though the competition is the other vendor in the category. It isn't. The real comparison is against an afternoon of agent time plus whatever the maintenance turns out to cost. When a $250/mo screenshot API meets a service that took two hours to write and costs nothing to run, the $250 isn't expensive relative to competitors, it's expensive relative to zero, and that's the number it's being judged against.
Every line item on Levels' list was individually defensible. Two hundred and fifty dollars here, five hundred there. Collectively they were $25,000/mo, and each one failed the same comparison independently.
What survived, and why
Look at the six he kept and a pattern appears immediately.
Everything that survived has at least one of three properties, and none of them are features:
1. There's physics underneath. Hetzner has data centres. Cloudflare has an anycast network and IP reputation built over fifteen years. R2 and B2 have spinning disks in buildings. You cannot vibe code a data centre, and an agent that writes perfect code still can't write you an AS number with a clean sending history.
2. Someone else carries the liability. Payments, payroll, identity, compliance. You are buying the indemnity, not the software. Nobody rebuilds Stripe to save a fee; they'd be rebuilding the regulatory posture, and that isn't code.
3. The data or the network can't be instantiated alone. A frontier model API is the clearest case: the weights represent capital expenditure at a scale that makes "build it yourself" a category error rather than a trade-off.
The bill doesn't disappear, it changes form
Here's where I'd push back on the triumphant version of this story, and Levels himself has made the same point elsewhere: building is the easy part, scaling is where it gets hard. Cancelling fourteen subscriptions doesn't leave you with $25,000. It leaves you with $25,000 minus fourteen new on-call surfaces.
The custom NSFW detector has a false-negative rate that is now your legal problem. The self-hosted video streaming has an outage profile that is now your weekend. The scraper breaks when the target site ships a new layout, and it will, and nobody sends you a changelog. Every vendor you fire hands you back their roadmap, their pager, and their edge cases, and an agent that wrote the code in two hours will not notice the day it starts silently failing.
The build-versus-buy decision was never really about cost. It's about which maintenance you want to own.
That reframing is what makes this tractable. A one-person business can absorb fourteen small maintenance surfaces because the founder is the whole feedback loop and notices when something breaks. A fifty-person company replacing its CRM with an internal build is making a very different bet: the tool outlives the person who built it, and the honest cost is whoever maintains it in year three, not the afternoon it took to ship.
So the threshold is real, but it's personal. It sits at a different place for a solo founder than for a mid-size company, and the mistake I see most often right now is teams reading a viral post written from one side of that line and applying it from the other.
If you sell software, this is your product roadmap
Five things follow directly from the three gates, and every one of them is shippable this quarter:
Cut surface area instead of adding it. The reflex when a competitor ships something is to ship it too, and products accumulate screens the way a garage accumulates boxes. Every screen a customer has to understand before they get value is a charge on the comprehension tax, and they are now weighing that charge against an agent that will build them the one screen they actually wanted and nothing else. For most products the roadmap that keeps them alive is mostly subtraction: fewer settings, fewer concepts, fewer things a person has to learn before the software does the job they came for. A bloated product used to look like a rich one. Now it looks like a rebuild brief.
Ship an MCP server, and treat it as a tier-one surface. Not a side project maintained by one enthusiast. The agent is now a user of your product, and in a growing number of accounts it is the only user who touches it daily. If it can't authenticate, discover your tools, and finish a real task without a human in the browser, you are invisible exactly where the buying decision gets made. Any capability that exists only in your interface is, from that agent's point of view, a capability that does not exist.
Measure time to first real outcome, in minutes. Not signup-to-dashboard. Signup to the thing the customer actually came for. That number is now in direct competition with a build estimate, and every configuration screen between the two is a payment on the comprehension tax.
Price against the rebuild, not the category. Find the part of your product that's genuinely hard (the thing with physics, liability, data or scale behind it) and make sure that's what the price is attached to. If your revenue is concentrated on the easy 20% that a competent agent reproduces in an afternoon, that revenue has a clock on it regardless of how good the product is.
Decide, deliberately, whether you're interface or substrate. Interfaces get replaced. Substrate gets built on. Most SaaS companies are currently interfaces that would rather not think about it, and the transition is a strategy decision with a shelf life, not a design refresh.
The threshold moved, not the logic
Nobody ever bought software because they loved paying for it. They bought it because building was expensive, and the subscription was cheaper than the engineering. That calculation hasn't changed. One of its inputs collapsed.
What's left of SaaS is everything that was never really about the software: the network you can't recreate, the liability you don't want, the hardware you'd have to buy, the scale you can't reach alone. That's a smaller business than the industry currently prices itself at, and a much more durable one.
If you build one of these products, the survival move is not a bigger feature set. It is a smaller one an agent can drive. Make the thing simple enough that rebuilding it feels like pointless work, and reachable enough that your customer's agent picks you up instead of routing around you. Do both and you stop competing against an afternoon of agent time. Do neither and you are quietly financing your own replacement, one screen at a time.
A useful exercise, and it takes twenty minutes: open your company's subscription list and run each line through the three gates. Can an agent drive it? Is it faster to learn than to rebuild? Is it cheaper than owning it? Most tools clear all three and you'll close the spreadsheet reassured. The few that don't are the ones someone on your team is already quietly rebuilding. And if you sell software, that same list is being run against you right now by somebody who hasn't told you yet.