Software as an Operation (SaaO)

Notes on a category that doesn’t have a name yet

By Danilo Naranjo Emparanza

There’s a question I’ve been unable to shake for months, and I think it defines the exact moment the software industry finds itself in: if AI can build any software in hours, why does it still take months to have software actually running in production?

This is not rhetorical. It’s literal.

In 2025 we crossed a threshold without much fanfare. Anthropic’s Claude Code, OpenAI’s Codex, Cursor, Lovable, Bolt, v0, Replit Agent, GitHub Copilot Workspace. Each one, in its own way, demonstrated that code generation stopped being a novelty and became infrastructure. Today, a developer with Claude Code writes complex systems in hours that used to take weeks. Codex executes engineering tasks autonomously. Lovable turns a description into a deployed application in minutes.

And yet, as I write this, the dental clinic down the street still manages its appointments in a paper notebook. The restaurant around the corner still takes orders by phone. The independent accountant still tracks invoices in Excel. The neighborhood gym still uses a printed sign-up sheet.

These aren’t people who haven’t heard of software. These are people who looked at the available options and reached a reasonable conclusion: getting custom software running is still too expensive, too complex, and too fragile for their reality.

Something doesn’t add up. The industry is celebrating technical capabilities that, in the real world, haven’t changed the lives of the vast majority of businesses that need them. It’s worth pausing to ask why.

The hole nobody names

When you look carefully at what the available tools actually solve, an uncomfortable pattern emerges.

Claude Code and Codex are extraordinary. But they were designed for developers. They assume there’s someone on the other end who understands what a repository is, how to configure environments, how to read errors, how to make architectural decisions. They are tools to amplify professionals, not to replace them.

Lovable, Bolt, and v0 lowered the bar significantly. Someone without deep technical knowledge can describe what they want and see something working in minutes. In fact, today we see designers, product managers, non-technical founders, and even occasional curious users launching products with these tools. Some of those products become real businesses, and it’s worth acknowledging that honestly.

But when you look at who is succeeding with this model, a pattern emerges: they’re people with high digital fluency, building something for themselves or for a niche they know intimately, and willing to keep operating the tool when something breaks. It’s a real profile, and a valuable one, but it isn’t representative of the vast majority of businesses that need software. The dental clinic owner isn’t going to learn Lovable. Not because they aren’t capable, but because the cognitive effort of doing so is greater than the value they perceive.

There’s a deeper observation here. The non-developers who succeed with these tools generally build prototypes, MVPs, personal projects, or micro-SaaS where they themselves are the primary user. Very rarely do they build systems that other businesses operate critically. Because when software actually matters (when your patients depend on it working, when your invoicing flows through it, when a bug costs real money) the responsibility of operating it becomes intolerable without someone reliable on the other side.

Vercel and Replit go further. They offer hosting, observability, Git integration, preview environments. But they remain platforms for developers to build and deploy, not services for businesses to operate. A dentist won’t open Vercel. They don’t know what a deployment is. They shouldn’t have to.

What none of these tools resolve, and what actually matters, is everything that happens after the software is live.

Where does the data live? Who manages the database? How do users authenticate? What happens when someone can’t log in at eleven o’clock on a Sunday night? Who updates dependencies when a vulnerability is published? Who renews the SSL certificate? What about backups? What if the service goes down during peak business hours? What about regulatory compliance? Who integrates the payment gateway? Who connects it to WhatsApp? Who monitors performance? Who fixes the bug that only shows up when two users try to book the same slot at the same time?

The code was the easy part. The operation is where the value lives, and where every existing solution abandons the customer.

Let me put numbers to this. I’ve spent eighteen years building software products for enterprises across Latin America, and I’ve observed a consistent pattern: the initial development of a software product accounts for, on average, twenty to thirty percent of its total lifetime cost. The remaining seventy to eighty percent is operation, maintenance, evolution, and support.

AI has just disrupted the twenty percent. Nobody has touched the remaining eighty.

An observation about the stack

The cloud computing industry organized itself, over two decades, into progressively higher layers of abstraction. Each one absorbed a layer of complexity that previously fell on the customer.

IaaS (Infrastructure as a Service) said: you don’t need to buy servers. Rent compute.

