From Owning the App to Owning the Grammar: The Evolution of Vertical SaaS Platforms

When you build vertical SaaS, there’s a moment that often comes up.

You start with one very concrete context of workflow – store operations in retail, scheduling and billing in a clinic, and compliance in a tightly regulated industry. You find a control point, a place where the work really happens and where data is created, and you build a product around it. Then, as the product matures, you realise the real leverage is not only there. It is in the neighbouring workflows that touch the same customers: procurement, planning, financing, risk, partner management, and so on.

At that point, a deceptively simple question often arises: “Are we building an ecosystem for this use case, or for that one?”

Behind that question, there is a more structural one: how much should you bundle under one product, one brand, one UX – and how much should you deliberately allow to fragment into multiple hubs and (often third-party) applications?

The world of SaaS playbook has become relatively well understood. Tidemark’s recent Vertical Saas Benchmark report is there to tell the story: control points, multi-product expansion, value-chain extension, embedded Fintech, and AI features as default. And it is happening exactly while vibe coding makes it radically easier for people to spin up new product surfaces.

In this environment, understanding “what is our product?” becomes less evident than it used to be. My sense is that we need at least three lenses at once:

• a way to reason about how many hubs to have and how to scope them;
• a way to think about how modular capabilities and APIs provided by an ecosystem of independent players can add to our product;
• and a way to understand how vibe coding affects the balance of power between surfaces and the domain’s underlying grammar.

From a single app to a system of hubs

The canonical story of vertical SaaS still starts in a simple way. You find a control point in an industry – the system a customer would shut down last if everything went wrong – and you build a system of action around it. That usually gives you your first product: a tool that owns a critical workflow and, over time, accumulates what Tidemark calls data gravity and account gravity.

Once you have that, you begin to expand. You add a second product that addresses a neighbouring use case for the same customer. If you are successful, you might eventually extend along the value chain, serving suppliers, partners, employees, and even end-customers.

On a slide, this is a clear progression: one product, then a few more modules neatly arranged, then a suite. But as soon as you go multi-product and expand your original app, you add complexity to the UX. Often, the new “experiences” target the same user, sometimes someone within the same company; however, in practice, you’re often dealing with different roles, rhythms, and mental models, so cognitive load can increase quite quickly.

The design question becomes not only “what do we build next?” but “how many of these hubs should feel like one coherent product – and where is it actually healthier to let things split?”

The question is especially relevant if you work in a portfolio company, with multiple teams operating to target a specific but ample sector.

A simple matrix: cross-fertility versus cognitive load

Whenever you decide whether multiple use cases should live inside the same product or not, two dimensions matter a lot more than all the others.

The first is customer cross-fertilization. How often is it essentially the same account—and often the same internal group of people—that spans these use cases? If you succeed in Store Operations, how easy is it, in reality, to also succeed in Replenishment and Merchandising within the same company? How much growth potential exists in reusing that relationship? If the product features marketplace and network dynamics with third-party apps or third-party inventory, the question becomes even more relevant because you generally want to keep everything together to boost network effects.

The second is cognitive complexity. How far apart are the use cases in terms of the people involved, the time scales, the language, and the metrics they care about? Daily store operations and weekly scheduling are very close; daily operations and annual risk capital planning are very far.

If you imagine a horizontal axis for cross-fertility (low to high) and a vertical axis for cognitive complexity (low to high), you get a simple 2×2 that is surprisingly helpful.

In the bottom-right corner – high cross-fertility and low cognitive complexity – you are in what I’d call the natural suite zone. This is the case where the same people, or a very small, tightly coupled team, use multiple workflows that feel like steps of one bigger job. In a small retail chain, the person who handles shifts, inventory, and in-store promotions might be the same. In this quadrant, it makes sense to behave as a single product: one hub, one UX frame, clear zones or modules inside it. The user’s brain is happy with that level of bundling, and from a business perspective, you get strong expansion and network effects almost “for free”.

If you move up – high cross-fertility but also high cognitive complexity – you arrive in the suite of surfaces territory. Now you still have the same customer spanning multiple use cases, but the work looks very different across roles and time. Think of a big omnichannel brand where store staff, merchandisers, supply chain professionals, and finance each have their own world. Here it is dangerous to pretend that one monolithic application can serve everyone well. The healthier move is to keep a strong platform identity – a single vendor relationship, a single data model, a single set of rails for identity and money – but articulate this into several distinct surfaces: a Store Console, a Merchandising Workbench, a Supply and Vendor Portal, a Finance Console, and so on. UX can diverge; semantics, permissions and cross-hub journeys must remain coherent.

In the bottom-left corner – low cross-fertility and low complexity – you are in the land of product siblings. This is when two products share technology and maybe some domain intuition internally, but not much in the customer base or go-to-market. A tool for small independent shops and a tool for wholesalers might sit here. Each can be a separate product, sometimes even a separate brand. You reuse infrastructure behind the scenes, but there is little reason to present them as “one suite” externally.

Finally, the top-left corner – low cross-fertility and high complexity – is what I think of as the Domain OS territory. Here you are dealing with different products, different customers, quite different kinds of work, that only really share the fact that they belong to the same industry, or domain. A Risk Management system and a an Investment management for the banking industry talk about the same world, but would never be bundled as a suite for a single buyer. In this quadrant, the thing you most want to keep common is not the UX but the domain language and infrastructure: the canonical entities, the events, the compliance models. On top of that, you can host many products, yours and others’, each with its own surface and commercial motion.

From product suite to modular ecosystem

