Sometime in the last two years the bottleneck shifted. I used to spend most of a greenfield week staring at an empty editor, scaffolding routes, arguing with ORMs, and coaxing CSS into something that did not look like a government form from 2004. Today I can prompt my way to a working CRUD app with auth, a reasonable schema, and even half-decent styling before lunch. The code, it turns out, was never the hard part. The hard part was–and still is–keeping the thing alive once real users touch it.
The SaaS mental model
“Software as a Service” trained an entire generation to think the value lives in the application layer. Build a clever feature, wrap it in a subscription, ship a landing page. The implicit promise: we write the software, you pay monthly, everyone wins. That framing put the spotlight squarely on creation–new features, new integrations, new UI polish.
But anyone who has operated a SaaS product past the euphoric launch week knows where the hours actually go:
- Rotating secrets and patching CVEs at 11pm on a Friday
- Chasing down why the invoice PDF lambda timed out in ap-southeast-2 but not us-east-1
- Fighting Terraform drift after someone clicked through the console “just this once”
- Explaining to a customer why their data export is 48 hours stale because the Celery worker OOM-killed itself
The ratio of build-time to keep-it-running-time was already lopsided. AI just made it more obvious.
Enter the vibe-coded prototype
Large language models have compressed the “zero to working prototype” phase from weeks to hours. Cursor, Copilot, Aider, v0, Bolt – pick your weapon. The scaffolding phase that used to justify a two-pizza team for a quarter now fits in a solo weekend sprint. I have experienced this first-hand: prompting out a FastAPI backend with DynamoDB tables, an SPA frontend, and a deployment pipeline that mostly works. The code is not elegant. It does not need to be. It is structurally correct enough to demo and iterate.
This is genuinely magical. It is also genuinely dangerous, because it creates an illusion of completeness. The prototype works on your laptop, passes the happy path tests the LLM also generated, and looks great in the demo. Then production happens.
Production is where software goes to get serviced
Here is where the mental model needs updating. We are not really selling Software as a Service anymore. We are selling Serviced Software – and the distinction matters.
In the SaaS framing, the software is the product and the service is the delivery mechanism. In the Serviced Software framing, the service is the product and the software is just the substrate it runs on. Customers do not care that your backend is FastAPI or Express or Rails. They care that:
- It is up when they need it (hosting, redundancy, failover)
- Their data is safe (encryption at rest and in transit, access controls, backups that actually restore)
- It stays current (dependency updates, OS patches, framework migrations)
- It costs a predictable amount (no surprise egress bills, no runaway autoscaling)
- Someone answers the phone when it breaks at 3am
None of those are code problems. They are operational problems. And they are the problems that AI is worst at solving, because they require sustained human judgement over months and years, not a one-shot generation pass.
The maintenance asymmetry
There is a well-known asymmetry in software engineering: building version 1.0 is perhaps 20% of the total lifetime cost. The remaining 80% is maintenance, evolution, and eventual decommissioning. AI has dramatically reduced the cost of that first 20%. But it has done almost nothing for the other 80%.
If anything, AI makes the maintenance problem worse. When code is cheap to produce, people produce more of it. More repos, more microservices, more side projects that “just need a small server.” Each one becomes a maintenance liability. Each one needs patching, monitoring, log rotation, certificate renewal, database vacuuming. The open-source maintainer burnout problem I wrote about after PyConAU 2019 is now everyone’s problem, because everyone is now a maintainer of their own vibe-coded fleet.
I keep thinking about the analogy to 3D printing. When desktop printers got cheap, everyone printed trinkets for a month. Then the printers gathered dust because the hard part was never fabrication–it was design, finishing, and material science. The bottleneck moved upstream and downstream simultaneously, leaving the newly-cheap middle step feeling oddly irrelevant.
What “Serviced Software” looks like in practice
If you accept that the value has shifted from code creation to code stewardship, a few things follow:
Platform engineering matters more than feature engineering. Internal developer platforms (Backstage, Port, Humanitec) that abstract away infrastructure and enforce guardrails are more valuable than another AI code assistant. The companies investing in paved roads for deployment, observability, and incident response will win over those investing in faster code generation.
Managed services eat custom code. Every line of custom infrastructure code is a future maintenance burden. I learned this the hard way running microservices from folders on EC2 – cron jobs, plain-text .env files, manual venv management. It worked, but every operational incident was my problem. The appeal of managed Postgres over self-hosted, or Vercel over hand-rolled CI/CD, is not laziness. It is recognizing where your scarce operational attention should go.
Security becomes the primary differentiator. When everyone can generate a working app, the ones that survive are the ones that do not get breached. Supply chain attacks, dependency confusion, credential leaks in AI-generated code that helpfully hardcoded an API key – these are the failure modes of the vibe-coding era. Security is not a feature you bolt on; it is the service layer that justifies the subscription.
Cost modeling is a core engineering skill. I wrote about EKS baseline costs being $70/month for personal projects back in 2020. That sensitivity to operational cost used to be a niche concern. Now that anyone can spin up infrastructure with a prompt, understanding what it costs to keep running is table stakes. Cloud bills are the new technical debt – invisible until they are catastrophic.
Tactical tornados vs strategic maintainers
Every engineering org has its archetypes. The tactical tornado is the superstar feature developer who can bang out a new module in a weekend, leave a trail of impressed stakeholders, and move on to the next shiny thing. They are celebrated in sprint reviews, promoted quickly, and held up as the template for “10x engineers.” Product managers love them because they turn roadmap dreams into demo-able reality at terrifying speed. AI amplifies the tornado: give them Copilot and a weekend and they will generate an entire product surface.
Then Monday arrives. The tornado has moved on to the next feature. Someone else inherits the code–no tests beyond the happy path, no runbooks, secrets in environment variables that nobody documented, an autoscaling policy copied from a blog post that assumed a different traffic shape. The tactical tornado created value in a burst. The strategic maintainer captures it over months.
Strategic maintainers are the people who go deep on the two or three features that actually drive revenue. They understand the edge cases customers hit at 2am. They know which database index is holding the query plan together and what happens when the table crosses 50 million rows. They are the ones who turn a flashy demo into a reliable product–incrementally tightening error handling, adding observability, negotiating with product managers about which “small” feature requests would actually require rewriting the payment flow.
Product managers sit in the middle of this tension. A good PM dreams up the features that will deliver the most value and sequences them so the team can ship without drowning in maintenance debt. A less experienced PM treats every sprint as a feature factory, stacking new work on top of un-serviced foundations, because the roadmap rewards visible output over invisible resilience. In the Serviced Software framing, the PM’s job is not just “what should we build next?” but “what is costing us the most to keep running, and is it worth it?”
The industry has historically rewarded tornados and feature-shipping PMs disproportionately. Promotions go to the person who launched the thing, not the person who kept it alive for three years. AI will sharpen this imbalance unless orgs explicitly revalue the strategic maintainer. When code generation is cheap, the scarce skill is not writing new software–it is understanding existing software deeply enough to keep it healthy.
The human layer
There is a deeper point here that goes beyond tooling. The shift from SaaS to Serviced Software is really a shift from building to caring. Building is exciting, creative, dopamine-rich. Caring is routine, patient, often invisible. Our industry has always undervalued the people who keep the lights on relative to the people who ship new features. AI will widen that gap unless we consciously correct for it.
The sysadmin, the SRE, the on-call engineer, the person who actually reads the CVE advisories and patches before the exploit drops – these roles are becoming more important, not less. The code is becoming commodity. The care is becoming scarce.
Where this goes
I do not think SaaS as a business model disappears. But I think the honest version of what customers are paying for will increasingly sound like: “We run and maintain this software so you do not have to.” That is not a new idea – managed hosting has existed forever. What is new is that the software layer itself is becoming thin enough that the operational layer dominates the value proposition.
We are entering an era where the question is not “can you build it?” but “can you keep it running, secure, updated, and affordable for the next five years?” The answer to that question has never been a one-shot prompt. It is a sustained commitment – and that, for now, remains stubbornly human.
