Software strategy

Six SaaS Models that Shape Modern Software

Horizontal platforms, vertical specialists, ecosystem orchestration, embedded finance and capital roll-ups are not variations of one playbook.

They are different philosophies with different ceilings, risks and sources of leverage.

Horizontal SaaS Vertical SaaS Ecosystem Platforms Embedded Finance Capital Roll-Ups AI-Native Vertical SaaS

Written by Peter Franks

There is no single correct way to build a software company.

Over the past two decades, a range of SaaS business models have emerged, from horizontal platforms to vertical specialists, each optimised for different forms of scale and defensibility.

Both models can produce enduring, highly profitable businesses. They are simply playing different games.

A horizontal SaaS company seeks scale across industries. It abstracts common workflows and builds broadly applicable tools.
A vertical SaaS company, by contrast, embeds itself deeply within a single industry, optimising for regulatory nuance, workflow specificity and domain expertise.

However, ‘horizontal versus vertical’ is only part of the picture. Alongside these two archetypes sit other viable philosophies for building software companies:

The ecosystem orchestrator, which builds a platform others extend
The embedded finance layer, which captures value by inserting itself into financial flows
The capital roll-up, which compounds through disciplined acquisition rather than organic expansion of a single product
The AI-native vertical system, which leverages domain-specific intelligence as its core advantage

Each of these models optimises for a different goal, and each involves different risks and structural ceilings. Building these businesses successfully requires very different leadership profiles depending on the model.

This article does not argue that one philosophy is superior to the others. Instead, it maps the terrain: by examining six distinct approaches, and the companies that exemplify them, it aims to provide a better understanding how value is created, captured and sustained in software markets.

After all, the mistake founders often make is not in choosing the wrong model, but misunderstanding which model they are actually building.

What Is Horizontal SaaS?

A horizontal SaaS company builds software that can be used across many industries. Its products handle common business tasks, such as customer management, accounting, collaboration and marketing, rather than serving the needs of one particular sector.

The goal of horizontal SaaS is scale. Companies using this model aim to create standardised tools that are used by many types of organisations, rather than building industry-specific applications.

The Argument for Horizontal SaaS

The horizontal SaaS model is built on abstraction. Rather than tailoring software to a specific industry, horizontal companies focus on common workflows that exist across many types of organisations.

These workflows include areas such as customer relationship management, communication, productivity and marketing. By identifying shared needs, horizontal SaaS companies build tools that can be applied broadly, regardless of sector.

This approach optimises for scale. By addressing a wide range of customers, horizontal software companies target large addressable markets and aim to become widely adopted standards within their category. Over time, successful products often evolve into platforms, supported by integrations, extensions and partner ecosystems.

The economics reflects this breadth. Horizontal SaaS companies benefit from large distribution potential and the ability to expand within accounts across multiple use cases. Ecosystems further reinforce their position, as third-party developers build on top of the platform, increasing its utility and stickiness.

Horizontal SaaS Example: Salesforce

A clear example of this model is Salesforce. Originally built as a cloud-based CRM, Salesforce focused on a common business function shared across industries. Rather than specialising in a single sector, it expanded horizontally, adding new products and building a broad platform that could be used by organisations of all types and sizes.

The strengths of the horizontal model lie in its scalability and extensibility. Successful horizontal platforms can achieve significant reach, support large ecosystems and expand into adjacent categories over time. In some cases, they become foundational layers within the software stack.

However, this breadth introduces trade-offs. Because the product must serve many industries, it may not fully match the specific workflows of any one sector without configuration or customisation. This can create opportunities for vertical competitors to offer more tailored solutions within particular domains.

As a result, the structural ceiling of horizontal SaaS is defined by its ability to become a standard across industries. The most successful companies achieve platform-level scale, but they must continuously balance generality with usability to maintain their position.

Horizontal SaaS

Example: Salesforce

What it is	Cross-industry software that standardises common workflows and sells to many sectors.
What it optimises for	Breadth, category ownership, and ecosystem expansion.
Core strength	Huge addressable market and compounding value from integrations, partners and platform effects.
Key constraint	Less depth in any single industry’s specialised workflows, compliance and edge cases.

