Horizontal tools, vertical UIs

I came of age building web apps in Angular. I learned to think of apps as a combination of models (data), views (UIs), and controllers (logic) — the MVC framework. Though Angular is long dead, I still like this framework for thinking about all SaaS apps in general.

All SaaS apps are a set of horizontal capabilities (data + logic) accessed via predefined views (UIs). That last bit — predefined views — is becoming more customized to each user. Users will increasingly interface with SaaS apps via vertical UIs: custom UIs created on the fly for specific use cases. 

This trend changes the design and economics of SaaS businesses.

If you've ever used modern spreadsheet-adjacent tools like Coda or Notion, you're already familiar with vertical UIs. When you switch between a Kanban View, a List-Detail View, or a Timeline View for some data, you switch between various vertical UIs that better fit your use case.

In Coda, you are limited to a predefined number of views: Kanban, List-Detail, Timeline, etc. A team of developers predefines the types of views you can access. The idea of vertical UIs extends this pattern to any kind of view. This is now possible with LLMs.

The recent Google Gemini launch video showed a good example.

Here, we see a user asking for party theme ideas. Gemini responds with a List-Detail view created on the fly. You can imagine more examples. A travel query returns a map view. A programming query returns a live code editor. Gemini, and LLMs like it, are great at inferring intent and responding with code. This is the unlock that makes vertical UIs possible.

We can extend this pattern to all SaaS apps. In this world, your SaaS provider gives you a set of baseline primitives: views, workflows, calculations, automations. You then extend the app with any vertical UI that fits your use case better.

There is, of course, a natural limit to customizability. When you pay for a SaaS tool, you pay for common workflows and best practices embodied in features and UIs. You're not paying for the privilege of writing your own piece of software.

Vertical UIs work best for apps with a heavy lift to build core features and a long tail of features you must support. These apps tend to be enterprise apps where adding a new feature involves adding a new button and yet another way to interact with some underlying data. Think of your classic ERP software vendor.

Vertical UIs change how we think about product development. If end users can define bespoke UIs, product orgs don't have to be feature factories, and users don't have to perform UI archeology to figure out how to make bloated apps work for them.

The impact on SaaS economics is twofold.  First, on the cost side, R&D spending that would have gone to building button after button is eliminated. Second, on distribution, intelligently designed enterprise apps don't have to get into a button war with incumbents before unlocking enterprise customers with intimidating RFP lists.

That said, new paradigms present new problems.

I've assumed in this post that a new feature is synonymous with a new button or view. This assumption is an intentional simplification. There is a ceiling of complexity to end-user programmed features. Back to the original Angular framework, custom UIs can only be defined on the fly if they depend on data types or logic primitives already supported on the server. For example, if you have a list of location coordinates in Notion, you can't natively visualize these in a map view because there is no concept of coordinates as a first-class primitive.

Finally, custom UIs introduce new challenges to supporting and maintaining software. How do you debug or QA an app where the end-user defines their UI? How do you standardize customer support when a user may be talking about a vertical UI that a customer support rep has never seen?

There’s been a lot of talk about how LLMs impact programming for software engineers. The next wave is how they impact programming for end-users. 

Alan Kay spotted this trend in 1984:

"What is needed are ways to build applications that first, do useful things for the user; second, surreptitiously teach the user deeper ideas about how the application is structured, and third, let the user "open the hood" and have a high probability of success at doing customizations that the applications programmers didn't specifically anticipate."

- Opening the Hood of a Word Processor 

In 2024, we are finally getting closer to this vision.