PaaS (Platform as a Service) said: you don’t need to manage servers. Just deploy code.

FaaS (Function as a Service) said: you don’t even need to think about servers. Write functions, we’ll run them.

SaaS (Software as a Service) said: you don’t need to build software. Use ours.

There’s something odd about that list, and it deserves attention. Each layer absorbs complexity, but none, not even SaaS, which is sold as the end of the chain, fully frees the customer from making technical decisions.

IaaS requires configuring virtual machines. PaaS requires writing and deploying code. FaaS requires writing functions and managing event triggers. SaaS requires adapting your business to someone else’s product, configuring it, learning it, compromising with its limitations, living within its assumptions about how a business that isn’t yours should work.

The progression stopped halfway. There’s a logical layer missing, and its absence explains why so many businesses remain without access to the software they actually need.

That missing layer is one where the customer does nothing technical. Where the software is built to their specifications, deployed, operated, maintained, updated, secured, and evolved. And the customer, simply, uses it.

Not code delivery. Not platform access. Not a subscription to a generic tool.

Software delivered as an operation.

SaaO, Software as an Operation.

The definition, carefully

Before going further, it’s worth being precise.

Software as an Operation (SaaO): A delivery model where custom software is built, deployed, operated, maintained, secured, and evolved on behalf of the customer. Who interacts only with the running product, never with the code, infrastructure, or development process.

The distinction from existing models isn’t of degree. It’s of nature.

Model What the customer gets What the customer must do IaaS Virtual machines Everything above the hardware PaaS Runtime environment Write, deploy, and maintain code FaaS Function execution Write functions, design triggers SaaS Generic application Adapt business to the tool SaaO Custom application, running Use it

It’s worth thinking about it this way: SaaO is to SaaS what SaaS was to on-premise software. SaaS said: you don’t need to run software. SaaO says: you don’t need to settle for someone else’s software, either.

“But aren’t Claude Code, Codex, Lovable, and Vercel already doing this?”

This is the honest question that deserves an honest answer, because it’s the one any informed person will ask, and the answer matters.

Yes, the tools are getting closer. Anthropic’s Claude Code is probably the most powerful AI-assisted software construction tool that exists today. OpenAI’s Codex allows engineering tasks to be executed autonomously. Lovable and Bolt generate web applications in minutes. Vercel, with v0 and Open Agents, has the most complete infrastructure for orchestrating agents that build and deploy. Replit integrates everything into a single environment with hosting included.

Each one of these tools is impressive. And yet, none of them is SaaO. The differences are worth examining carefully, because they explain why the category exists and why it’s inevitable.

The first difference is the audience.

Claude Code and Codex were designed for developers. They are productivity multipliers for people who already know how to build software. Lovable, Bolt, and v0 lowered the bar and let a wider universe of people (designers, product managers, sophisticated non-technical founders) build functional things. That’s real, and it’s valuable.

But there’s a distinction worth making. These tools work well when the user is building something for themselves, knows the domain deeply, has digital fluency, and is willing to invest time in learning the tool. They work less well when what’s needed is for a business owner without that preparation to obtain software that other people will operate, in production, for years. An independent lawyer who needs a case-tracking system can technically use Lovable. In practice, they don’t know what to ask for, don’t know what to do when something breaks, don’t know how to evolve it when their business changes. The tool presupposes a kind of preparation the end user doesn’t have.

SaaO assumes no technical knowledge and no willingness to operate the tool. The entry channel is a phone call, a WhatsApp message, a natural conversation in the customer’s language. The “prompt” in SaaO isn’t text, it’s a human conversation. And what’s delivered isn’t a tool for the customer to use, but a service that operates on their behalf.

The second difference is the temporal scope.

This is the most important point, and it’s the one the industry systematically overlooks.

Claude Code, Codex, Lovable, and every similar platform are, in essence, tools for construction. Some (like Vercel and Replit) extend their scope into deployment. But none of them, today, takes responsibility for operating the software over time.

Deployment is an event. Operation is a continuous service.

That distinction sounds semantic, but it defines an entire industry. The moment an application starts running in production is also the moment when the real obligations of software begin to accumulate: monitoring, security updates, data backup, incident response, feature evolution, user support, regulatory compliance. All the things that decide whether the software is still useful a year from now or has become abandoned technical debt.

