Sitemap

The Extinction Event: Why SaaS is Already Dead (It Just Doesn’t Know It Yet)

20 min readMar 19, 2025

I inverted the URL.**

For thirty years, the web has worked the same way. You click a URL, a page loads, and then you navigate through an interface to get anything done. You fill in forms, click submit buttons, wait for confirmation pages, and maybe see a success message at the end. Every URL on the internet points at a visualization of a function — a pretty interface wrapped around what is actually just a simple database operation.

But I had a different question: what if the URL just pointed directly at the function itself?

On the traditional web, when you want to create a record in Airtable, you visit their website, wait for the page to load, navigate to the right table, fill in a form, and click submit. You are interacting with an interface that eventually triggers a function on their server. But the interface is not doing the work. It is just the middleman between you and the actual operation.

I realized you could skip all of that. Instead of pointing a URL at a page that shows you a form that eventually calls a function, you could point the URL directly at the function. The outcome is identical, but you have eliminated every step in between. That is not AI. That is not automation. That is just removing unnecessary layers. And once you see it, you start to realize the entire web might be backwards.

We built all these visual interfaces because humans could not express their intent to computers any other way. But if AI can translate natural language into function calls, then the visualization layer becomes overhead. And that is exactly what SaaS companies are charging you for — the privilege of clicking through interfaces to access functions that were always available directly.

This is the story of how I figured that out, and what I built to prove it works.

It Started With Garbage Trucks

I had been writing essays for my nephew for years. They were meant to be a collection of life lessons and stories I wanted to give him when he turned eighteen. I kept them all in Mem.ai, tagged and organized, waiting for the right moment to compile them into something meaningful.

But when his second birthday approached, I had a different idea. He was obsessed with garbage trucks. Not just interested — obsessed. The kind of obsession where a two-year-old will stop mid-sentence to point at a trash truck driving by and lose his mind with excitement. So I decided to use AI to transform those essays into a three-part boxed set of children’s books about garbage trucks. Age-appropriate stories with the same underlying lessons, just wrapped in a world he actually cared about.

Writing the stories was straightforward. AI handled that easily. Generating image prompts from the stories was simple enough. Creating the images themselves worked fine. But then came the logistics. I had roughly one hundred eighty files spread across six folders for what should have been a twenty-page children’s book.

  • One tool to write the stories.
  • Another tool to create the image prompts.
  • Another to generate the images.
  • Text bubbles for each page created separately.
  • Everything living in different places, none of it connected, all of it requiring manual file management and constant context switching.

The result was beautiful. My nephew’s face lit up when he saw it. He literally shouted “That’s medriving the truck!” We nailed it. The image generator was good enough that it looked just like him. It was perfect. But it did not make sense that this should take so long or be this chaotic.

So after I finished, I asked GPT to help me debrief the workflow. I explained the chaos — files everywhere, manual routing between tools, constant copy-pasting, zero integration. It suggested the concept of a “command center” that could coordinate everything. That was the origin of what eventually became OrchestrateOS. I was not trying to build an operating system. I was trying to make garbage truck books and podcast covers more efficiently.

Each revelation led to the next. Local execution came from working around Ideogram’s remix endpoint, which required files to be on disk. I asked GPT if it could execute a script on my computer the same way it called an API. That led to Flask, which led to routing, which led to realizing I could point everything at localhost and skip the interfaces entirely. The months that followed were just more of the same pattern: “What else can I make possible?” Until it became what you have seen.

But it all started because managing image files for a children’s book should not have been that hard. And once I saw the pattern — that every tool was just routing data but none of them talked to each other — I could not unsee it.

Every SaaS tool you use — Notion, Asana, Trello, Salesforce, Airtable — is doing the exact same four things: Create, Read, Update, and Delete. That’s it. They just hide it behind interfaces, dashboards, and workflows to make you think it’s more sophisticated than it actually is.

Create