Why Salesforce fits: Salesforce is fundamentally a horizontal CRM platform. Its core product abstracts a broadly shared need (managing customer relationships and revenue pipelines) and applies it across almost every industry, then expands value via a large app ecosystem and adjacent clouds (marketing, service, analytics).

What Is Vertical SaaS?

A vertical SaaS company builds software tailored to the specific workflows, regulatory requirements and operational realities of a single industry.

Rather than abstracting common processes across sectors, vertical SaaS embeds deeply within one domain. The product is often opinionated, pre-configured and aligned with industry norms.

The goal of vertical SaaS is depth rather than breadth. These companies typically trade total addressable market size for higher switching costs, faster time-to-value and stronger domain loyalty.

The Argument for Vertical SaaS

The vertical SaaS model is built on a simple premise: software becomes more valuable when it is closely aligned with the workflows, constraints and regulatory requirements of a particular industry.

Rather than attempting to serve many types of organisation, vertical SaaS companies focus on one domain and seek to become deeply embedded within it. Their products are designed around how that industry actually operates, often incorporating its terminology, compliance requirements and established processes.

This narrow focus can help customers realise value more quickly. Because the software already reflects their needs, it usually requires less configuration and can fit more naturally into existing operations. Over time, it may become closely intertwined with core workflows, making it difficult and costly to replace.

This depth can create strong product-market fit, customer loyalty and a defensible position based on specialist knowledge. In some industries, a vertical SaaS product can become the default system of record. Customers are then less likely to leave because switching would involve not only adopting new software, but also changing established processes. This can support higher retention, stronger pricing power and more predictable revenue.

Vertical SaaS Example: Veeva

A clear example of this model is Veeva Systems. Veeva built its platform specifically for the life sciences industry, focusing on areas such as clinical, regulatory and commercial operations. Rather than adapting a general-purpose CRM or data platform, it developed software aligned with the specific requirements of pharmaceutical and biotech companies. This allowed it to become deeply embedded within its customers’ operations.

The model also has constraints. The addressable market is limited by the size of the industry, and growth may slow once the core market becomes saturated. Expansion into neighbouring sectors can also be difficult because their workflows, regulations and customer needs may be substantially different.

The structural ceiling of vertical SaaS is therefore usually lower than that of a successful horizontal platform. A vertical SaaS company may dominate its chosen market, but its success is generally defined by depth of penetration rather than breadth of reach.

Vertical SaaS

Example: Veeva

What it is	Industry-specific software built around one domain’s workflows, compliance and specialised data.
What it optimises for	Depth, workflow lock-in, and high switching costs within a single sector.
Core strength	Strong retention and pricing power, driven by domain fit, regulatory nuance and embedded operational value.
Key constraint	Market size is capped by the sector, so expansion often depends on adjacent modules or adjacent verticals.

Why Veeva fits: Veeva is a vertical SaaS leader in life sciences. Its products are tailored to highly regulated, industry-specific workflows (commercial, medical and clinical operations), where compliance and domain terminology are not “nice to have” features. That depth makes it sticky, defensible, and hard for general-purpose platforms to replicate without becoming effectively vertical themselves.

For a closer comparison of the two approaches, including their differences in market size, customer acquisition, retention and expansion, see our guide to horizontal and vertical SaaS.

Horizontal vs Vertical SaaS: How the Models Compare

Beyond Vertical and Horizontal

Alongside vertical and horizontal models, other approaches have emerged that optimise for different objectives. Some companies focus on orchestrating ecosystems rather than building all functionality themselves. Others concentrate on monetising financial flows rather than software usage. Some prioritise capital allocation over product expansion. More recently, a new category of AI-native systems has begun to emerge, built around domain-specific intelligence rather than traditional software workflows.

Each approach reflects a distinct strategic philosophy, with its own economic logic, strengths and constraints.

The Ecosystem Orchestrator Model

The ecosystem model is built on orchestration rather than ownership. Instead of developing all functionality internally, these companies create a platform that enables others to build, extend and deliver value on top of it.

At its core, this approach recognises that no single company can innovate across every use case. By opening up the platform to developers, partners and third parties, ecosystem companies allow functionality to expand in a decentralised way.

This model optimises for network effects. As more developers build on the platform, the range of available functionality increases. This, in turn, attracts more customers, which then attracts more developers. Over time, a reinforcing loop can emerge between supply and demand.

