15 SaaS Business Models and How They Make Money

SaaS business models describe who pays you, what they pay for and how the money reaches you: subscriptions, transaction fees, commission, licenses or a mix. Below are 15 of them, from classic B2B subscriptions to marketplaces and open core, with what each one demands from your billing, user roles and data.

A business model isn't a pricing model. Pricing is the unit a customer pays for, like seats or usage, and I cover it in my guide to SaaS pricing models. As a developer, I focus on what each model means for the code and the budget.

The short answer

Here are all 15 at a glance: how each one earns money and what is usually hard to build.

My rule of thumb: the more parties in the money flow, the more expensive the product is to build and run. Choosing the model is step one in my complete guide to building a SaaS, before you pick any technology.

Subscription-first models

The first four earn from subscriptions. They differ in who the customer is and how the sale happens.

1. Horizontal B2B SaaS

A tool for a job many companies share, like project management, CRM or time tracking, usually billed monthly or yearly per seat or plan.

The foundation is an account (the company) with several users, invitations, simple roles like admin and member, and a subscription attached to the account. A common mistake is tying the subscription to whoever signed up. It breaks the day that person leaves.

My take: the most proven model, and also the most crowded. Without a sharp angle, you're up against products with far bigger budgets.

2. Vertical SaaS

Software for one industry, such as hair salons, physiotherapy clinics, transport companies or property managers. Many vertical products earn extra from add-ons like SMS reminders or payments.

The hard part is the industry's workflows: shift schedules, treatment notes or delivery routes. The data model has to match how the industry works, and there's almost always an integration with industry-specific software.

My take: the model I usually point founders to first. In smaller markets like the Nordics or Benelux, one niche can support a healthy business, and the competition is often an aging system nobody loves. You or a partner do need to know the industry from the inside.

3. B2C SaaS

Subscriptions sold to consumers, like apps for fitness, budgeting or languages. Prices are low, so the business depends on volume and low churn (the share of customers who cancel each month).

Everything has to work without a human in the loop: sign-up, payment, password resets, card updates and cancellation. VAT is harder than in B2B: once cross-border consumer sales pass a small EU-wide threshold, you charge each customer's local rate. App Store and Google Play sales add their own in-app payment rules. I compare the billing options in my post on SaaS subscription billing.

My take: hard to profit from without a serious marketing budget. Consumers are price-sensitive, and a support ticket costs the same whether the customer pays €5 or €50 a month.

4. Sales-led enterprise SaaS

A handful of large customers on annual contracts, often negotiated one by one. Sales take months and involve procurement, IT security and legal, but each customer is worth a lot.

Big customers ask for things small ones never mention: single sign-on through their identity provider (such as Microsoft Entra ID or Okta), an audit log, granular roles, a data processing agreement and often a long security questionnaire. Payment is usually by invoice on agreed terms.

My take: only realistic if you already have access to the buyers. Don't build SSO and audit logs up front, but design roles and events so they can be added when the first big customer asks.

Models with more than one kind of customer

The next three serve more than one type of customer. Budgets often slip here, because the data model must tell the groups apart from the start.

5. B2B2C

A business pays, but its own customers use the product too. A booking system for clinics is the classic case: the clinic pays the subscription and patients book appointments. Revenue comes from the business, often plus a fee per SMS or booking.

You get two very different user groups and two interfaces. End customers need to get in without friction, often without a password, while each business wants its own logo and colors. Under GDPR, the business is usually the controller for its customers' data and you're the processor. Keeping each business's data separate is covered in my post on multi-tenant SaaS architecture.

My take: a strong model, because end customers make your product hard to replace. But you're designing and supporting two products instead of one.

6. Marketplace

You connect buyers and sellers and take a commission on every deal, sometimes with a subscription for sellers on top. Think tradespeople and homeowners, or landlords and tenants.