When you create a task in Asana, type a note in Notion, or upload a file to Dropbox, you’re not actually “doing work” in any meaningful sense. You’re just adding a row to a database. It feels like a workspace because they’ve designed it that way, but underneath the polish, it’s just a fancy input form writing to storage.

Read

When you read data — refreshing your Trello board, searching for an old Slack message, checking a Google Doc — you’re just querying stored information. The interface makes it seem like you’re “navigating” or “exploring,” but you’re really just asking a database to return some records. You don’t need a UI to find things. The friction of clicking through menus and tabs is something SaaS companies built into your workflow on purpose.

Update

When you update something — changing a due date in ClickUp, renaming a folder in Box, modifying a customer record in Salesforce — you’re not working. You’re overwriting a database entry. The UI makes this feel important, but it’s the same operation you’d run in two seconds with a direct command.

Delete

And when you delete something — archiving an email in Gmail, removing a contact from HubSpot, clearing a record from Monday.com — you’re just erasing a row from a database. The interface adds confirmation dialogs and undo buttons to make it feel significant, but the underlying action is instantaneous and simple.

Here’s what that means: SaaS isn’t software. It’s just an interface charging you rent to access your own data. And if you stop paying, they lock you out. Your own knowledge, your own records, your own work — all held hostage behind a monthly subscription.

But I didn’t see this clearly until I started trying to solve my own problems. The garbage truck project forced me to look at how these tools actually worked. And once I started paying attention, I couldn’t stop seeing the pattern everywhere.

The first time it clicked was with a podcast transcript processing tool. I was paying sixty dollars a month for it. You upload a transcript, it spits out a newsletter draft, some social media posts, and an episode description — all formatted nicely in their interface. It felt like magic until I started building OrchestrateOS and needed to understand how APIs actually worked.

I looked at the OpenAI Playground to see what was happening under the hood. That’s when I realized: these guys were just sending a request to a chat completion endpoint. The entire product was a prompt and a pretty UI wrapper. Sixty dollars a month for what amounted to an API call I could make myself for pennies.

Todoist

Then I looked at Todoist. I had been using their free tier and kept running into the task limit. I didn’t want to pay for an upgrade, so I thought: what if I just built my own task manager? I started sketching it out and realized a task is just fields and values. A title, a due date, a status, maybe a priority level. That’s all JSON. I could store that in a file and read it back whenever I needed it. So I built a simple script — task.py — and suddenly I didn’t need Todoist anymore. It did everything I needed without a subscription.

That’s when I started looking at other tools differently.

Gmail

Gmail was next. I was drowning in email and kept thinking about how much metadata Gmail’s interface forces you to deal with. Thread IDs, label structures, nested folders, HTML formatting, encoding types — forty-seven fields of metadata when all I actually needed were three things: who sent it, what it’s about, and the message itself.

So I built nylas_inbox.py, a script that strips out everything except those three fields, auto-tags emails based on whether they need a reply, and stores it all in a simple JSON file. No interface. No folders. Just a fifty-kilobyte file with everything I need.

Airtable

I had been using it to track some project data and got curious about how it actually worked. I opened an export file and saw that every “base” was just JSON. Every “record” was an object with fields. Every “relation” was a reference to another object’s ID. I was paying them to store rows in a database and give me a spreadsheet interface to interact with it. But if the data was already structured as JSON, I could just use json_manager.py — a universal tool for reading and writing JSON files — and do the exact same thing for free.

Calendly

Calendly was the last straw. I had applied to Y Combinator with an early version of OrchestrateOS and got rejected. Fine. Whatever. But one of YC’s biggest success stories was a Calendly competitor that raised millions and went through their program.

After the rejection, I decided to see if I could build my own Calendly replacement. It took one afternoon and fifty lines of Python. The script checked my calendar for availability, let someone book a time slot, created the event, and sent a confirmation. That’s the entire product that YC helped raise millions for. I didn’t need their network, their advice, or their funding. I just needed Nylas’s API documentation.