The model is driven by aggregation and participation. Rather than capturing all value through direct software sales, ecosystem companies benefit from transaction fees, revenue sharing and increased platform usage. The platform becomes more valuable as more participants engage with it.

Ecosystem Orchestrator Example: Shopify

A clear example of this model is Shopify. While Shopify provides core commerce infrastructure, much of its extended functionality comes from its app ecosystem. Third-party developers build tools for marketing, logistics, payments and analytics, allowing merchants to assemble solutions tailored to their needs. Shopify’s role is to provide the foundation and coordinate the ecosystem.

The strengths of this model lie in its scalability and adaptability. Ecosystems can evolve more quickly than centrally developed products, as innovation is distributed across many contributors. This allows the platform to support a wide range of use cases without needing to build everything itself.

However, the model introduces complexity. Ecosystem governance becomes critical, including decisions around pricing, access, quality control and competition between the platform and its partners. Poorly managed ecosystems can fragment or create tension between participants.

As a result, the structural ceiling of ecosystem companies is tied to their ability to sustain a healthy platform. When successful, they can achieve significant scale and become central coordination layers within their domain. Their advantage is not just the product they build, but the system they enable.

Ecosystem Platforms

Example: Shopify

What it is	A platform that enables other businesses (developers, partners, merchants) to build, extend, and transact on top of it.
What it optimises for	Scale through network effects: more users attract more builders, which creates more value, which attracts more users.
Core strength	Fast innovation at the edge (apps, integrations, partners) without the platform owning every feature itself.
Key constraint	Governance tension: balancing platform control, partner economics, and user trust without killing the ecosystem.

Why Shopify fits: Shopify is not “just” e-commerce software. It is an ecosystem with an app store, themes, agencies, integrations, and an expanding set of platform services. Its value compounds as third parties extend the core product and as merchants standardise on Shopify’s tooling, creating a flywheel that is structurally different from a standalone SaaS product.

The Embedded Financial Layer Model

The embedded finance layer is built on proximity to transactions. Rather than generating value purely through software usage, these companies position themselves within the flow of money.

Instead of charging only subscription fees, they enable payments, lending, insurance or other financial services directly within a product or platform. Revenue is then generated as a function of transaction volume rather than seat count or feature access.

This approach optimises for revenue density. By participating in financial flows, embedded finance companies can capture a small percentage of each transaction. At scale, this often results in higher monetisation per customer than traditional SaaS models.

The economic logic is straightforward. Software can become commoditised over time, but the movement of money remains a high-value layer. By embedding financial services at the point of need, companies reduce friction for users while creating new revenue streams tied to usage rather than adoption alone.

Embedded Financial Layer Example: Stripe

A clear example of this model is Stripe. Stripe provides payments infrastructure that allows businesses to accept and manage transactions online. While it offers software tools and APIs, its primary economic engine is tied to processing payments and taking a percentage of each transaction. As its customers grow, Stripe’s revenue scales alongside them.

The strengths of this model lie in its alignment with customer activity. Revenue grows as customers transact more, creating strong upside in high-volume environments. It also allows companies to monetise beyond subscription pricing, often leading to higher lifetime value per customer.

However, this proximity to financial flows introduces complexity. Companies must navigate regulatory requirements, manage risk and often operate with thinner margins on individual transactions. The model can also be sensitive to broader economic conditions, as transaction volumes fluctuate.

As a result, the structural ceiling of embedded finance companies is tied to the scale of the financial flows they can access and process. Those that become core infrastructure for transactions can achieve significant scale, but their success depends on both technological capability and regulatory execution.

Embedded Finance

Example: Stripe

What it is	A financial layer embedded within software products, capturing value from payments, lending, or transactions rather than just subscriptions.
What it optimises for	Revenue density per user by taking a small percentage of high-volume financial flows.
Core strength	Scales with customer success. As customers grow and transact more, revenue expands automatically.
Key constraint	Exposure to regulation, margin pressure, and dependency on underlying financial infrastructure.

Why Stripe fits: Stripe does not primarily monetise software seats. It monetises payment volume. By embedding itself into the transaction layer of the internet, it captures a small cut of every payment processed. Its APIs make it the default financial infrastructure for modern software businesses, turning payments into a scalable, compounding revenue engine.

