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.

Over the past two decades, the SaaS industry has produced companies that look superficially similar. They share subscription models, recurring revenue and cloud delivery. Yet beneath the surface they are built on fundamentally different architectural philosophies. Some aim for cross-industry dominance. Others pursue depth within a single sector. Some orchestrate ecosystems. Others monetise financial flows. A few focus less on product innovation and more on capital allocation.

When discussions arise around vertical versus horizontal SaaS, the debate is often simplified to niche versus broad. In reality, that distinction captures only one axis of a much larger landscape.

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. Both models can produce enduring, highly profitable businesses. They are simply playing different games.

And 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
The AI-native vertical system, which leverages domain-specific intelligence as its core advantage

Each of these models optimises for a different goal. Each carries different risks. Each has a different structural ceiling. 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, we can better understand how value is created, captured and sustained in software markets.

The mistake founders often make is not choosing the wrong model. It is misunderstanding which model they are actually building.

What Is Horizontal SaaS?

A horizontal SaaS company builds software designed to serve multiple industries. Its products abstract common workflows such as customer relationship management, accounting, collaboration or marketing automation, and apply them broadly across sectors.

The goal of horizontal SaaS is scale. By targeting a large addressable market, these companies aim to become standardised tools across many types of organisations. Their strength lies in breadth of applicability and ecosystem expansion rather than industry-specific depth.

Examples include companies like Salesforce in CRM or Microsoft in productivity software.

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.

Examples include Veeva Systems in life sciences or Procore in construction.

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.

Beyond Vertical and Horizontal

The distinction between vertical and horizontal SaaS captures an important divide in how software companies are built. It highlights the trade-off between depth and scale, and between specialisation and standardisation.

However, this distinction alone does not fully describe the landscape.

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.

These approaches are not variations of a single model. They represent distinct philosophies, each with its own economic logic, strengths and constraints.

The Vertical SaaS Thesis

The vertical SaaS model is built on a simple premise. Software becomes more valuable when it is deeply aligned with the workflows, constraints and regulatory realities of a specific industry.

Rather than attempting to serve many types of organisations, vertical software companies focus on one domain and seek to become embedded within it. The product is designed around how that industry actually operates, often incorporating its terminology, compliance requirements and established processes.

This approach optimises for depth. By focusing narrowly, vertical SaaS companies can deliver faster time-to-value, reduce the need for configuration and align more closely with customer needs. Over time, this creates strong switching costs, as the software becomes intertwined with core operational workflows.

The economics follows from this depth. Customers are less likely to churn because replacing the system would require not just adopting new software, but reworking established processes. This often results in higher retention, stronger pricing power and more predictable revenue over time.

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 strengths of the vertical model are clear. It enables a high degree of product-market fit within a defined segment, supports strong customer loyalty and can create defensible positions through domain expertise. In many cases, vertical SaaS companies become the default system of record within their industry.

However, these advantages come with constraints. The total addressable market is inherently limited by the size of the industry. Growth can slow once the core market is saturated, and expansion into adjacent sectors is often difficult due to differences in workflows and requirements.

As a result, the structural ceiling of vertical SaaS is typically bounded. These companies can achieve dominance within a specific domain, but they rarely expand into broad, cross-industry platforms. Their success is defined by depth of penetration rather than breadth of reach.

The Horizontal SaaS Thesis

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.

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.

The Ecosystem Orchestrator Thesis

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.

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 Thesis

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.

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.

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

This approach typically targets fragmented markets, often within vertical software. Many smaller companies serve niche industries with stable customer bases but limited scale. The roll-up strategy is to acquire these businesses, maintain their operations and improve performance through disciplined management.

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 Thesis

This model optimises for capital efficiency. By acquiring profitable or cash-generative businesses, capital roll-up companies can compound returns over time. Growth comes from a combination of acquisition, operational discipline and reinvestment of cash flows rather than organic expansion alone.

The economic logic is rooted in fragmentation and predictability. Vertical software markets often consist of many independent providers with loyal customer bases and recurring revenue. These characteristics make them suitable for consolidation. By aggregating multiple such businesses, roll-up companies can build large portfolios of stable, cash-generating assets.

A clear example of this model is Constellation Software. Constellation has built a large portfolio of vertical market software companies across a wide range of industries. Rather than integrating them into a single platform, it operates them as a collection of largely independent businesses, focusing on long-term value creation and disciplined capital deployment.

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 be stable and predictable. Over time, consistent reinvestment can lead to significant scale without the need for breakthrough product innovation.

However, the model introduces its own challenges. Successful execution depends heavily on disciplined capital allocation and the ability to identify suitable acquisition targets. Integration decisions must be carefully managed, as excessive consolidation can erode the strengths of individual businesses. The availability of attractive targets can also diminish over time as markets consolidate.

As a result, the structural ceiling of roll-up companies is tied to the depth and fragmentation of the markets they operate in, as well as their ability to continue deploying capital effectively. When executed well, the model can produce sustained long-term growth, but it relies more on financial discipline than product-led expansion.

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.

The AI-Native Vertical Thesis

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.

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.

What the SaaS industry has demonstrated over the past two decades is not convergence, but divergence. Multiple models have emerged, each optimised for a different source of value creation. Horizontal platforms scale through breadth and standardisation. Vertical SaaS companies win through depth and domain expertise. Ecosystem players coordinate networks. Embedded finance businesses monetise transactions. Roll-ups compound capital. AI-native systems attempt to redefine how work itself is performed.

These are not variations of the same strategy. They are fundamentally different approaches, with different operating models, risk profiles and structural ceilings.

A horizontal SaaS company can achieve enormous scale, but may struggle to penetrate deeply into specific workflows. A vertical SaaS company can dominate a sector, but its market is inherently bounded. Ecosystem platforms can grow exponentially through network effects, but face constant governance tension. Embedded finance businesses can generate exceptional revenue per customer, but operate under regulatory and margin pressure. Roll-ups can produce highly predictable outcomes, but depend heavily on acquisition discipline. AI-native systems offer the promise of step-change productivity, but are still searching for durable defensibility.

Each model is coherent. Each works on its own terms.

The mistake is to treat them as interchangeable, or to drift between them without clarity. Many companies begin with one philosophy and unintentionally evolve into another, creating strategic confusion. A vertical SaaS company that attempts to become horizontal too early may lose its edge. A platform that over-integrates can undermine its ecosystem. An AI product without proprietary data risks becoming a thin wrapper over commoditised models.

Clarity of intent matters more than the choice itself.

For founders, the key question is not which model is “best”, but which model you are actually building. That decision shapes everything that follows: product design, go-to-market, hiring, capital allocation and long-term positioning.

For investors and operators, understanding these distinctions helps explain why superficially similar software businesses behave so differently. Growth rates, margins, retention, and exit outcomes are all downstream of the underlying philosophy.

And for the industry more broadly, this diversity is not a weakness. It is a reflection of how much surface area software now covers. As new technologies emerge, particularly in AI, we should expect further variation rather than consolidation.

The landscape is not settling. It is expanding.

The companies that succeed will not be those that follow a single playbook, but 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