Code generation platforms end their work exactly where the real work begins. The customer is left standing in front of their newborn software, not knowing what to do with it. The usual solution today is to hire a developer to maintain it, which brings the problem back to square one.

SaaO takes on that responsibility. It doesn’t deliver code. It delivers a service that includes the software, its continuous operation, and its evolution over time. The customer pays a monthly fee, and the software, like a silent and reliable employee, simply works.

The third difference, and the deepest one, is governance.

This one deserves more time, because it’s where the industry is about to make a significant mistake.

The accountability nobody is building

There’s a question almost nobody asks in conversations about generative AI for code, and it’s the one that weighs most in the long run: if AI agents build and operate software autonomously, who is responsible when it fails?

Software will fail. Not because AI is bad at writing code, in fact, it gets better every year, but because software is intrinsically complex. Business rules have edge cases. Integrations break. Environments change. Regulations evolve. Attackers find new vectors.

When a human team builds software, accountability flows naturally through people. The developer who wrote the code, the reviewer who approved it, the product manager who prioritized the feature, the security engineer who reviewed the pipeline. There’s a chain of decisions that can be examined, understood, and corrected. There are names, roles, signatures. There is responsibility.

When AI agents build and operate software autonomously, that chain doesn’t exist by default. Without a deliberate design that builds it, what you get is a black box: the software appeared, it works, and nobody can explain with certainty how the decisions that led to it were made.

For a coffee shop managing reservations, this may seem abstract. For a clinic handling health data, a bank processing transactions, an insurer evaluating risk, or any company touching sensitive personal data, it is plainly a dealbreaker. And as regulators catch up with AI (the EU AI Act is already in force, NIST is actively developing frameworks for autonomous agents), it will become a legal requirement for everyone.

SaaO without governance is a legal liability waiting to materialize. SaaO with governance is something different: it’s a new standard.

What does governance look like in an SaaO model? Every AI agent that participates in building or operating the software has a verifiable cryptographic identity. Every significant action is preceded by an explicit declaration of intent. Every step (from requirement capture to the last deployment) is recorded in an immutable, cryptographically sealed audit chain. The customer doesn’t just receive working software; they receive a Software Passport: a verifiable, independently auditable record of how their software was conceived, designed, built, tested, secured, and deployed.

I’ve been building this governance layer since October 2025 as an open-source protocol called DCP-AI (Digital Citizenship Protocol for AI Agents). It defines the trust infrastructure that autonomous agents need to operate in environments where accountability matters: identity binding with human responsibility, intent declaration, cryptographically sealed audit chains, and standards for agent-to-agent communication. The specs are published, the SDKs exist in five languages, and the protocol was submitted in response to NIST CAISI’s Request for Information (Docket NIST-2025–0035) and to the NCCoE Concept Paper on AI agent identity. There’s still ground to cover before frameworks like this are formally recognized, but the debate is open, and it’s the right debate.

But the point here isn’t my specific protocol. The point is that any SaaO provider that doesn’t build governance into the foundation is building on sand. And those who do will have a structural advantage that’s nearly impossible to replicate later, because governance is an architectural decision, not a feature you add in a later iteration.

This is, at bottom, the most relevant difference between SaaO and the platforms I mentioned. Claude Code, Codex, Lovable, Vercel, Replit, all of them can add autonomous operation in a quarter of engineering. They can add blueprints. They can add non-technical channels. They can, with enough will, move toward the SaaO model. But adding governance to an existing pipeline requires redesigning it almost completely. Whoever starts with governance from day one will have a structural advantage when regulators, and enterprise customers, require it. And they will.

Blueprints: the ingredient that makes the model viable

There’s one last component that deserves attention, because it’s what separates a good concept from a viable business model.

Generating software from scratch every time, even with the best AI tools, has a fundamental problem: it’s slow, it’s expensive, and it’s fragile. Every project faces the same problems that have been solved a thousand times before (authentication, roles, permissions, error handling, forms, notifications, reports) and solves them, with varying degrees of fortune, from scratch again.