The Capital Roll-up Model

The roll-up model is built on capital allocation rather than product innovation. Instead of focusing primarily on developing and expanding a single software product, these companies grow by acquiring and operating a portfolio of existing businesses.

This approach is particularly common in fragmented vertical software markets. Many smaller providers serve specialised industries with loyal customers, recurring revenue and limited routes to large-scale organic growth. A roll-up can acquire these businesses, preserve their niche strengths and compound their cash flows through disciplined ownership and further acquisitions.

Not all vertical SaaS roll-ups follow the same operating model, however. In a decentralised roll-up, acquired companies continue to operate largely independently. Value creation comes principally from disciplined capital allocation, recurring portfolio cash flow and the repeated redeployment of returns, rather than from combining the products into a single system.

An integrated platform-acquisition strategy has a different objective. Here, acquisitions are used to assemble a broader operating platform within a vertical market. The acquired businesses may share infrastructure, data, payments, distribution, customer relationships or product capabilities. This can create greater opportunities for cross-selling and operational leverage, but it also introduces greater integration risk.

A more interventionist version of the same compounding logic can be seen in Bending Spoons, which acquires mature digital businesses and radically restructures the organisations behind them.

Why Bending Spoons Is Rebooting Mature Software Companies

However, acquisition alone create a platform. Buying several software businesses amounts to simple aggregation unless there is a credible source of shared strategic or operating value – whether through infrastructure, distribution, payments, procurement, customer acquisition, data or product integration. Some successful roll-ups deliberately avoid such integration; genuine platform strategies generally depend on it.

Decentralised Model Example

A clear example of the decentralised model is Constellation Software. Constellation has built a large portfolio of vertical-market software companies across numerous industries. Rather than integrating them into a single platform, it operates them as largely independent businesses, focusing on long-term ownership, disciplined capital deployment and the reinvestment of cash flows.

The strengths of this model lie in its resilience and compounding potential. Because many acquired businesses serve niche markets with recurring revenue, the overall portfolio can produce durable and diversified cash flows. Over time, consistent reinvestment can create significant scale without requiring a single breakthrough product.

However, the model introduces its own challenges. Successful execution depends heavily on acquisition discipline, suitable deal flow and responsible stewardship after purchase. Integrated platform strategies carry the additional risk that consolidation may disrupt products, customer relationships or the domain expertise that made the acquired businesses valuable.

The structural ceiling of a roll-up is therefore tied to the depth and fragmentation of its target markets, as well as its ability to continue deploying capital effectively. The ceiling of an integrated platform-acquisition strategy depends additionally on whether the combined businesses create genuine operating value rather than merely greater financial scale.

Capital Roll-Ups

Example: Constellation Software

What it is	A capital allocation strategy that compounds by acquiring many smaller software businesses rather than scaling one product organically.
What it optimises for	Return on invested capital through disciplined acquisitions, strong cash flow, and operational stewardship.
Core strength	Resilience and compounding: diversified cash flows across many niches, with reinvestment into more acquisitions.
Key constraint	Execution complexity: integration discipline, deal flow quality, and avoiding the “growth by acquisition” trap.

Why Constellation Software fits: Constellation is a canonical software roll-up. It buys hundreds of small, mission-critical vertical market software businesses, runs them for cash, and redeploys capital into new acquisitions. The edge is not a single breakthrough product, but a repeatable acquisition process and a culture that preserves niche products while compounding cash flows over decades.

For a fuller examination of these approaches, our guide to vertical SaaS roll-ups compares the main ownership and integration models, sources of value and execution risks.

The Vertical SaaS Roll-Up: Models, Value Creation and Risks

The AI-Native Vertical Model

The AI-native vertical SaaS model is built on domain-specific intelligence. Rather than focusing primarily on workflow software, these companies aim to embed machine learning and language models directly into the core tasks of a particular profession or industry.

While traditional vertical SaaS systems structure and manage workflows, AI-native systems seek to perform or augment those workflows. The product is not just a system of record or coordination, but a system that can generate outputs, analyse information and assist with decision-making.

