Inverting SaaS / ideas on the future of business applications and AI at work

This is a follow up to my comments on SaaS fatigue. I'm sharing ideas, but I don't assume I have all the answers! If you’re interested in these topics send me a note.

So, how did we get to here...?

In the very early days of software there weren't a lot of over-the-counter options to choose from. If you wanted something, you built it or hired someone to build it. In the 90s this began to change rapidly. More people learned to code, software development became easier and faster, and distribution improved (from disks to CDs to downloads, app stores, and SaaS). Investment poured in and software exploded.

For the next 20 years companies raced to create the first, and then the best applications for every line of business and operational workflow. As everything migrated 'to the cloud', business software moved to a subscription model (Software-as-a-Service, or SaaS for short), making it even more accessible. Fast forward to today, and there are 17,000 SaaS companies creating products for everything. The average organization subscribes to 29 SaaS applications after its first year of operations, and grows from there to 118 in a few years. Companies in the U.S. alone spend $150 billion per year on SaaS.?

In 2015, my team and I were no exception to this rule. We ‘spun up’ our business with a dozen out-of-the-box SaaS products, and over time we added dozens more. It was fast and efficient, but as we grew we noticed some major downsides. For example:

1. Every application has its own data silo: Each application has its own data silo, which makes it harder to analyze the business, understand how different functions impact each other, and make data-driven decisions.
2. Application workflows exist in silos: Features live within one application, and connecting them requires custom integrations or a lot of manual data migration.
3. Applications don’t evolve with our needs: Most SaaS apps are mass produced, one-size-fits-most, but their users each have unique needs that change over time.
4. Context switching is distracting and slows you down: Each app has its own style and navigation, and as a virtual destination on your computer. You have to learn each one, and jumping around makes you more susceptible to distractions and procrastination.
5. It gets expensive: Each SaaS company has a similar cost structure to support their one product. Also, we had to pay for teams and software to manage all of the vendors and manage how our employees onboarded into and off boarded from the apps.
6. Our brand and culture were nowhere to be found: Building company culture is hard, and using 3rd party SaaS made this harder.? Our company values, terminology, quirks, and acronyms weren’t included. Our employee experience became a wall of Okta apps, a stark contrast from homegrown internal tools at Amazon that carried the culture. For example, we used Gusto for HR. It worked great, but each payday when they announced it to our employees, our company name wasn't included in the email.

At the time there was no good alternative. It was too expensive and slow to build our own custom software. Now, with AI lowering the cost and time to develop software, while at the same time introducing entirely new ways of doing work, things are changing.

Today, the average company subscribes to 100+ SaaS applications produced by as many different companies. What if instead of this, the SaaS model was inverted ? Instead of one company subscribing to many apps from many developers, one developer built a full suite of business applications for each of its customers. The applications would be built on a unified application platform and data model. This would remove data silos and unlock workflows across formerly disparate applications.

Until recently the idea of one company producing dozens of performant, best-in-class SaaS applications across many domains would have been hard to imagine. However, with existing applications serving as blueprints of what to build, the primitives of applications being easier to create and reuse, and AI coding tools making software development much, much faster, it is no longer daunting. We already have powerhouses like Microsoft, and startups like Zoho and Rippling well down this path today.

This model would solve many of the problems listed above.

Think about how you use the web. If you want to find something specific, you don’t open every website and look around until you find it…you go to Google, OpenAI, or another service that has already scoured and indexed the web. You tell them what you want, and they bring you answers or tell you exactly where to look. Business applications can work the same way. Instead of visiting each application individually to get something done, AI will be aware of all of your applications and data, and surface the features, forms, tools, etc., to you on-demand, when you need them to complete a task. Instead of going into each app to do work, AI can bring the functionality of each app to you.

Imagine a central, AI-powered work hub that could do this for you. By operating above individual app silos, it could even generate new features or workflows on-the-fly, not yet built into the standalone applications. It would be super useful. However, it would be completely limited by the number of applications and databases that it can access.

Because of this, the largest business application companies with the most scope will be in the best position to build this and gain momentum first. If they do so, and their customers love it, then their customers will want it to work for all of their apps. This will pressure the independent, standalone application providers they use to go down one of three paths: try to become one of the leading AI work hubs (partnerships), integrate into the leading work hubs, becoming more ‘headless' over time, or be sidelined or replaced. Most will have to open up and integrate with the larger application platforms if they want to remain relevant.

Stepping back, traditional software applications were designed so that people could visually navigate them. I.e. people click through an application's menus, navigating to a specific page or feature in the app to do something, such as filling out a form, updating a status, reading content, sending a message, reviewing visual charts, uploading data, etc. This human-led approach to working in apps will still be the best way to get some things done, but it will become less relevant over time as AI becomes more capable and our role in work evolves. Agents will use natural language to take and receive instructions, produce relevant content for any task, and generate the needed UI or workflow on-demand, in-line when a human-in-the-loop is needed to complete a task. In this way, agents will work for us, bring a concise, organized version of our work to us, instead of us having to jump around and find the place to get work done within each application.

(note: I don't think that these ideas apply to all types of applications people use for work. For example, a spreadsheet will likely remain a standalone app for a long time)

MORE ON WHAT AI-POWERED WORK HUBS COULD LOOK LIKE

Components

1. A user-facing portal that is the AI work hub, with full integrations into every relevant application and database
2. Personalized chat agent and work co-pilot for every employee
3. Generative UI/workflow capable of creating temporary applications, forms, tools, etc., on-demand for a given task
4. Configurable platform for IT teams to manage this across employees
5. Access to leading AI models

Paths to get there

A. Build it over an existing suite of 1st Party Applications

• Companies like Microsoft, Rippling, Zoho, or Salesforce can build an AI co-pilot or workflow layer on top of their existing suite of applications. Forms of this area already happening.
• Other companies that lack a broad suite might acquire more applications or rapidly develop complementary ones, leveraging today’s easier/cheaper/faster software development.

B. Forge an independent alliance of apps

• An independent, neutral work hub could emerge that integrates with any application that wants to remain relevant and continue to have a seat at the table.

C. Develop Agents That Navigate Existing UIs

• Similar to current bots and scrapers, these agents would interact with any application, without the need for integrations or programatic access.
• I think that this is unlikely to work well in the enterprise space due to the higher overhead to maintain connections, as well as latency and reliability issues

D. Enterprise-Specific Custom Hubs

• Some large companies, like Amazon, might build their own bespoke hubs to integrate their internal systems with third-party apps, giving their employees a unified workspace
• Although challenging due to coordination demands, this approach may serve large organizations initially, with aggregators eventually easing integration.