The alternative, which turns SaaO into a real business rather than just an elegant idea, is blueprints. These aren’t generic templates. They are complete applications, production-tested, refined through hundreds of real deployments, cryptographically audited, and parameterizable.

When a customer needs a scheduling system, no new one is generated. A blueprint that was already tested with fifty other clinics is taken, customized (brand, integrations, business rules) and deployed. The difference in speed and reliability compared to “generate from scratch” is enormous.

The obvious parallel is Shopify. Shopify doesn’t generate a new e-commerce engine for each merchant. It provides a proven engine, extraordinarily refined, and lets each merchant make it their own. SaaO applies the same logic, but instead of a single vertical, it covers any vertical where there’s enough demand to justify a blueprint. And the customization, in SaaO, is done by AI agents, not humans.

This introduces an interesting tension with the imagery of “AI can build anything.” In theory, it can. In practice, the value isn’t in building from scratch, it’s in the accumulated institutional knowledge of what works, encoded into blueprints that agents customize.

In other words: the future value isn’t in generated code, but in the library of proven code that gets generated once and reused infinitely.

A note on which market this is for

Before going further, an important distinction is worth making, because without it the argument risks being misread.

SaaO is not meant to replace custom software for large enterprises. Large companies, those operating banking, retail, telecommunications, healthcare at scale, manufacturing, insurance, have requirements that generic blueprints don’t cover and probably never will: complex integrations with dozens of legacy systems, regulatory compliance across multiple jurisdictions, transaction volumes that require architecture designed specifically, internal teams that need to collaborate closely with the provider, long-term contractual relationships with strict SLAs, third-party audits, contractual liabilities that an automated model can hardly assume.

Enterprise custom software will continue requiring, for a long time, experienced human teams, tailored architecture, and trust relationships built over years. There, the value isn’t in the speed of construction but in the depth of understanding of the business, the ability to sustain complex commitments, and the accumulation of context that is only gained by working for years with the same organization. That value isn’t being automated in the near future, and shouldn’t be.

SaaO targets a different market: the one made up of businesses that never had access to custom software because the cost structure and the complexity of the relationship made it impossible. The dental clinic that books a few hundred consultations per month. The independent accountant with thirty clients. The family-run restaurant. The neighborhood fitness center. The four-person consulting firm. The independent professional who today runs their business on spreadsheets.

This market is enormous in count, millions of businesses in any developed or developing economy, but each one has a modest monthly spending capacity. Developing custom software for each of them through traditional means was never viable. The combination of AI agents that build from blueprints, autonomous infrastructure, and operational economies of scale makes it viable, for the first time, to offer them genuinely custom software at prices comparable to SaaS.

The relevant metric isn’t “how much does it cost to build” but “how much does it cost, per unit, to build and continuously operate a custom product.” In the traditional model, that figure was prohibitive for the small-and-medium-business segment. In the SaaO model, with autonomous agents building from proven blueprints and operating at scale, the figure enters a range that a small business can reasonably pay monthly.

The addressable market for SaaO, then, is not the current enterprise custom software market. It’s the enormous silent majority of small and medium businesses that have always needed it and never had it.

Two categories, two markets, two distinct logics. Not one competing with the other. It’s a new layer of the market becoming visible for the first time.

What SaaO is not

It’s worth spending a few lines establishing boundaries, because new categories run the risk of dilution if everything can fit inside them.

SaaO is not no-code or low-code. Those platforms give users building blocks and ask them to assemble them. In SaaO, the user never sees a builder; they receive the assembled and operating product.

SaaO is not managed hosting. Hosting provides infrastructure to run the code you have. SaaO provides the code, the infrastructure, and the ongoing management of both.

SaaO is not AI code generation. Generation tools deliver files. SaaO delivers a service that includes the software running, maintained, and evolving over time.

SaaO is not white-label SaaS. White-label allows rebranding someone else’s fixed product. Each SaaO instance is a custom product that can evolve independently from the others.

SaaO is not outsourcing. Outsourcing moves work to cheaper humans. SaaO moves work to governed autonomous agents with auditability and scalability that no human team can match.

Each of these distinctions matters, because each existing category has its own business logic, its own economics, and its own limitations. SaaO is not a marginal improvement of any of them. It’s a fundamentally different value proposition.