This approach optimises for intelligence within a defined context. By focusing on a specific domain, these companies can tailor models, data and interfaces to the nuances of that field. Performance is improved not just through general capability, but through alignment with domain-specific language, processes and requirements.

The economic logic reflects this shift. Value is created through time saved, improved outcomes or reduced reliance on manual work. Rather than charging solely for access to software, AI-native systems often capture value based on the impact they have on productivity or output.

AI-Native Vertical SaaS

Example: Harvey

What it is	Vertical software where domain intelligence is the product, using AI to automate expert work rather than digitise workflows.
What it optimises for	Outcome improvement: speed, quality, and cost reduction on high-value domain tasks.
Core strength	Step-change productivity when AI is trained, tuned, and integrated around domain-specific constraints and data.
Key constraint	Model dependency and defensibility: differentiation can erode if others access similar models and data.

Why Harvey fits: Harvey is built for a specific profession, not a general audience. It targets legal workflows and outputs, where accuracy, citation, and domain conventions matter. The “software” is not just a workflow wrapper around a generic model. The moat comes from domain tuning, product integration, and usage-driven feedback loops that make the system increasingly useful in the narrow context it is designed for.

The AI-Native Vertical Example: Harvey

A clear example of this model is Harvey. Harvey applies AI to legal workflows, assisting with tasks such as document analysis, drafting and research. By focusing specifically on the legal domain, it is able to tailor its capabilities to the needs of lawyers, rather than offering a general-purpose AI tool.

The strengths of this model lie in its potential to reshape how work is performed within a domain. By combining software interfaces with domain-specific intelligence, these systems can go beyond coordination and begin to automate or augment core tasks. This creates the possibility of significant efficiency gains and new forms of product value.

However, the model also faces important constraints. Many AI capabilities are built on underlying foundation models that are improving rapidly and becoming more accessible. This raises the risk of commoditisation at the model level. Differentiation must therefore come from domain expertise, proprietary data, workflow integration and user experience rather than raw model capability alone.

As a result, the structural ceiling of AI-native vertical systems is still evolving. The most successful companies are likely to be those that combine deep domain understanding with strong product execution, creating systems that are not easily replaced by general-purpose tools.

Comparison of SaaS philosophies

Philosophy	Example	Core goal	Strength	Key constraint
Horizontal SaaS	Salesforce	Cross-industry scale	Large TAM, ecosystem expansion	Limited depth in specific workflows
Vertical SaaS	Veeva	Industry dominance	Retention, pricing power, workflow lock-in	Market size capped by sector
Ecosystem Platforms	Shopify	Platform coordination	Network effects, external innovation	Governance and partner conflict
Embedded Finance Layer	Stripe	Monetise transactions	High revenue per customer	Regulation and margin pressure
Capital Roll-Up	Constellation	Capital compounding	Predictable cash flows, disciplined M&A	Execution risk across acquisitions
AI-Native Vertical SaaS	Harvey	Domain intelligence	Automation of core workflows	Model commoditisation risk

Conclusion

There is no single correct way to build a software company. The mistake is to treat these models as interchangeable – or to drift between them without understanding the consequences.

A vertical SaaS company that attempts to become horizontal too early may lose the specialist advantage that made it valuable. A platform that over-integrates may weaken its ecosystem. An AI product without proprietary data, workflow integration or distribution may remain little more than a layer over increasingly commoditised models.

For founders, the central question is therefore not which model is “best”, but which model they are actually building. That choice shapes product design, go-to-market strategy, hiring, capital allocation and long-term positioning.

For investors and operators, these distinctions help explain why apparently similar software businesses can produce very different growth rates, margins, retention and outcomes.

The SaaS landscape is unlikely to converge on a single playbook. The companies most likely to succeed will be those that understand which game they are playing and execute it with consistency and discipline.

Peter Franks

Founder & Editor, No Latency

Peter writes long-form analysis on technology, gaming and artificial intelligence – focusing on the systems, incentives and strategic decisions shaping the modern software economy.

He has spent 20+ years working with software and games companies across Europe, advising founders, executives and investors on leadership and organisational design. He is also the founder of Neon River, a specialist executive search firm.

Connect on LinkedIn

Built by No Latency

Play Paradigm

A scenario game where you become a software company owner and navigate the choices around adopting AI.

Play the game