And here’s what should keep YC partners up at night: this isn’t unique to Calendly.

Go look at your own portfolio companies’ API documentation right now. Airtable literally publishes the JSON structure for every operation. Notion documents their entire data model. Asana, Trello, Monday.com — they all publish the exact structure of their data because developers need it to build integrations.

You’re funding companies that publish the blueprint for their own obsolescence.

Every productivity tool in your portfolio is a UI wrapper around CRUD operations. The APIs to perform those operations directly are freely available, documented by the companies themselves. The only reason users pay for the UI is because they don’t know they can skip it.

But here’s the problem: AI just taught them how to skip it.

The pattern is now undeniable. Email clients, task managers, spreadsheets, scheduling tools, note-taking apps — they’re all just interfaces charging rent to access freely available APIs. And the moment enterprise CFOs realize they’re paying millions for UI access to APIs that cost pennies to call directly, seventy percent of your productivity SaaS portfolio loses its entire value proposition overnight.

This isn’t speculation. This is math. And every word of it is verifiable by looking at the API documentation your portfolio companies publish themselves.

SaaS was never about efficiency. It was about control. It exists to trap you in a cycle of subscriptions, forcing you to pay for tools that do nothing but present your own data back to you in a slightly prettier format than a spreadsheet.

1. SaaS Doesn’t Do the Work — It Makes You Do It

Project management tools don’t manage projects. CRMs don’t manage customer relationships. Productivity apps don’t make you productive. You do all of that. SaaS just gives you a place to click buttons while convincing you that activity equals output.

Defenders of SaaS will tell you that the UI makes software “easier for non-technical people.” But that’s exactly the con these companies use to justify their pricing. In reality, most businesses don’t need ninety percent of the UI. They just need workflows to execute. Google Drive is a glorified file browser. Trello is a to-do list with columns. Airtable is a database with a prettier frontend. You don’t need an interface to store and retrieve files. The entire premise of SaaS is built on making you feel like the UI is necessary when it’s really just a middleman between you and your own work.

2. SaaS Is Just a Middleman Between You and Your Data

Every SaaS product functions as a toll booth between you and what you already own. You enter data into their system, you pay every month to access it, you manually update and retrieve it, and if you ever stop paying, they take it away. Enterprise SaaS is the worst offender. Companies pay millions per year for tools like Salesforce that do nothing except act as a middleman between users and a database. The value isn’t the software. It’s the fact that you’ve been trained to think you need their interface to access your own business data. When companies realize that execution doesn’t require an interface, the entire SaaS industry collapses.

3. SaaS Tricks You Into Feeling Productive

SaaS tools aren’t built for execution. They’re built for engagement. Slack keeps you in notification loops. Task managers make you feel accomplished just by organizing to-dos. Analytics tools drown you in dashboards instead of giving you insights. The illusion of productivity keeps you locked in. This is why people think APIs are “too complicated” for the average user. The truth is that APIs are only difficult because SaaS companies keep them that way. The reality is that businesses don’t need endless dashboards and UI-based workflows. They need execution. The moment companies break free from SaaS interfaces, they realize they don’t need the tool at all.

4. SaaS Is Built to Keep You Clicking, Not Completing Work

Every UI is optimized for one thing: keeping you inside the tool as long as possible. Airtable makes you build tables manually. Monday.com forces you to update statuses instead of executing tasks. Notion makes you organize endlessly. The longer you spend inside the software, the more valuable you think it is. SaaS companies justify this with the usual arguments about security, support, and updates. But let’s be honest. Support is nonexistent unless you’re paying six figures. Most SaaS support is just a chatbot running scripted responses, and if you’re lucky, you’ll get an email back in three to five business days. Security means trusting a SaaS company with your entire data stack, which is a mistake. And updates? The only thing SaaS companies reliably update is their pricing model.