A marketplace is one of the heaviest models to build. Sellers must be onboarded and verified with a payment provider, each payment split between the seller and you, and you handle payouts, refunds, disputes and reviews. Stripe Connect is built for this: according to Stripe's documentation, you can collect from the customer and automatically pay out a portion to the seller. The rest is in my guide on how to build a two-sided marketplace.

My take: the code is rarely the hard part. Getting buyers and sellers on board at the same time is. Test demand manually before you build automated payouts.

7. White-label and resellers

Partners, typically agencies or consultants, pay to sell your product to their clients under their own brand. You earn a license fee per partner, per end customer or both, and they do the selling.

That adds a layer to the data model: the partner, the partner's clients and their users. Add custom domains, themes, emails from the partner's domain, a partner portal and partner-level billing. The full list is in my post on white-label SaaS.

My take: a good way to get distribution without a sales team, but wait until the product is stable. Every bug now hits your partner's clients and reputation.

Models that earn on transactions and usage

In the next two, revenue grows with what customers do in the product, not with user count, so you must count and bill accurately.

8. Embedded payments

Your customers take payments from their own customers through your product, and you add a small margin on top of the payment provider's fee. A booking system might take payment at booking, for example. For some vertical products, that margin ends up bigger than the subscription.

Each customer needs a connected account with the payment provider, including its identity checks. Then come fees, refunds, payouts and a reconciliation report your customer's accountant can use. The provider handles the payment itself, but the code around it has to be exact.

My take: an obvious extra revenue stream in vertical SaaS, where payment is already part of the workflow. Add it when customers ask for it, not in version 1.

9. API-first

The product is an API (an interface other software can call) rather than a user interface. Customers are developers paying per call, by volume or for a capped plan. Think SMS, email or address lookup.

You need API keys per customer, rate limiting, usage metering, documentation, a sandbox and stable versions. A change that breaks a customer's integration can cost you the customer, so plan versioning from day one.

My take: works when you solve a narrow technical problem better than anyone. Operations and support weigh more than in a typical web product, because developers expect high uptime.

Models built on an ecosystem

The next three rely on someone else's platform, other people's apps or a community around the code.

10. App on another platform

You build an app for a system your customers already use, such as Shopify, HubSpot or an accounting package, and sell it in its app store. Customers find you there, and billing often runs through the platform. Under Shopify's revenue share rules, developers keep 100% of their first $1M in lifetime gross app revenue and 85% above that, and all billing carries a 2.9% processing fee.

You'll build an install flow with the platform's OAuth, handle its webhooks, use its billing API and keep up when the API changes. Most app stores review apps before listing them.

My take: the fastest route to your first customers, because the platform hands you distribution. The price is dependence. If the platform changes its rules or its API, or builds your feature itself, you're exposed.

11. Your own app marketplace

Once your product is big enough, other companies can build apps and integrations for it. You earn a share of their sales, but the bigger win is retention: customers stay because their other tools are wired into yours.

That takes a public API, OAuth so third parties can act on a customer's behalf, scoped permissions, webhooks, developer docs and a review process for new apps.

My take: not a model for a new SaaS. Start with a solid API and webhooks for your own customers. Nobody builds for an app marketplace until there are plenty of customers to sell to.

12. Open core

The core is open source and free to self-host, and you earn from a hosted version or paid-only features. The analytics tool Plausible is an example: according to Plausible's self-hosting page, its Community Edition is free under the AGPL license, while features such as funnels and SSO are cloud-only.

You maintain two editions: one others can install, usually as a Docker image, and one you host. Upgrades have to work for people who skip versions, and paid features need to switch on and off with a license.

My take: fits best when your customers are technical themselves. Choosing the license is a legal decision, so settle it before the code goes public.

Models where software is only part of the product

The last three sell something besides software: human work, a device or data insight.

13. Service-led SaaS

The customer pays a fixed monthly fee for software plus work done by people, like bookkeeping, payroll or reporting. The software makes your own team faster and gives the customer visibility.