To complicate things you’ve to consider that – in your vertical ecosystem – there is not just you and your customers but rather a network of independent vendors that are modular capabilities. Some industries are more mature and have ecosystems already there; in others, they are emerging and you may be the catalyst to let this happen.

In the most common pattern, a platform aims to build an app store, integrate third parties into its hub, and allow them to operate mostly within its UX. An example is how Shopify embeds apps through its famous “reverse app” framework, maintaining a consistent UX across apps. However, if you succeed in establishing a common language and motivate your third parties to release modular capabilities as APIs, the landscape shifts: while you can provide centralized dashboards and core capabilities, the product X from your ecosystem can call module Y as an API and incorporate the outcome into its own process. Over time, what a customer truly experiences is less “this hub or that hub,” and more a mosaic of interacting products. Some of these products might come from you, others from different providers—all communicating in the same language.

At that point, the role of the “platform” shifts quite radically. You are no longer just the centre of the UX universe that everyone must plug into. You become the custodian of the language that these modules implement. You design and govern the semantic contracts: what an order is, what a shipment is, how a claim moves from state to state, which events exist, and what they mean. You keep a registry of who offers which capabilities in that language, along with documentation that both humans and AIs can understand.

In practice, three patterns of platform enablement appear on top of this:

• You still keep a very visible control tower: a central application where someone can see the full picture, orchestrate work, and monitor status. Many of the actions available in that hub are, in fact, calls to underlying modules provided by you or by partners.
• You behave like a reverse application host. You define a strong UX framework – navigation, layout, design system – and ask partners to adopt it when surfacing their capabilities. Users experience one cohesive product; architecturally, you are assembling pieces contributed by multiple actors.
• You are almost invisible in the UX. You define the domain language, the security and contractual model, and the financial rails. Products from various vendors, including your own teams, speak that language and ride those rails. Customers might never log into “your” app at all, yet every meaningful interaction in the ecosystem flows through your grammar.

If you look back at the matrix through this modular lens, there is a nice alignment. In the “natural suite” quadrant, you will probably combine a strong control tower hub with modules beneath. In the “suite of surfaces” quadrant, you still want a common language and might have several control towers, one per role. In the “product siblings” quadrant, modularisation is mostly an internal efficiency play. In the “Domain OS” quadrant, the language-only ecosystem pattern dominates.

So far we have not said much about AI. But AI, and vibe coding in particular, changes the economics of all this.

What vibe coding does to surfaces and grammar

Vibe coding is a shorthand for a new way of building software: instead of carefully writing and reading code, you describe what you want in natural language to an LLM, get a first cut of code, run it, and iterate by giving feedback. Tools in this area are improving quickly; some are general-purpose, others are industry- or platform-specific.

If you assume that anyone with some technical understanding in your ecosystem – your own team, partners, sophisticated customers – will soon be able to do this, three consequences follow.

First, surfaces become cheap. The marginal cost of creating a small tool, a role-specific dashboard, a bespoke workflow step drops dramatically. You no longer have a single official UX; instead, you have many small surfaces, some operated by you, some by partners, some by customers inside their own systems. The key question shifts to ensuring that all these surfaces behave coherently.

Second, the grammar becomes the moat. When surfaces are easy to generate, what becomes valuable is a clean, expressive, stable domain language that both humans and AIs can reason about – entities, relationships, events, constraints – and a set of rails around it for money, identity, permissions, compliance, obligations. Owning that thin waist, in the middle of a diverse ecosystem of surfaces, becomes strategically more important than owning any single screen.

In other words, vibe coding raises the stakes: it makes exploration at the edge cheaper, while at the same time making convergence in the middle more essential (and harder to control).

What this means if you are building a vertical platform

All of this can sound abstract, but it has quite concrete implications for teams building vertical SaaS now.

When you consider a new product, you cannot just: you need to ask where it sits in the cross-fertility versus cognitive load space relative to what you already have. Furthermore, when you talk about “the platform”, you need to be clear what you mean: are you primarily offering a strong control tower experience that coordinates work and shows the whole picture? Are you aiming to build the gravitas needed to convince everyone to adopt a reverse application framework in which many capabilities can live under one (your) UX? Or are you mainly offering a domain language and Rails, letting others build UIs on top?

It also means you probably want to start modularising capabilities sooner rather than later. Any engine that could realistically be reused across workflows – pricing, routing, underwriting, risk checks, scheduling – is a key candidate to establish a language.

It also means you have to take incentives and governance seriously. You cannot simply decree that partners should expose their capabilities as APIs and fall in love with your domain language. You need to make it economically and operationally attractive: revenue-sharing on reused modules, distribution advantages, easier integration if they adopt your grammar, maybe even technical support and tooling that lowers their costs.

And finally, it means treating vibe coding not as a gimmick but as an inevitability.

Your documentation, schema descriptions, and API designs will increasingly be read by LLMs as much as by humans. The more regular, self-describing and consistent they are, the more likely it is that people can successfully generate and adapt code against them. Guardrails – scopes, rate limits, auditability – become part of your product, not just part of your security checklist.

From owning the app to owning the grammar

Vertical SaaS started life as “an opinionated app for a specific industry” but as you expand into multiple hubs, host other vendors, and operate in a world where anyone can spin up a new surface through AI tooling, the centre of gravity moves.

The matrix of cross-fertility and cognitive load helps you be intentional about how you structure your hubs based on context and ambition. The modular view helps you see that your job is not only to ship features, but to choreograph a network of modules with vibe coding, reminding you that the number of surfaces will explode, whether you plan for it or not.

Underneath all of that sits a quieter question: what is the grammar of this ecosystem, and who has the right (or courage) to steward it?