5. SaaS Makes You Dependent on Subscriptions for Basic Functions

If you cancel your subscription today, your task lists vanish, your files get locked, and your automations break. SaaS isn’t built to empower you. It’s built to keep you dependent. When people push back on this, they usually say something like “well, self-hosting is a pain.” But why is that? Because SaaS companies have spent the last decade making sure that running software yourself is artificially difficult. The question you should be asking is simple: would you rather pay ten thousand dollars a year for a UI that wraps an API, or just run the API itself? This is the final weakness of SaaS. The moment users realize they don’t need the UI, the entire model collapses.

But Wait — What About AI-Powered SaaS?

Surely tools that use AI are different, right? They must be doing something more sophisticated than just CRUD operations on a database.

No. They’re the same scam with one extra step.

Take Readwise Reader. They have a “Chat with your highlights” feature that sounds magical. What’s it actually doing? It queries your highlights from their database, sends them to OpenAI along with your question, and displays the response in their interface. That’s it. Four lines of code wrapped in a subscription fee. Notion AI works the same way. Query your documents, send the content to OpenAI, display the response. Superhuman AI? Query your emails, send them to OpenAI, display the response. Gamma AI? Send your outline to OpenAI, get back formatted slides.

Every “AI-powered” SaaS tool follows the same pattern. They have your data because you gave it to them. They send it to OpenAI, which you could do yourself. Then they charge you for removing the copy-paste step. That’s not AI-native. That’s a wrapper with ChatGPT bolted on. And you’re paying fifty dollars a month for what should cost you nothing.

The Proof: 4,769 Executions

You might be thinking: okay, but does this actually work at scale? Fair question. Here is the answer.

I have been running OrchestrateOS in production for five months. This is not a side project or a demo. This is the infrastructure for running an actual company. In that time, the system has executed 4,769 tasks with a 97% success rate. That is not theory or a pitch deck. That is real work getting done without opening a browser.

Here is the breakdown:

  • json_manager: 2,242 executions (replaces spreadsheets, Airtable, database UIs)
  • terminal_tool: 678 executions (handles file operations and scripts)
  • outline_editor: 404 executions (manages documents via API)
  • podcast_manager: 239 executions (production workflows for real episodes)

Every single one of those executions would have required opening a SaaS tool, clicking through a UI, manually entering data, and waiting for confirmation. The average execution time is 503 milliseconds. That means from intent to completion takes half a second, with no page loads, no navigation menus, and no form submissions.

Let’s do the math on what that actually means. If each of those tasks took two minutes to complete through a traditional SaaS interface — and two minutes is conservative when you factor in opening browsers, logging in, navigating to the right section, entering data, and confirming — that adds up to 159 hours of work that did not require any human interaction. At a billing rate of one hundred dollars per hour, that represents nearly sixteen thousand dollars in recovered productivity.

And that does not even count the subscription costs I eliminated:

  • Todoist Premium: $4/month
  • Airtable: $20/month
  • Calendly: $10/month
  • Email tools and task managers: $15/month combined

That is roughly $365 in subscriptions I canceled over five months because I replaced them with direct API access.

But here is what matters more than the money. We are managing an actual fundraise with this system.

  • Investor CRM data lives in json_manager.
  • Cold email campaigns run through email_list_tool.
  • Meeting scheduling happens through nylas_calendar.
  • Podcast production workflows execute through podcast_manager.
  • Document creation and editing flow through outline_editor.

Every workflow that used to require opening multiple tools and manually copying data between them now just executes automatically. You state the intent, the system executes it, and the work is done.

This is not a demo. This is not a vision of the future. This is how we work right now, today, with no browser tabs, no context switching, and no clicking through interfaces.

User Interface Was Never the Goal — It Was a Workaround

User interfaces did not exist because they were the best way to interact with computers. They existed because there was no other way.