You're building two products: the one customers see, and an internal tool for your staff with task queues, deadlines and access across customer accounts. That access must be controlled and logged, because your team sees many customers' data.

My take: lower margins than pure software, but much easier to sell early on. If you already run a service business, it's often the most realistic path.

14. Hardware plus SaaS

A device such as a sensor, GPS tracker, payment terminal or meter, paired with a subscription for software and data. The device is sold or leased, and the subscription brings recurring revenue.

The system has to ingest data from many devices, cope when they lose connection, know which device belongs to which customer and ideally update firmware (the software on the device itself) remotely. Logistics, returns and warranty are a business of their own.

My take: strong when the device produces data you can't get any other way. I build the platform, the API and the interface, but electronics and firmware need other specialists.

15. Data and benchmarks

You aggregate data across customers and sell the insight, like how a store's revenue per square meter compares with similar stores, usually as a higher tier or add-on.

You need a data model that compares across customers, plus anonymization rules so no single customer can be identified. The bigger hurdle is legal. If personal data is involved and you're the processor, you may only use it on the customer's instructions, not for your own purposes, as the EDPB's guide for small businesses explains. Otherwise, your terms decide what you may do.

My take: a good extra revenue stream in vertical SaaS with many customers, never a model to start with. If you'll want cross-customer data later, talk to a lawyer and cover it in your terms and data processing agreement from the start.

How to choose and combine models

Most SaaS products end up combining two or three models. A vertical booking system might earn from subscriptions, embedded payments and SMS add-ons all at once. That's fine as long as one model carries the business and the rest arrive when customers ask.

These five questions show how technically heavy your model is:

1. Is the payer also the user? If not, you have several user groups and probably a B2B2C or white-label setup.
2. Does money pass through your product to anyone but you? Then you need a payment provider with connected accounts, and reconciliation becomes part of the product.
3. Who sells the product? That decides if you need self-service sign-up, a partner portal or invoice billing.
4. Do you own the customer relationship, or does a platform? On someone else's app store, you're borrowing their customers.
5. Which data will you use across customers? That affects both the data model and your terms.

Questions 1 and 2 are the expensive ones to change later, because they shape the data model. Prices, plans and add-ons can be adjusted as you go.

Next steps: turn your business model into a technical plan

Write your business model as one sentence: who pays whom, for what, and where the money goes. For example: "Clinics pay a monthly subscription, patients book for free, and the system takes a small cut of payments made at booking." That sentence tells a developer more about your data model than a long feature list.

Bring it, and your answers to the five questions, to your first conversation. Before larger builds I run a fixed-price discovery phase where you and I turn the model into accounts, roles, payment flows and a tightly scoped first version. You can see how that works on my SaaS development service page.

Frequently asked questions

Can I change my SaaS business model after launch?+

Yes, but the cost depends on what changes. Adding plans, add-ons or annual billing is usually a small job. Moving from a plain subscription to a marketplace or white-label setup typically means data model changes. So think through the two or three most likely models before version 1, even if you only build one.

Which business model suits a small SaaS with limited resources?+

A simple B2B subscription for a narrow industry is usually the most realistic choice. Businesses pay more than consumers, a niche is easier to reach on a small budget, and you only have one customer type and one money flow to build. Hold off on marketplaces, hardware and your own app ecosystem until you have paying customers.

Do I need a license to take payments on behalf of my customers?+

Usually not, as long as a licensed payment provider receives and pays out the money, for example through Stripe Connect. If the money lands in your own account before you pass it on, it can count as a regulated payment service under EU rules, requiring authorization from your national financial regulator. The exemptions are detailed, so have a lawyer review your setup first.

Does the business model affect what a SaaS costs to build?+

Yes, often more than the feature count does. A subscription from one customer type is the cheapest model to build. Every extra user group, money flow or external platform adds work to the data model, payment flow and testing, and to operations after launch. That's why I pin down the business model before I estimate a SaaS build.