AI Agents > Humans will be primary user of our Tools

There has been infrastructure as SaaS for two decades. Think AWS, Snowflake, Datadog, Heroku, Databricks, Confluent, Stripe, Twilio, Crowdstrike, and more. These tools were built for engineers, extremely fast performance, or very large-scale datasets.

‍

There are also SaaS applications. Think Salesforce, Hubspot, ServiceNow, Workday, Okta, and more. These tools were built for non-engineers.

‍

Some of the above SaaS applications have evolved into infrastructure and AI won’t affect their role in the future as much — for instance, Salesforce is more like Snowflake than it is like Monday.com.

‍

AI is commoditizing, neutering, and sometimes killing thinner SaaS applications that are more workflow than infrastructure.

‍

What AI is not doing is killing software. Software is going to explode in value because of AI — if you turn your SaaS application into infrastructure. 

‍

The CEO of Intercom just did this last week when they released the Fin API. ElevenLabs is “SaaS as infrastructure,” whereas Decagon and Sierra are SaaS.

‍

Hence, AI will force winning SaaS companies into infrastructure.

‍

How SaaS as infrastructure will be different from traditional SaaS

‍

SaaS apps are built with the expectation that a human is the primary user. SaaS as Infrastructure is built for an AI primary user.

‍

When AI is the primary user, there are two implications:

‍

1. The intensity at which AI wants to use a tool is infinitely higher in volume and scale than a human. To meet those demands, you need to build a product that looks more like infrastructure. Software needs to support a button clicked 1000 times per second (AI speed) versus 1 time every 30 seconds (Human speed), as a crude example.
2. Data requirements to make AI useful go up — you need to get world-class at the concept of Context Intelligence. Context Intelligence is a data-infrastructure problem that requires ingesting arbitrary datasets, modeling them in custom ways, and coordinating compute resources to execute arbitrary data jobs.

‍

How SaaS as Infrastructure will be different from infrastructure as SaaS:

‍

Infrastructure as SaaS is built for technical folks. SaaS as infrastructure will be built for non-technical folks, and AI is a critical enabler to give non-engineers the superpowers of engineers. 

‍

I think Replit and Claude Code are two of the best examples of this type of company today. A non-technical user can execute a wide range of large and small tasks. They have built tools, frameworks, and infrastructure where AI is the primary user of “clicking buttons” and the human is expressing intent. 

‍

If you’re unclear on what I mean by tools, frameworks, and infrastructure, I talk about it more in It’s not the Model, it’s the Tools + Environment. You can also ask Claude Chat or Claude Code, “what tools do you have at your disposal?”, and it will give you a list. But it’s the tools, frameworks, and infrastructure that make the human user receive a fast output they can trust.

‍

At Rippit, we’ve been preparing for this future since 2023. We didn’t know it would play out exactly like this, but we knew right when ChatGPT came out that our original product was going to get massively commoditized, and we needed to chase harder technical problems.  

‍

A little bit of foresight and a little bit of luck creates the Rippit opportunity.

‍

Note: This concept is still being refined, but it is a directional set of statements. Please share ideas to push the thinking and refine the logic.

When you use Claude Code, you see the same model (ex. Opus 4.6) is used across Claude Code, Claude Cowork, and Claude Chat. Then why does it perform differently? The tools and environment.

‍

Think of the model as the brain and the tools as the arms, hands, legs, and feet.

‍

Claude Code has many coding-specific tools. 

‍

What you need for your task will require specific tools, environments, and optimizations too.

‍

Designing the best tools and environments is going to be the name of the game.

‍

For example, if you want to build an analytics system, you connect Claude to Snowflake. In that case, Snowflake is the tool. Snowflake is the hard part of the problem and 99% of companies don’t have the engineers to build products as technically difficult as Snowflake.

‍

This has become more obvious since the code behind Claude was leaked the other week and people studied it - but it’s not obvious to the regular person blown away by Claude Code and “Vibe Coding”. When you experience a crazy, mind-blowing output, it's hard to separate the 'AI' from the tools and systems doing the mission-critical heavy lifting.

‍

The world of Tool Design is going to go through a lot of trial, iteration, and realization — we have our differentiated POV but the playbook is being written.

Traditional business application software from 2000-2022 (e.g. software sold into HR, Sales, Marketing, etc.) has been primarily workflow automation tools — Salesforce started with SFA (Salesforce Automation), ServiceNow started with IT Workflow Automation, and Workday is HR workflow automation. 

‍

The core value proposition was coordinating large groups of people around a process.

‍

When you wanted to do complex data analysis — crunch lots of numbers, combine data from different data sources, etc. — you would push that data into a data warehouse (Teradata in the 2000s, later replaced by Snowflake) and layer it with a BI solution (like Tableau or, more recently, Sigma/Looker).

‍

SaaS apps that lived in the world of Security and Infrastructure were more likely data/infra apps from the beginning — companies like Rubrik, Crowdstrike, and Datadog fit this mold.

‍

The type of engineers and cultures you attract to build workflow apps versus data apps is materially different.

‍

AI requires a higher percentage of SaaS apps to become data apps. 

‍

99% of apps will die in this process because they have to build a fundamentally different engineering culture. Only 1% will survive.

‍

Rippit realized this three years ago and embarked on this journey — partly through our instinct of how SaaS needed to transform, and partly through a little bit of luck. 

‍

This also transforms my role, and I’m going through my own journey of survival. As a non-engineer, being the founder of a workflow app is significantly less technical and more S&M-oriented than being the founder of a data app. 

‍

My Monday morning meeting used to be the Go-To-Market kickoff and now it’s the Engineering kickoff. I’m working very hard to become as effective as I can at lower levels of product decisions — my ceiling here directly affects Rippit’s ceiling.