In the earliest days of computing, there were no screens, no windows, no icons. Users had to manually feed punched cards or flip switches to input commands. The first command-line interfaces were introduced to remove the need for physical hardware inputs, but they were still rigid and difficult to use. You had to learn machine syntax. You had to memorize commands. You had to think like a computer.

The Graphical User Interface emerged in the 1970s at Xerox PARC and was later popularized by Apple and Microsoft. It was a breakthrough, but not because it was the best possible way to use a computer. It was simply an easier way to issue commands manually. Instead of typing arcane syntax, you could point and click. Instead of memorizing file paths, you could see folders and icons. The GUI was not the destination. It was a compromise.

Computing pioneers like Douglas Engelbart and Alan Kay never saw the GUI as the final form of human-computer interaction. They viewed it as a stepping stone toward something more natural. The real goal was always to remove the need for a UI altogether, so that computers could understand users directly without requiring clicks, menus, and input fields. But the technology was not there yet. Natural language processing did not exist. AI could not translate intent into commands. So we built visual interfaces as a bridge between human thought and machine execution.

That bridge became the foundation of the modern web. Every website, every app, every SaaS tool is built on the assumption that humans need to see what they are doing. We need buttons to click, forms to fill out, confirmation pages to reassure us that something happened. The entire internet is designed around the idea that execution requires visualization.

But that assumption is no longer true. AI can now translate natural language into function calls. You can state what you want in plain English, and the system can figure out which API to call, which parameters to pass, and how to handle the response. The visualization layer is no longer necessary for execution. It has become pure overhead.

This is not about making software “easier” or “more intuitive.” This is about recognizing that the UI was always a workaround for a limitation that no longer exists. We built interfaces because humans could not speak machine language and machines could not understand human language. Now they can. Which means the entire premise of the modern web — that you need to visualize commands before executing them — is obsolete.

The UI Is Dead — AI Is the Interface

For decades, we thought work meant managing software. We believed that progress required dashboards, updates, and endless clicking. But that illusion is collapsing.

Execution does not wait for buttons. It does not pause for manual input. It just happens. SaaS companies built their entire business model on keeping users inside interfaces, but execution-first AI removes the need for UI-driven workflows entirely. Instead of navigating screens, users simply state what needs to happen, and it gets done.

We are already seeing this transition across industries. In finance, more than eighty percent of stock trades are executed by algorithms with no human clicking buttons. In customer service, AI chatbots resolve the majority of requests without anyone opening a dashboard. In enterprise workflows, AI-driven systems generate reports, process data, and manage IT infrastructure without manual intervention.

Companies that still rely on UI-based SaaS tools are falling behind. The ones that embrace execution-first infrastructure are moving faster, operating leaner, and eliminating entire categories of overhead. The world is not waiting for this shift to happen gradually. It is already happening. And SaaS companies do not want you to realize it, because the moment you do, their entire value proposition disappears.

The Post-Web Interface: Language-Native Execution

The web was Phase 1 of human-computer interaction. We built visual interfaces because humans could not express intent in machine language, and machines could not understand human language. The GUI was the compromise that made computing accessible to everyone.

But we are now in Phase 2. AI can translate natural language into function calls. Which means the compromise is no longer necessary. We do not need to visualize commands before executing them. We can just state what we want and let the system handle the rest.

This is not about making APIs easier to use. This is about redesigning them to be language-native instead of GUI-native. Most APIs were designed for graphical interfaces. They require you to know internal IDs, pass parameters in specific formats, and call multiple functions in sequence because that is how the UI works. But if you are designing for language instead of clicks, you can collapse that complexity.

Take Airtable. Their API requires you to pass a base ID and a table ID — ugly strings like “appAbc123” and “tblDef456” — because that is how their database works internally. But humans do not think in UUIDs. We think in names. So in OrchestrateOS, I added alias resolution. You just say “Marketing base” and the system looks up the ID for you. Same outcome, zero cognitive overhead.

