Vertical SaaS

What is vertical SaaS?#

Horizontal SaaS serves a business function across industries — CRM, communication, accounting. Vertical SaaS serves an industry's operating model: restaurant point of sale, life-sciences quality management, construction project administration, bank loan origination.

A vertical platform typically compounds across four layers:

Two public companies bracket the range. Toast runs a transaction-heavy model: fiscal 2025 revenue of $6,153m, of which $5,037m was financial-technology solutions and only $936m subscription, across roughly 164,000 locations and $195.1bn of gross payment volume. Veeva runs a subscription-heavy model: fiscal 2026 revenue of $3,195.3m, of which $2,684.2m (84.0%) was subscription. (Toast Q4/FY2025 results, 12 Feb 2026; Veeva Q4/FY2026 results, 3 Mar 2026) Both are called vertical SaaS. They are not the same business.

Why does vertical SaaS matter to founders?#

A narrow market can support a broad product. The logo count is smaller than for horizontal software, but revenue per customer expands through modules and transactions. Size the economic surface area per customer, not just the TAM of software seats.

Domain depth lowers commercial friction. Industry-specific integrations, controls, and reporting shrink the gap between demo and production, and references from near-identical customers carry unusual weight in a small industry.

Adjacent products change the margin profile, not just the revenue line. Payments, hardware, lending, and services can raise revenue per customer and deepen switching costs while lowering blended gross margin. "More revenue per customer" is not automatically "better SaaS economics."

The wedge determines the expansion rights. A frequent workflow creates habit and data. A regulatory workflow creates trust and lock-in. A transaction creates monetization density. Choose the wedge for what it lets you sell next, not only for how much it hurts today.

How do you model vertical SaaS economics?#

1. Score the wedge#

Rate a candidate starting workflow on frequency and urgency, economic cost of error, current fragmentation and manual labour, access to both buyer and end user, required integrations, time to first value, budget ownership, and adjacent expansion paths. A severe but annual workflow makes a poor system of engagement. A frequent but trivial task will not fund acquisition cost.

2. Measure workflow depth, not seats#

Track the share of the customer's relevant work completed in the product: transactions processed, locations live, modules adopted, records governed, integrations active. Seats measure licence purchase; depth measures dependence.

3. Model revenue and contribution by stream#

revenue per account = subscription + usage + transaction revenue + hardware + financial products + services

account contribution = revenue − software delivery − payment and financial cost − hardware cost − service delivery − attributable support

Compute contribution per stream, then blend. Applying one software gross-margin assumption to the whole bundle is the single most common modelling error in this category.

4. Test repeatability#

implementation ratio = implementation cost ÷ first-year recurring revenue

configuration share = reusable configuration effort ÷ total implementation effort

Configuration share should rise as the product matures. Caveat: both ratios are only meaningful with a written policy on what counts as implementation cost — the same onboarding hours can sit in cost of revenue or in CAC, and that choice can move payback by months without changing anything real.

5. Map the control points#

Identify systems of record, mandatory integrations, regulators, payment rails, channel partners, incumbent contracts, and data rights. That map is simultaneously your defensibility and your dependency list — the same integration that makes you sticky can be closed by its owner.

Worked example: one restaurant location, one month#

Assume a location processing $80,000 of card volume. All rates below are assumptions, chosen to sit near Toast's disclosed 2025 stream margins; replace them with your own realised data.

Payments cost is $1,760 of interchange, network, and processor fees (2.20% of GPV) plus $35 of fraud, chargeback, and compliance cost.

blended gross margin = $755 ÷ $2,750 = 27.5%

Two things fall out immediately.

Payments dominate revenue but not profit. Payments are 82.9% of revenue and 64.2% of gross profit. Subscription is 16.0% of revenue and 41.7% of gross profit. A revenue-mix chart tells you almost nothing about where the earnings are.

Software modules move gross profit far more than payment volume does. Add an inventory module at $120/month costing $30 to deliver:

revenue = $2,870 · cost = $2,025 · gross profit = $845 · margin = 29.4%

Revenue rose 4.4%; gross profit rose 11.9%. At $2,400 of acquisition and installation cost, simple payback falls from $2,400 ÷ $755 = 3.2 months to $2,400 ÷ $845 = 2.8 months. Caveat: this payback formula assumes no churn during the window and no further sales cost — see CAC payback before quoting it.

Stress test the spread. Hold volume constant and cut the gross payment spread by 10%, from 2.85% to 2.565%. Revenue falls $228 — and because the cost side is unchanged, so does gross profit. That is 30.2% of the location's entire gross profit erased by a repricing you may not control. Interchange changes, processor renegotiation, mix shift toward debit or card-present, or a regulatory cap all produce this move. A vertical SaaS company with a payments-heavy mix is partly a spread business, and should be stress-tested like one.

Related concepts#

• SaaS — the recurring software economics this model extends.
• Marketplace Model — connecting industry participants once you own the workflow.
• Hardware-as-a-Service — modelling deployed devices, subsidy, and replacement.
• Managed Services — the model you are actually running if configuration share never rises.
• AI-Native Business Models — what changes when the workflow itself is machine-performed.
• Vertical Integration — deciding which adjacent activities to own.
• Transaction-Based Pricing — pricing the payments and take-rate layer.
• Switching Costs — separating embedded workflow from customer satisfaction.

Sources#

1. Toast, Inc., Toast Announces Fourth Quarter and Full Year 2025 Financial Results, 12 February 2026. Source for FY2025 revenue and cost of revenue by stream, ~164,000 locations, $195.1bn GPV, $2,047m ARR, and Toast's own ARR definition and caveat.
2. Toast, Inc., fiscal 2025 Form 10-K (year ended 31 December 2025), filed February 2026. Source for the end-to-end restaurant-platform description spanning software, payments, hardware, and financial technology.
3. Veeva Systems Inc., Veeva Announces Fourth Quarter and Fiscal Year 2026 Results, March 2026. Source for FY2026 total revenue of $3,195.3m and subscription revenue of $2,684.2m (84.0%).
4. Veeva Systems Inc., fiscal 2026 Form 10-K (year ended 31 January 2026), filed 2026. Source for the industry-cloud description and segment revenue split.
5. Procore Technologies, Inc., Procore Announces Fourth Quarter and Full Year 2025 Financial Results, 24 February 2026. Source for 2025 revenue of $1.3bn (+15%), 80% GAAP gross margin, and 2,710 customers above $100,000 ARR representing 66% of ARR.