Where the value moves

There’s a broader implication, and it’s worth thinking about calmly, because it touches everyone who works in the software industry.

For four decades, value in software has been in building: knowing how to write code, how to design architecture, how to get a product to production. Companies hired developers. Developers accumulated leverage. The structural bottleneck was talent.

If SaaO becomes the dominant model for standard business software, and I believe it will, within a five-to-ten year horizon, value moves to three different places.

First, to blueprints. The accumulated knowledge of what works, refined through hundreds of real deployments in a vertical. A company that has spent eighteen years building systems for clinics knows things about edge cases, user behavior, and integration patterns that no AI will discover from first principles. That institutional knowledge, encoded into blueprints, becomes a reusable asset and the structural competitive advantage.

Second, to operations. Running thousands of custom applications reliably, securely, and affordably is an engineering problem of a different nature than building individual applications. It’s infrastructure, but at a higher level of abstraction: not “how do I configure a load balancer,” but “how do I detect and resolve a problem across a heterogeneous fleet of applications before the customer notices.”

Third, to governance. In a world where AI agents build and operate software without line-by-line human oversight, the ability to demonstrate that the software is secure, auditable, and accountable stops being an optional technical feature. It becomes a market requirement, a condition for operating in certain industries, and eventually, a legal condition.

Code becomes a commodity. Trust becomes the product.

This shift has consequences worth thinking about carefully, because they aren’t uniform. For mission-critical enterprise software, the kind specialized consultancies build for banks, retailers, and healthcare at scale, generative AI is an internal productivity tool, not a disruption of the model. The client-provider relationship still rests on trust, accumulated context, and contractual responsibilities that an agent doesn’t assume. If anything, AI allows these teams to be more efficient, deliver faster, and focus on the genuinely complex problems.

For generic SaaS software, however, the challenge is subtler. Its historical moat was operational (“we run the software so you don’t have to”), but if AI can build and operate custom software at SaaS prices, the product’s generality shifts, in certain segments, from being an advantage to being a limitation. This doesn’t mean SaaS disappears, many will continue winning where standardization is a virtue, as in personal productivity or collaboration. But the most vulnerable segment is niche SaaS that today charges commodity prices for covering only a fraction of its customers’ real needs.

None of these transitions will happen overnight. But they are underway, and it’s worth seeing them clearly.

An invitation

I’m not writing this to announce a product. I’m writing it because I believe a structural shift is taking place in how software is delivered, and it still doesn’t have a name.

The pieces exist today. AI agents can build production-grade software. Cloud infrastructure can operate it autonomously. Governance protocols can make it accountable. The economics work. The demand is massive and largely unserved.

What’s missing is the assembly, the company or companies that integrate these components into a coherent offering and deliver them to the millions of businesses that have been waiting for years.

I’ve already started. My company has spent eighteen years building custom digital products for large clients across Latin America, and it will continue doing so, because that work, with the depth it requires, doesn’t get automated. In parallel, we’re building the layer that makes SaaO possible: an autonomous factory for the segment that has historically been left out of custom software. The governance layer, DCP-AI, is open source, because accountability infrastructure for AI agents shouldn’t be proprietary, just as TCP/IP shouldn’t have been.

But SaaO is bigger than one company, one protocol, or one market. It’s the logical conclusion of the trajectory the entire industry is already on. Someone will build it. Many will build it. The relevant question isn’t whether it will happen, but how. Whether it’s built with governance from the foundation, or whether governance is bolted on as a patch when regulators force it. Whether it’s built with the non-technical customer in mind from day one, or whether someone tries to retrofit a developer platform to serve a market that was never its audience.

I prefer, humbly, for the industry to get this right from the start.

The “as a Service” stack:

IaaS → Infrastructure as a Service
PaaS → Platform as a Service  
FaaS → Function as a Service
SaaS → Software as a Service
SaaO  → Software as an Operation ← you are here

The hole in the stack has a name now.

Danilo Naranjo Emparanza, Founder Ocular — Wingsoft — 9House Foundation. Creator of DCP-AI, the Digital Citizenship Protocol for AI Agents, an open-source governance protocol for autonomous AI agents (Apache-2.0, dcp-ai.org).