Or Outline. Their API needs a collection ID to create a document. But instead of making you look up that ID, I built hashtag routing. You just type your content and add “#Resources” at the end, and the system routes it to the right collection automatically. Language-native design means the interface disappears. You just state the outcome you want.

ConvertKit is another example. Their API has two separate functions: create a broadcast and schedule a broadcast. Why? Because that is how their UI works. You create a draft first, then you schedule it later. But that is GUI friction. Why would you recreate that in the API layer? So I combined them into one function. You call create_newsletter with optional scheduling parameters. If you pass a send time, it schedules. If you do not, it saves as a draft. One function, one outcome, zero unnecessary steps.

This is not workflow automation. This is outcome orchestration. Workflow automation tries to replicate the steps a human would take in a UI. Outcome orchestration asks what the actual goal is and executes it directly. The difference matters because one forces you to think like a GUI, and the other lets you think like a human.

Right now, I’m using ChatGPT’s Custom Actions as the interface layer. OpenAI built Custom Actions so developers could connect GPTs to external APIs. I pointed mine at a local server running on my machine. From their perspective, it’s just another developer using Custom Actions the way they were designed. But what’s actually happening is that every command routes to local tools that execute without ever hitting OpenAI’s chat completion endpoint.

The system is model-agnostic by design. We have Claude integration built. We’re adding local LLM support. The interface layer doesn’t matter because the execution happens locally. That’s the point. The LLM is just the router — a way to translate natural language into function calls. Whether that router is GPT, Claude, or a local model running on my machine makes no difference to the outcome.

This is not a demo. This is not a prototype. This is production infrastructure that has been running for five months, executing thousands of tasks, managing real workflows, and proving that the visualization layer is obsolete. The web was built for humans who needed to see what they were doing. The post-web is built for humans who just need things to get done.

Stop Paying Rent

We wrote, researched, revised, and prepared this article without relying on a single SaaS workflow. No task managers. No note-taking apps. No social scheduling tools. No document editors. No project management dashboards. Everything you just read was produced through direct execution — natural language commands routed to APIs, with zero interface overhead.

This is not magic. This is just what happens when you stop paying for unnecessary visualization layers and start executing directly. Every SaaS tool you use is just a UI that lets you Create, Read, Update, and Delete data. That is all they do. They convinced you that managing a UI was necessary, but if AI can interact with data directly, you do not need the UI at all.

For decades, businesses assumed they needed software to track projects, document ideas, and manage workflows. But SaaS never solved those problems. It just created new interfaces for them and charged you rent to use them. Execution-first infrastructure removes the interface entirely. It eliminates the friction. It just executes.

Here is what that looks like in practice:

  • You do not open tools — you issue commands
  • You do not organize tasks — you get tasks done
  • You do not manage data — your system retrieves it and acts on it
  • You do not wait for progress — you see results instantly

This is not some distant future. This is already happening.

What is OrchestrateOS?

OrchestrateOS is a natural language operating system that transforms text into real actions across your tools. It connects to any external API — from Notion and Dropbox to Gmail and Outline — and automatically integrates every tool with every other one.

That means you can:

  • Create documents and move files with simple commands
  • Send messages and chain entire workflows together
  • Move data between apps using just plain language
  • Execute full multi-step workflows without opening a browser

There are no usage fees, no token limits, and no hidden API calls, because everything runs locally on your machine.

The data speaks for itself:

  • Five months in production
  • 4,769 executions with 97% success rate
  • $16,000 in recovered productivity
  • Zero SaaS subscriptions

This is not a demo. This is how we work.The UI layer is dead. The question is whether you want to keep paying for it anyway.

🚀 Click here to join the private beta

--

--

Srinivas Rao
Srinivas Rao

Written by Srinivas Rao

Candidate Conversations with Insanely Interesting People: Listen to the @Unmistakable Creative podcast in iTunes http://apple.co/1GfkvkP

Responses (144)