SaaSCron

Project management SaaS: types, pricing models and how to choose one

Ricardo Machado — Sat, 31 Oct 2026 21:00:00 GMT

You run projects in a spreadsheet and a chat thread, and deadlines slip because nobody can see who is doing what. A project management tool fixes that only if you pick the kind that matches how your team works, at a price that still makes sense when the team grows. Every tool here is rented as a subscription, the model explained in What is SaaS?.

This guide maps the four kinds of project management software, shows how free tiers, seat minimums and billing terms change what you pay, and ends with a checklist for your trial. Vendor figures come from the vendors’ own pages, checked in October 2026. For a general method to compare vendors, see How to evaluate SaaS solutions.

Project management software in plain terms

Think of the ticket rail in a restaurant kitchen. Each order is pinned in a row, moved along as the dish is prepared and taken down when it leaves the pass. Anyone in the kitchen can see what is waiting, what is cooking and what is late.

A project management tool is that rail for office work. Each task is a ticket with an owner, a due date and a status. The tool shows the same tasks in different views: a list, a board with a column per status, or a calendar. A timeline, often called a Gantt chart, draws tasks as bars across dates so you can see which ones depend on others.

The four kinds

Kind	Built for	What it adds	Watch for
Task management	Small teams with simple to-dos	Lists, boards, due dates, comments	Outgrowing it once projects depend on each other
Agile and software delivery	Development teams working in sprints	Backlogs, sprint boards, links to code	Too rigid for non-technical teams
Work management	Several departments sharing one tool	Custom fields, automations, many views	Setup time; someone has to own the templates
Portfolio management	Leaders tracking many projects at once	Roll-ups across projects, goals, capacity	Price; usually on the top tiers only

Most products cover more than one row, and the vendors use the labels loosely. Decide which row is your main need, then check that the tier you can afford includes it. Asana, for example, lists “Timeline and Gantt views” on its Starter plan, while “Unlimited portfolios” and “Goals” appear on Advanced.

How the price is built

Asana and monday.com both price per user (seat) per month. Three details move the bill:

Free-tier limits. Asana’s free Personal plan is limited to 2 users. Jira’s Free plan allows up to 10 users. monday.com’s free plan allows up to 2 seats and up to 3 boards.
Seat minimums. monday.com says its paid plans start at 3 seats, so a 2-person team on a paid plan pays for 3.
Billing terms. Asana lists Starter at $10.99 per user per month billed annually and $13.49 billed monthly. Advanced is $24.99 annually and $30.49 monthly.

Example: a 12-person team chooses Asana Starter, then considers Advanced for portfolios.

Starter, billed annually: 12 x $10.99 = $131.88 a month, or $131.88 x 12 = $1,582.56 a year.
Starter, billed monthly: 12 x $13.49 = $161.88 a month, or $161.88 x 12 = $1,942.56 a year.
Cost of monthly billing: $1,942.56 - $1,582.56 = $360.00 a year, which is $360.00 / $1,582.56 = 22.7% more than annual.
Advanced, billed annually: 12 x $24.99 = $299.88 a month, or $299.88 x 12 = $3,598.56 a year.
Cost of the upgrade: $3,598.56 - $1,582.56 = $2,016.00 a year, or $2,016.00 / 12 = $168.00 per person per year.

The upgrade question then becomes concrete: is a portfolio view worth $168 per person per year to your team? If only 2 managers need it, ask the vendor whether a workspace can mix tiers before you upgrade everyone.

Monthly billing makes sense while you are still deciding. Once the tool has survived a quarter of real use, annual billing costs $360 a year less for the same 12 seats.

Checklist

Run this during the trial, with real work, not a demo project:

Your main kind of work (from the table) is covered on the tier you can afford.
Two people outside the project lead can create, assign and close tasks without help.
The views your team uses most, such as board and timeline, are on that tier.
You know the free-tier user limit and what happens when you pass it.
You know the seat minimum and whether guests or viewers need paid seats.
The tool connects to your chat, calendar and file storage.
You can export all tasks, comments and attachments in a usable format.
Single sign-on and user provisioning are available on your tier, if your company needs them.
You have priced the next tier up for the whole team, not only for one feature.
One person owns templates, statuses and fields after rollout.

Asana, for example, lists SAML sign-in and SCIM user provisioning on its Enterprise plan. For how to run the rollout once you pick, see SaaS implementation.

Common mistakes

Choosing by feature list, not by workflow. A tool with every view still fails if the team works in sprints and the tool thinks in projects. Why it happens: comparison pages count features. Instead: pick the row of the table that matches your main work first.
Paying monthly after the decision is made. In the example, monthly billing costs $360 a year more for 12 people. Why it happens: nobody revisits the plan after the trial. Instead: switch to annual billing once the tool has survived a quarter.
Planning around the free tier. Asana’s free plan stops at 2 users and Jira’s at 10, and teams grow during projects. Why it happens: free feels like a trial without an end date. Instead: price the paid tier for your expected headcount in a year before you invite everyone.
Letting everyone design statuses and fields. Ten people create ten ways to say “blocked”, and reports stop making sense. Why it happens: work management tools make customizing easy. Instead: name one owner for templates and statuses. For how seat licenses are counted at renewal, see SaaS licensing.

Sources

Asana, Pricing, checked October 2026.
Atlassian, Explore Jira Cloud plans, checked October 2026.
monday.com, Pricing, checked October 2026.

In three sentences

Project management SaaS comes in four kinds, task, agile, work and portfolio management, and the right one depends on how your team works more than on the feature count. Free-tier limits, seat minimums and billing terms move the price: 12 people on Asana Starter pay $1,582.56 a year billed annually, $360 more billed monthly and $2,016 more on Advanced. Trial the tool with real work, price the next tier for the whole team and name one owner for templates before you roll it out.

The SaaS industry: how it is structured, how big it is and what is changing it

Ricardo Machado — Sat, 31 Oct 2026 16:00:00 GMT

You need a picture of the SaaS industry for a pitch deck, a job move or the market section of a plan, and most of what you find mixes forecasts, rankings and opinions with no dates attached. What helps is a structure you can reuse and a few figures that carry their source and date. If SaaS itself is new to you, start with What is SaaS?.

The SaaS industry is the set of companies that sell software as a hosted subscription, plus the platforms they build on and the marketplaces they sell through. Its parts earn money in different ways, so an average across all of them says little about any one company. For what makes a single company a SaaS company, see B2B SaaS companies.

The industry in plain terms

Think of a shopping mall. Department stores sell a bit of everything to everyone, specialist shops sell to one kind of customer, the landlord supplies power and floor space, and the directory at the entrance sends visitors to shops. All of it is retail, but each earns money in a different way.

The SaaS industry has the same four parts:

Part	What it sells	Typical buyer	Usual way of charging
Horizontal SaaS	One business function for every industry: CRM, email, HR, accounting	Any company	Subscriptions, often per seat
Vertical SaaS	Software for one industry, such as dental clinics or builders	Businesses in that industry	Subscriptions, often plus payments or other services
Infrastructure and platforms	What SaaS products run on: cloud computing, databases, delivery networks	Software builders	Usage
Marketplaces	App stores and listings inside larger platforms	Vendors who sell through them	A share of each sale or a listing fee

The table is a map, not a ranking. One company can sit in more than one row, as when a CRM vendor runs an app marketplace. For how the first two rows differ in revenue, see Vertical SaaS vs horizontal SaaS.

Dated figures: size and valuation

The figures below change with each new edition of their source. Each one carries its source and date, so you can replace it when a newer edition appears.

Figure	Value	Source and date
Worldwide end-user spending on SaaS, 2024	$250,804 million, up 18.1%	Gartner forecast, November 19, 2024
Worldwide end-user spending on SaaS, 2025	$299,071 million, up 19.2%	Gartner forecast, November 19, 2024
Worldwide public cloud spending, all services, 2025	$723,421 million	Gartner forecast, November 19, 2024
SaaS spending in Australia, 2026	Almost A$16.4 billion, up 13.8%	Gartner forecast, May 11, 2026
Median EV/TTM revenue multiple, SEG SaaS Index	5.7x in 2Q25, 3.2x in 2Q26	Software Equity Group, 2Q26 report

Gartner calls SaaS “cloud application services” in its tables. The 2025 values are forecasts made in late 2024, not measured results.

Example: reading the Gartner table and the SEG multiple.

SaaS share of all public cloud spending in 2025: $299,071M / $723,421M = 41.3%.
Growth from 2024 to 2025 in dollars: $299,071M - $250,804M = $48,267M.
Growth as a rate: $48,267M / $250,804M = 19.2%, which matches Gartner’s growth column.
Now a hypothetical company with $50 million in trailing revenue, valued at the index median. At 5.7x it is worth 50 x 5.7 = $285 million. At 3.2x it is worth 50 x 3.2 = $160 million.
Change in value: ($285M - $160M) / $285M = 43.9% lower, with no change in the company’s own revenue.

Step 5 is the reason to keep market data in a dated box. A valuation built on last year’s multiple can be wrong by almost half without the business changing at all. For how multiples are calculated, see SaaS valuation multiples.

How the industry measures itself

Many public and private SaaS companies report the same handful of numbers, which makes them comparable:

ARR (annual recurring revenue): the yearly value of subscriptions in force.
Net revenue retention: this year’s revenue from last year’s customers, as a share of last year’s revenue from them.
Gross margin: the share of revenue left after the cost of running the service.
Growth plus margin: some investors add the revenue growth rate to the profit margin and compare the sum with 40%, a convention often called the Rule of 40.

The numbers matter more than the labels. Two companies with the same ARR can be worth very different amounts if one keeps 120% of last year’s revenue and the other keeps 90%.

The forces changing the industry

Buyers counting seats. Gartner’s May 2026 forecast for Australia says SaaS growth there is slowing “with organizations prioritizing license optimization, slower seat growth and tighter application portfolio scrutiny.” Fewer new seats per customer means growth has to come from price, new products or new customers.

Usage meters next to seats. Infrastructure has long charged by use. Application vendors are adding usage meters too, often for AI features, alongside per-seat plans. Salesforce sells Agentforce actions through Flex Credits, and GitLab’s Premium plan includes $12 of GitLab Credits per user each month for AI features.

Platforms and marketplaces. Large vendors open their products to other companies’ apps and take a share of what sells through them. A small vendor can reach customers through a marketplace, at the price of the platform’s fee and rules.

AI agents and the per-seat model

The debate in 2026 is whether AI agents reduce the number of seats customers need. Gartner said on July 1, 2026 that up to $234 billion of enterprise application spending is exposed to “agentic arbitrage” by 2030, roughly 20% of enterprise application SaaS spending. The same release says “SaaS will not be destroyed; it will emerge in a different form.” Treat both lines as one firm’s forecast, dated, and check the next filings of the vendors you care about.

Common mistakes

Quoting a forecast as a fact. Gartner’s 2025 figure was published in November 2024 as a forecast. Why it happens: the number looks precise. Instead: write “forecast” and the publication date next to it.
Mixing figures from different editions. Research firms can revise categories between releases, so a 2024 table and a 2026 table may not measure the same thing. Why it happens: search results show both. Instead: compare years only within one release.
Averaging the whole industry. A vertical SaaS company with payments revenue and an infrastructure vendor billing by usage do not share one “typical” margin or multiple. Why it happens: one industry figure is easier to cite. Instead: compare a company with peers in its own row of the map.
Valuing a company on an old multiple. In the example, the same revenue was worth $285 million at one median and $160 million at the next. Why it happens: the last number you saw sticks. Instead: use the latest index edition and state its quarter.

Sources

Gartner, Gartner Forecasts Worldwide Public Cloud End-User Spending to Total $723 Billion in 2025, November 19, 2024, checked October 2026.
Gartner, Gartner Forecasts Australian Organizations Will Spend More Than A$33 Billion on Public Cloud in 2026, May 11, 2026, checked October 2026.
Gartner, Gartner Says $234 Billion in Enterprise Application Software Spend Is at Risk from Agentic AI, July 1, 2026, checked October 2026.
Software Equity Group, Quarterly SaaS report, 2Q26, checked October 2026.
Salesforce, Agentforce pricing, and GitLab, Pricing, checked October 2026.

In three sentences

The SaaS industry has four parts, horizontal, vertical, infrastructure and marketplaces, and each earns money differently, so compare companies within their own part. Gartner’s November 2024 forecast put SaaS at $299,071 million of 2025 spending, 41.3% of public cloud, while SEG’s median revenue multiple fell from 5.7x to 3.2x between mid-2025 and mid-2026. Keep every market figure in a dated box with its source, because the same revenue can be valued 43.9% lower one year later.

Will AI agents replace SaaS? The per-seat debate behind the 2026 software selloff

Ricardo Machado — Sat, 31 Oct 2026 11:00:00 GMT

You pay for software by the seat, or you sell it that way, and you keep reading that AI agents will make seats obsolete. If an agent does the work of five people inside a business application, does the vendor still get paid for five logins? This explainer sets out both sides with named, dated sources and leaves the forecast to you. For the subscription model at stake, start with What is SaaS?.

“SaaSpocalypse” is a nickname for the fear that AI agents will hollow out software companies. The research firm Gartner used the word in a July 2026 release, redefining it as “the disaggregation of the legacy SaaS market”. Software Equity Group (SEG), which publishes the SEG SaaS Index of public SaaS companies, described a “sharp early-year selloff” in its report on the second quarter of 2026. For how those valuation multiples are calculated, see SaaS valuation multiples.

Agents and seats in plain terms

Think of a toll road that charges per car. If a company replaces five delivery vans with one larger truck, the same goods travel the road, and the toll collects one fee instead of five. The road’s owner then needs a different way to charge, such as by weight.

Two terms carry the debate:

Per-seat pricing: you pay a fixed amount per named user per month. Revenue grows when the customer hires.
AI agent: software that carries out multi-step tasks across systems on someone’s behalf, not only answering questions.

Gartner names the effect “agentic arbitrage”, which “happens when AI agents complete tasks across multiple systems”.

The case that agents shrink SaaS

Gartner’s release of July 1, 2026 puts a number on the risk. It says up to $234 billion of enterprise application spending is “exposed to agentic arbitrage between now and 2030”, roughly 20% of enterprise application SaaS spending by 2030.

George Brocklehurst, Managing Vice President at Gartner, gives the mechanism: “Agentic systems deliver outcomes directly, bypassing traditional user experience (UX)-heavy applications.” On revenue, he says agentic AI “breaks the link between user growth and revenue growth for many enterprise software vendors.” He adds that “the user interface is no longer a differentiation.”

Valuations fell in the same period. SEG reports that the median EV/TTM revenue multiple of its index fell from 5.7x in the second quarter of 2025 to 3.2x in the second quarter of 2026. The multiple compares a company’s enterprise value with its revenue over the trailing twelve months. SEG says the reset was broad as AI reshapes software, and that the market now reserves premium valuations for companies with strong operating performance and defensible advantages.

The case that SaaS changes shape instead

The same Gartner release argues against reading this as an ending. It says “SaaS will not be destroyed; it will emerge in a different form”, and Brocklehurst calls the shift “less an apocalypse and more of a metamorphosis.” His argument for incumbents rests on data: “Better outcomes from AI require systems that can retain deep institutional memory and customer context over time.” On that argument, vendors that already hold years of customer records start ahead.

Incumbents are also selling agents themselves. Salesforce reported on August 26, 2026 that revenue for its fiscal second quarter of 2027 was $11.3 billion, up 11% year on year. It said Agentforce annual recurring revenue (ARR) “exceeded $1.5 billion, up over 240% Y/Y.” The same release notes that from that quarter, Agentforce ARR also counts Salesforce’s AI offerings, Slackbot and Headless 360, so the figure is not directly comparable with earlier quarters.

Pricing is moving too. Salesforce’s Agentforce pricing page lists $2 per conversation and Flex Credits at $500 per 100,000, noting that “Agentforce actions are 20 Flex Credits”. It also lists a per-user add-on at $125 per user per month. Seats remain on the list, next to meters for the work an agent does.

Example: fewer seats, new meters

Example (hypothetical vendor, real reference rate): a vendor charges $100 per seat per month, and a customer holds 50 seats.

Current bill: 50 x $100 = $5,000 a month.
Agents take over routine work, and the customer renews with 30 seats: 30 x $100 = $3,000.
Revenue lost: $5,000 - $3,000 = $2,000 a month, or $2,000 / $5,000 = 40%.
Suppose the vendor meters agent work at Salesforce’s published Flex Credit rate: $500 / 100,000 = $0.005 per credit, and 20 credits per action is 20 x $0.005 = $0.10 per action.
Actions needed to replace the lost revenue: $2,000 / $0.10 = 20,000 a month, or 20,000 / 30 = about 667 a day.

The arithmetic shows why both sides can be right about different customers. A customer whose agents run 667 actions a day pays the vendor what it paid before. A customer whose agents run 100 a day pays $3,000 + 100 x 30 x $0.10 = $3,300, which is 34% less than before.

What to watch, without a forecast

Neither side’s claim can be checked today; the evidence arrives in later filings and price lists. Four signals are public:

Signal	Where to find it	What it would show
Seat counts and net revenue retention	Vendors’ quarterly filings	Whether customers buy fewer seats at renewal
New meters on pricing pages	Vendors’ pricing pages	Whether vendors charge for agent work beyond seats
AI revenue figures and their definitions	Earnings releases, footnotes	Growth, and whether definitions changed
Index multiples	SEG and other index reports	How investors price the change

For how seat-based and usage-based pricing compare in general, see SaaS pricing models.

What to ask at your next renewal

Whichever side turns out closer, your contract is where the debate reaches you. Ask the vendor:

How is agent work billed: by seat, conversation, action or credit?
What is the rate per unit, and is there a monthly cap on usage charges?
If you cut seats because agents do the work, will agent usage cost more than the seats you save?
Are AI features included in your plan, or sold as add-ons with their own meter?
Which of your records does the agent read, and can you export them if you leave?

Common mistakes

Treating a share-price fall as proof. Lower multiples show what investors expect, not what customers have done. Why it happens: market headlines arrive before filings. Instead: read seat counts and retention in the vendors’ own reports.
Comparing AI revenue across quarters without the footnotes. Salesforce widened what counts as Agentforce ARR in the quarter it reported $1.5 billion. Why it happens: the definition sits below the headline figure. Instead: read the definition before comparing growth rates.
Assuming fewer seats means a smaller bill. In the example, a customer running 667 agent actions a day pays the same $5,000 on 30 seats. Why it happens: seat counts are the familiar unit. Instead: model both meters at renewal and ask for caps on usage charges.
Reading “exposed” as “lost”. Gartner’s $234 billion is spending “exposed to agentic arbitrage” up to 2030, not revenue already gone. Why it happens: large numbers travel without their verbs. Instead: quote the forecast with its wording, its date and its horizon.

Sources

Gartner, Gartner Says $234 Billion in Enterprise Application Software Spend Is at Risk from Agentic AI, July 1, 2026, checked October 2026.
Software Equity Group, Quarterly SaaS report, 2Q26, checked October 2026.
Salesforce, Salesforce Delivers Record Second Quarter Fiscal 2027 Results, August 26, 2026, and Agentforce pricing, checked October 2026.

In three sentences

The case against SaaS is that AI agents work across many applications, so customers need fewer seats; Gartner says up to $234 billion of enterprise application spending is exposed by 2030. The case for SaaS is that vendors holding customer data are selling agents and adding usage meters, as Salesforce’s $1.5 billion Agentforce ARR and $0.10-per-action Flex Credit rate show. Whether a 40% seat cut becomes a loss depends on how much metered agent work replaces it, so watch seat counts, pricing pages and definitions rather than share prices.

GitHub vs GitLab SaaS: hosted plans, CI minutes, security and self-managed options

Ricardo Machado — Fri, 30 Oct 2026 21:00:00 GMT

You need a home for your team’s code, and the choice has narrowed to GitHub or GitLab. Both sell a hosted service you rent per user, the model explained in What is SaaS?, and both also sell software you can run on your own servers. The price per user is only part of your bill: CI minutes, security add-ons and where your data lives decide the rest.

This comparison uses the vendors’ own pricing and documentation pages, checked in October 2026. Both companies change plans often, so recheck every figure on the linked pages before you sign.

Hosted Git in plain terms

Think of a shared workshop. Everyone keeps their projects on labeled shelves, a bench in the corner tests anything you put on it, and a guard at the door checks what comes in. You pay rent per member, plus extra when the bench runs long.

Each part has a name:

Repository hosting is the shelves: Git repositories with access control, code review (pull requests on GitHub, merge requests on GitLab) and issues.
CI/CD (continuous integration and delivery) is the bench: jobs that build, test and deploy code on every change. GitHub calls its service Actions; GitLab meters runner time in compute minutes.
Security scanning is the guard: tools that look for vulnerable dependencies, leaked secrets and unsafe code.

Hosted plans side by side

Checked October 2026	GitHub	GitLab.com
Free	$0; 2,000 Actions minutes a month; 500 MB Packages storage	$0; 400 compute minutes a month; 10 GiB storage; 5 users per top-level group (private groups)
Middle tier	Team: $4 per user/month; 3,000 minutes; 2 GB Packages storage	Premium: $29 per user/month, billed annually; 10,000 minutes; 500 GiB
Top tier	Enterprise: $21 per user/month; 50,000 minutes; 50 GB Packages storage	Ultimate: custom price; 50,000 minutes; 500 GiB
Extra CI	Linux 2-core $0.006 a minute, Windows $0.010, macOS $0.062 (standard runners)	$10 per 1,000 compute minutes, one-time purchase
AI allowance in the plan	Copilot free tier up to 2,000 completions a month	Premium includes $12 of GitLab Credits per user/month; Ultimate $24

One caution on GitHub’s prices. Its pricing page shows Team at $4 and Enterprise at $21 with the words “for the first 12 months” and an asterisk whose terms were not shown on the page when checked. Ask GitHub for the price from month 13 before you budget past year one.

GitHub’s documentation adds that Actions is free on self-hosted runners and for public repositories using standard GitHub-hosted runners. You pay for minutes only on private repositories using GitHub’s machines.

Example: 20 developers for one year

Example: a team of 20 developers whose private-repository CI uses 8,000 Linux minutes a month. The calculation assumes each GitLab compute minute equals one Linux runner minute; confirm the rate for your runner type in GitLab’s documentation.

GitHub Team, at the listed first-year price:

Seats: 20 x $4 = $80 a month.
Minutes over the allowance: 8,000 - 3,000 = 5,000. At $0.006 a minute: 5,000 x $0.006 = $30.
Monthly total: $80 + $30 = $110. Yearly: $110 x 12 = $1,320.

GitHub Enterprise, same basis:

Seats: 20 x $21 = $420 a month. The 8,000 minutes fit inside the 50,000 included.
Yearly: $420 x 12 = $5,040.

GitLab Premium:

Seats: 20 x $29 = $580 a month. The 8,000 minutes fit inside the 10,000 included.
Yearly: $580 x 12 = $6,960.

Now move half the builds to macOS, for an iOS app, and assume the included minutes go to the Linux jobs. On GitHub Team, 4,000 Linux minutes are covered by the 3,000 included plus 1,000 x $0.006 = $6, and 4,000 macOS minutes cost 4,000 x $0.062 = $248. The monthly bill becomes $80 + $6 + $248 = $334, three times the Linux-only figure. The operating system of your builds can matter more than the seat price.

The seat prices are not a like-for-like comparison of features. Read the plan tables for the three or four features you actually need, and price those.

Security scanning

GitHub: Dependabot is listed on the Free plan. GitHub Secret Protection and GitHub Code Security are sold as add-ons; the pricing page did not list their prices when checked.
GitLab: its pricing FAQ says basic static analysis (SAST), secret detection and container scanning run on all tiers, while enterprise-grade scanning and vulnerability management are in Ultimate.

If security scanning is the reason you are choosing, get a written quote for the add-on or tier that carries it, since neither company lists every security price on the main pricing page.

Data residency and self-managed editions

Option	GitHub	GitLab
Shared (multi-tenant) SaaS	GitHub.com; GitHub describes Enterprise Cloud as “a multi-tenant enterprise SaaS solution on Microsoft Azure”	GitLab.com
SaaS with data in a chosen region	Enterprise Cloud with data residency, on its own GHE.com subdomain; regions listed: EU, Australia, US and Japan	GitLab Dedicated: single-tenant SaaS “hosted and maintained by GitLab” in the AWS region you choose
Self-managed	GitHub Enterprise Server, on your own hardware or cloud account	GitLab Self-Managed; the Free tier means “bring your own storage and runners”, Premium is $29 per user/month billed annually

Self-managed editions move upgrades, backups and uptime to your team. They make sense when a rule requires the code on your own infrastructure, not merely in a given country, because both vendors now sell hosted options with regional data. For the general trade-off, see SaaS vs on-premise software.

Common mistakes

Comparing seat prices only. In the example, macOS builds tripled the GitHub Team bill while the seat line stayed at $80. Why it happens: per-user prices lead the pricing page. Instead: estimate monthly CI minutes by operating system and add them to each option.
Budgeting the first-year price for three years. GitHub labels its Team and Enterprise prices “for the first 12 months”. Why it happens: the label is small. Instead: get the year-two price in writing before you compare.
Forgetting free-tier user limits. GitLab’s Free plan allows 5 users per top-level group for private groups, so a sixth developer forces a decision. Why it happens: the limit sits in the plan details, not the headline. Instead: count everyone who needs write access, including contractors.
Self-hosting for data location when a hosted regional option exists. You take on upgrades and backups to solve a problem the vendor already sells. Why it happens: the regional options sit on separate product pages. Instead: check GitHub’s data residency regions and GitLab Dedicated first, then decide. For how per-user licenses are counted in contracts, see SaaS licensing.

Sources

GitHub, Pricing, GitHub Actions billing and About GitHub Enterprise Cloud with data residency, checked October 2026.
GitLab, Pricing and GitLab Dedicated, checked October 2026.

In three sentences

GitHub and GitLab both rent hosted Git with CI/CD per user and sell self-managed editions, but their plans bundle CI minutes, storage and security very differently. For 20 developers using 8,000 Linux minutes a month, the listed prices give $1,320 a year on GitHub Team, $5,040 on GitHub Enterprise and $6,960 on GitLab Premium. Price your real CI minutes by operating system, get the year-two price in writing and check hosted regional options before you choose to run either one yourself.

SaaS analytics: cloud BI tools and analytics for your own SaaS product

Ricardo Machado — Fri, 30 Oct 2026 16:00:00 GMT

You searched for SaaS analytics and found two kinds of answers: business intelligence tools you rent in the cloud, and dashboards that show a SaaS company how its own product is doing. Both are real, and your company probably needs a bit of each. The same pipeline sits behind both, and the cost surprises come from the same places. If SaaS itself is new to you, start with What is SaaS?.

The first meaning is cloud BI: tools such as Microsoft Power BI or Google BigQuery that you use as a service to analyze your company’s data. The second is product analytics for a SaaS business: the numbers that tell you whether customers use, keep and expand what they pay for. This guide covers the pipeline, prices a small BI rollout and lists the product metrics worth tracking.

The analytics pipeline in plain terms

Think of a restaurant kitchen. Deliveries arrive from several suppliers and go into one pantry, and the cooks plate dishes from what is in the pantry. Nobody cooks straight off the delivery truck.

Each part of a data pipeline has a kitchen equivalent:

Sources are the deliveries: your app database, billing system, CRM and help desk.
ELT (extract, load, transform) is the delivery route. You copy raw data out of each source, load it into one store, then clean and join it there. Its older cousin, ETL, transforms the data before loading it.
The data warehouse is the pantry: a database built for large analytical queries rather than for running an app.
The BI layer is the plating: the dashboards and reports people actually read.

Small teams sometimes skip the warehouse and point a BI tool straight at the app database. That works until a heavy report slows down the app your customers are using.

Meaning 1: cloud BI bought as SaaS

Cloud BI tools follow the SaaS pattern: subscriptions, a browser interface and servers the vendor runs. Two pricing shapes are common, and many companies pay both.

Per seat for the BI layer. Microsoft lists Power BI Pro at $14.00 per user per month and Premium Per User at $24.00, both paid yearly. A free account can build reports but must upgrade to share them.
Per use for the warehouse. Google’s BigQuery charges by the data your queries process. Its free tier covers 1 TiB of processed query data a month. Its sandbox adds a lifetime 10 GiB of storage, with tables that expire after 60 days.

Prices and limits are from Microsoft’s and Google’s own pages, checked in October 2026.

Example: a 12-person company wants one shared sales dashboard on Power BI, with data in BigQuery. Assume all 12 people need a Pro license to work with shared reports; check Microsoft’s licensing terms for your own setup.

Seats: 12 x $14.00 = $168.00 a month.
A year, paid yearly: $168.00 x 12 = $2,016.
Queries: the dashboard refreshes scan 25 GiB a day. Over a 30-day month that is 25 x 30 = 750 GiB.
Free allowance: 1 TiB is 1,024 GiB, so 750 / 1,024 = 73% of the monthly free compute.
Now the team adds hourly refreshes and scans 50 GiB a day: 50 x 30 = 1,500 GiB, which is 1,500 - 1,024 = 476 GiB above the free tier, billed at the on-demand rate on Google’s pricing page.

The seat line is predictable; the query line is not. More frequent refreshes doubled the scanned data without anyone adding a user.

Meaning 2: analytics for your own SaaS product

If you run a SaaS product, your questions are about accounts, not sales regions. These five metrics cover most of them:

Metric	Question it answers	Where the data lives
Activation rate	Do new sign-ups reach the first useful outcome?	Product events
Active accounts, weekly or monthly	Is the product used, not just paid for?	Product events, per account
Feature adoption	Which features do paying accounts use?	Events tagged by feature and plan
MRR and churn	Is recurring revenue growing, and who leaves?	Billing system
Net revenue retention	Do existing customers spend more over time?	Billing, by cohort

The first three rows live in product events and the last two in billing. The useful answers come from joining them, and that join is the main reason to have a warehouse. For the retention formulas, see NDR and GRR in SaaS.

Example (hypothetical): in one month, 400 accounts sign up for a trial. Of those, 140 reach the first useful outcome, such as sending a first invoice.

Activation rate: 140 / 400 = 35%.
Of the 140 activated accounts, 20% pay after the trial: 140 x 20% = 28 customers.
Of the 400 - 140 = 260 that never activate, 2% pay: 260 x 2% = 5.2, so about 5 customers.
Total: 28 + 5 = 33 new customers from 400 trials, or 8.25%.
Raise activation to 45% (180 accounts): 180 x 20% = 36, plus 220 x 2% = 4.4, about 4, for 40 customers.

Ten more points of activation adds 7 customers a month without one more sign-up. That is the kind of answer you get only when product events and billing sit in the same place.

Choosing the pieces

Your stage	Reasonable setup
A few sources, standard reports	One BI tool with built-in connectors
Billing and product data need joining	Add a warehouse and an ELT tool
Several teams build their own dashboards	Add shared metric definitions owned by one person

An ELT tool that copies data out of your other SaaS tools goes through their APIs, so their rate limits and sync schedules apply. See SaaS integration for that arithmetic.

Common mistakes

Reporting straight from the production database. A heavy query slows the app for paying customers. Why it happens: the data is already there and a warehouse feels like overhead. Instead: copy data to a warehouse, or at least to a read-only replica, before the first big report.
Two definitions of “active”. Sales counts logins, product counts actions, and the numbers never match. Why it happens: each team defines the metric in its own tool. Instead: write one definition per metric and use it in every dashboard.
Tracking every click without a plan. Thousands of unnamed events, and nobody can find the one that matters. Why it happens: tracking everything feels safe. Instead: list the questions first, then the events that answer them, with a naming rule.
Forgetting that refreshes cost money. Hourly refreshes on a usage-priced warehouse multiply the scanned data, as the example shows. Why it happens: the seat price is the only cost on the purchase order. Instead: set refresh schedules per dashboard and review the query bill monthly.

Sources

Microsoft, Power BI pricing, checked October 2026.
Google Cloud, BigQuery sandbox and BigQuery pricing, checked October 2026.

In three sentences

SaaS analytics means two things: BI tools you rent as a service, and the product metrics a SaaS company tracks about its own customers. In the example, 12 Power BI Pro seats cost a predictable $2,016 a year, while doubling dashboard refreshes pushed BigQuery queries past the free 1 TiB a month. Define each metric once, keep reports off the production database and join product events with billing, because that join shows which customers stay.

Zapier vs Make vs n8n: how each one counts your work, AI steps and self-hosting

Ricardo Machado — Fri, 30 Oct 2026 11:00:00 GMT

You want each new form submission to land in your CRM, post to a chat channel and get a reply drafted by an AI model, and three tools keep coming up: Zapier, Make and n8n. Their pricing pages use three different words for what you pay for, so the cheapest plan on the page may not be the cheapest for your workflow. All three are hosted services you rent, the model explained in What is SaaS?, and n8n can also run on your own server.

This comparison works from the vendors’ own pricing and help pages, checked in October 2026. Prices change often, so treat every figure as dated and recheck it on the linked page before you buy. For the plumbing underneath, APIs, webhooks and rate limits, see SaaS integration.

Billing units in plain terms

Think of three car parks with several barriers inside. The first charges for each barrier you pass after the entrance. The second charges for every barrier, the entrance included. The third charges once per visit, however many barriers you pass. The same drive costs very different amounts in each.

The three tools bill like that:

Zapier counts tasks. “A task is any successful action that runs in Zapier.” Triggers, filters, paths, formatter steps and failed actions do not count, and Zapier says polling checks “never use tasks.”
Make counts credits. “Every time a module in a scenario performs an action, it consumes credits.” Make’s help pages call each module run an operation: a module that processes 10 records (bundles) uses 10 operations, and a trigger uses one operation per check.
n8n counts executions. “An execution is a single run of your entire workflow.” The number of steps and the data volume do not change the count.

The plans as listed

Checked October 2026	Zapier	Make	n8n
Free	100 tasks a month, two-step Zaps, polling every 15 minutes	1,000 credits a month	Community Edition, self-hosted
Entry paid plan	Professional: $19.99 a month billed annually ($29.99 monthly), 750 tasks	Core: price not shown in the page text	Starter: €20 a month billed annually, 2,500 executions
Next plan	Team: $69.00 a month billed annually ($103.50 monthly), 2,000 tasks	Pro, Teams, Business: prices not shown	Pro: €50 a month billed annually, 10,000 executions
Self-hosting	No	No	Yes

Two notes on the table. Make’s pricing page did not show plan prices in its text when checked; it says paid allowances are “proportional to the number of credits that you purchase”, so read Make’s pricing page in your browser. n8n listed its prices in euros when checked, and your region may see another currency.

Example: one workflow on three meters

Example: a form submission starts a workflow with five actions: create a CRM contact, add a tag, post to a chat channel, ask an AI model for a reply draft and save the draft to a document. It runs 100 times a month, then 2,000 times. The trigger is instant (a webhook), each run carries one record, and Make’s trigger is assumed to use one credit per run.

Runs per month	Zapier tasks (5 actions x runs)	Make credits (1 trigger + 5 modules) x runs	n8n executions (1 per run)
100	5 x 100 = 500	6 x 100 = 600	100
2,000	5 x 2,000 = 10,000	6 x 2,000 = 12,000	2,000

Read the rows against the listed plans:

At 100 runs: Zapier’s 500 tasks fit Professional’s 750-task tier at $19.99 a month. Make’s 600 credits fit inside its free 1,000. The 100 n8n executions fit Starter’s 2,500 at €20.
At 2,000 runs: Zapier’s 10,000 tasks are 10,000 / 2,000 = 5 times Team’s entry tier, so you price a larger tier on the page. Make’s 12,000 credits need a paid allowance. The 2,000 n8n executions still fit Starter.
Add a sixth action: Zapier rises to 6 x 2,000 = 12,000 tasks, up 20%. Make rises to 7 x 2,000 = 14,000 credits. n8n stays at 2,000.

Per-step meters grow with every action you add; a per-run meter grows only with runs. Neither is cheaper in general. Short workflows that run rarely are cheap everywhere, and long workflows that run often favor the per-run count.

Polling changes Make’s number. A trigger that checks for new data every 15 minutes runs 4 x 24 x 30 = 2,880 checks in a 30-day month, and each check uses an operation even when it finds nothing. On Zapier the same polling costs no tasks.

AI steps are charged differently

Zapier: AI by Zapier is not on the Free plan. The pricing page says AI steps are charged per AI step and per tool call, with the cost depending on the model tier, and it sends you to a separate rates page. Zapier Agents is billed on its own allowance and “does not count as tasks.”
Make: the pricing page says most actions use one credit, while some features that run on Make’s AI Provider may use more. It does not list the amounts.
n8n: the pricing page counts one execution per run whatever the steps inside it do.

Whichever tool you pick, check how the AI model in your step is paid for: through the tool’s own credits, or through your own account with the model provider. That second bill does not appear on any of these pricing pages.

Self-hosting n8n: free to run, not free to own

n8n’s Community Edition is self-hosted and free, with its source on GitHub under the Sustainable Use License. That license allows use “only for your own internal business purposes or for non-commercial or personal use.” If you plan to sell hosted automation to clients, read the license before you build on it.

Self-hosting moves the bill from executions to your server and your time. Updates, backups, uptime and security patches become yours. In a hypothetical case, a $20-a-month server plus 3 hours of upkeep a month at $50 an hour costs $20 + 3 x $50 = $170 a month. That is more than n8n’s own Pro plan, so self-hosting tends to pay off for volume or data-location reasons, not to save the first subscription.

How to choose by billing shape

Your workflows	Unit that tends to fit	Check before you commit
Few, short, many different apps, no developer	Zapier tasks	Tier price at your real task count; AI step rates
Branching scenarios over lists of records	Make credits	Bundles per run and polling frequency
Long workflows, high volume, or data that must stay on your servers	n8n executions	Execution limits per plan; license terms if self-hosted

The table is about how each meter grows, not product quality. Confirm that the apps you need have connectors on the tool you pick. For how per-unit pricing compares with per-seat pricing in general, see SaaS pricing models.

Common mistakes

Comparing headline prices, not units. A $19.99 plan and a €20 plan look equal until one counts every action and the other counts whole runs. Why it happens: pricing pages lead with the price. Instead: count actions, modules and runs for your real workflow, as in the example.
Forgetting Make’s polling checks. A 15-minute trigger uses 2,880 operations a month before any data arrives. Why it happens: the trigger feels free because nothing visible happens. Instead: use instant triggers where the app offers webhooks, or poll less often.
Ignoring AI step charges. An AI step can carry a charge on top of the task or credit it uses. Why it happens: AI pricing sits on a separate rates page. Instead: price the AI step separately, including any bill from the model provider.
Self-hosting to save money without counting your time. Three hours of upkeep a month can cost more than a hosted plan. Why it happens: the software is free to download. Instead: self-host for volume, control or data location, and budget the hours.

Sources

Zapier, Pricing and help center article on task usage, checked October 2026.
Make, Pricing and Operations, checked October 2026.
n8n, Pricing and Sustainable Use License, checked October 2026.

In three sentences

Zapier bills each successful action as a task, Make bills each module run as a credit, and n8n bills each whole workflow run as an execution. A five-action workflow run 2,000 times a month is 10,000 Zapier tasks, about 12,000 Make credits and 2,000 n8n executions, before any AI step charges. Price your own workflow in all three units on the vendors’ current pages, and count your own hours before you decide to self-host n8n.

Open SaaS and open-source SaaS boilerplates: what you get and what the license allows

Ricardo Machado — Thu, 29 Oct 2026 21:00:00 GMT

You have a SaaS idea and a few free evenings, and the first weeks will go to login screens, password resets and a billing page before you write a line of the product itself. A SaaS boilerplate is a starter codebase that ships those parts already wired together. An open-source one lets you start from that code for free, under a license that decides what you owe in return. If the term SaaS is new to you, start with What is SaaS?.

“Open SaaS” means two things in searches. It is the name of one free template, Open SaaS by the team behind the Wasp framework, and it is shorthand for open-source SaaS starters in general. This guide covers both: what a starter contains, the hours it can save, the license question that matters for hosted software and the signs that a starter is still maintained. For the business side of a small, self-funded product, see Bootstrapping a SaaS.

Boilerplates in plain terms

Think of a furnished flat. You move in with the bed, the fridge and the curtains already there, and your first week goes to your own work instead of assembling shelves. The catch is that you live with someone else’s choices until you replace them.

A boilerplate (or starter kit) is that flat for code. Most SaaS starters cover the same parts:

Authentication: sign-up, login, password reset, email verification and social login.
Billing: a checkout, subscription plans and the webhooks a payment provider sends when a customer pays or cancels.
Admin: a dashboard to see users and revenue.
Email and jobs: transactional email and scheduled background tasks.
Deployment: a documented path to put the app online.

Multi-tenancy, one installation serving many customer organizations with their data kept apart, is less common. Check for it before you assume it is there.

What one real starter includes

Open SaaS is published by the wasp-lang organization on GitHub under the MIT license. Its repository describes it as “A 100% free modern JS SaaS boilerplate (React, NodeJS, Prisma)” built on the Wasp framework. As listed in the repository in October 2026:

Part	What the repository lists
Auth	Email, Google, GitHub, Slack and Microsoft login, with email verification
Payments	Stripe, Polar.sh or Lemon Squeezy
Admin	A dashboard built with ShadCN UI
Email	SendGrid, Mailgun or SMTP
Analytics	Plausible or Google Analytics
Files	Uploads to AWS S3
AI	An OpenAI API example that uses function calling
Tests and docs	Playwright end-to-end tests; documentation on Astro Starlight

The list tells you what you do not have to build. It also tells you what you inherit: a framework, a database layer and a set of vendors you did not pick. Swapping the payment provider later is your work, not the template’s.

The license question: MIT vs AGPL

For SaaS, the license matters in a way it does not for most desktop software. Your users never receive a copy of your code. They use it over the network. Two common licenses sit at opposite ends.

MIT is, in the words of choosealicense.com, “a short and simple permissive license with conditions only requiring preservation of copyright and license notices.” You may use the code commercially, change it and keep your changes private. You keep the copyright notice in the code.
AGPL-3.0 is a strong copyleft license. Its condition “network use is distribution” means that if you run a modified version as a service, you must make the complete source of that version available to its users, under the same license. The ordinary GPL does not ask this of software that only runs on a server.

What this means for you: an MIT starter can become your private codebase. An AGPL starter can still be a sound base, but the source of your product must be available to the people who use it.

A third group needs the same care: licenses that publish the source but limit how you use it. n8n’s Sustainable Use License, for example, allows use “only for your own internal business purposes or for non-commercial or personal use.” Read the LICENSE file in the repository, not the landing page, and check the licenses of the main dependencies too.

Example: the hours a starter can save

Example (hypothetical): you estimate the plumbing your SaaS needs before its first real feature, and you price your time at $50 an hour.

Part	Hours from scratch	Hours to adapt a starter
Auth with email verification and one social login	30	6
Subscription billing with webhooks	40	10
Admin dashboard	20	4
Transactional email and deployment	15	5
Total	105	25

Step by step:

Hours saved: 105 - 25 = 80 hours.
Value at $50 an hour: 80 x $50 = $4,000.
At 10 hours a week of evening work, you reach your first real feature 80 / 10 = 8 weeks earlier.
The cost side: suppose you spend 2 hours a month merging upstream updates and fixing what they break. Over 12 months that is 2 x 12 = 24 hours, or 24 x $50 = $1,200.
Net in year one: $4,000 - $1,200 = $2,800 in your favor, plus the 8 weeks.

The hour estimates are illustrative. Replace them with your own; the shape of the sum is the point. A starter saves the most when you would otherwise build every part yourself, and the least when you plan to rip out half of it.

How to tell whether a starter is maintained

A free starter that nobody updates turns into security debt, because it bundles auth and payment code. Before you build on one, check:

Last commit and last release dates. Months of silence on a project that depends on auth and payment libraries is a warning.
Open issues and replies. Read the oldest open issues and see whether maintainers answer.
Dependency freshness. Compare the versions in the package manifest with the current releases of the framework and the payment SDK.
Upgrade notes. A changelog or migration guide shows how painful the next version will be.
Who funds it. A starter backed by a framework company has a reason to keep it alive. A weekend project may not.

Stars measure popularity, not upkeep. A popular repository can still be abandoned.

Starter, scratch or paid kit

Your situation	Reasonable choice
Testing an idea fast on a common web stack	An open-source starter under MIT
You need something starters lack, such as strict tenant isolation	Build the core yourself and borrow pieces
You want support and one accountable maintainer	A paid starter kit, after reading its license
You plan to resell the software under other companies’ brands	Check the starter’s license first; see White-label SaaS

Common mistakes

Reading the README instead of the license. “Free” on a landing page can sit next to an AGPL or a non-commercial license. Why it happens: the README is friendlier. Instead: open the LICENSE file, and the licenses of the major dependencies, before your first commit.
Keeping every integration because it came in the box. Three email providers and two analytics tools mean more keys, more updates and more ways to break. Why it happens: deleting code feels like throwing value away. Instead: remove what you do not use in the first week.
Never pulling upstream fixes. Your copy drifts, and a security patch to the auth code never reaches you. Why it happens: merging is tedious once you have edited the same files. Instead: keep your changes in separate files where you can, and schedule a monthly merge.
Assuming multi-tenancy. Many starters treat each user as a customer, not each organization, and adding team accounts later touches every table. Why it happens: the demo works fine for one user. Instead: decide on day one whether your customers are people or companies.

For how to price the product once it runs, see SaaS pricing models.

Sources

wasp-lang, Open SaaS repository, checked October 2026.
choosealicense.com, MIT License and GNU AGPLv3, checked October 2026.
n8n, Sustainable Use License, checked October 2026.

In three sentences

An open-source SaaS boilerplate gives you auth, billing, admin and deployment already wired, so your first weeks go to the product instead of plumbing. In the worked example, adapting a starter saves 80 hours, worth $4,000 at $50 an hour, against about 24 hours of upkeep in the first year. Read the license before the README, because MIT lets you keep your code private while AGPL requires you to share the source of a modified version you run as a service.

SaaS for MSPs: managing client tenants, security and backup

Ricardo Machado — Thu, 29 Oct 2026 16:00:00 GMT

You run IT for twenty small businesses, or you are about to hire a firm that does. Each client has its own Microsoft 365 or Google Workspace, its own admins, and its own idea of who is responsible when files disappear. You need a way to manage all of them without holding a master key to everything, and a clear answer on backup.

A managed service provider (MSP) is a company paid to run another company’s IT. With SaaS, the vendor runs the software, as explained in What is SaaS?. Configuration, access, security settings and backup still need an owner, and for many small businesses that owner is an MSP.

MSP work in plain terms

Think of a property manager who looks after fifty apartments. A careful one holds a separate key for each apartment, only for the rooms it services, and logs every visit. A careless one carries one master key to the whole building. Both can fix a leaking tap. Only one of them is a disaster if the keys are stolen.

Two terms do most of the work:

Tenant: one client’s instance of a SaaS service, with its own users, settings and data. In Microsoft 365, each client organization is a tenant.
Delegated administration: admin rights that a client grants to a partner, so the partner can manage the client’s tenant without a user account inside it.

Access: separate, limited keys per client

Microsoft’s answer to the master-key problem is granular delegated admin privileges (GDAP). Microsoft describes it as least-privileged access that is “granular and time-bound”, and customers “must explicitly grant” it. Partners who manage Azure no longer receive the Global Admin role on a customer’s tenant by default. Roles are assigned through security groups, with a limit of 100 security groups per customer.

In practice, that means a help-desk technician gets a role that can reset passwords, and only the senior engineer gets a role that can change security policy. Each client grants access to the partner separately, so a compromise at one client does not open all of them.

One console for many tenants

Managing fifty tenants one admin portal at a time does not scale. Microsoft 365 Lighthouse is Microsoft’s multi-tenant console for MSPs. Its documentation lists multi-tenant views across customer environments, a default security baseline for small and medium-sized business tenants, multifactor authentication and self-service password reset setup, and alerts on risky sign-ins. Microsoft says there is no additional cost to use it. It is available to partners in the Cloud Solution Provider program, both direct-bill partners and indirect resellers, and both partner and customer tenants must meet its requirements.

Third-party tools cover the same ground across more vendors: multi-tenant management consoles, remote monitoring tools, ticketing and billing systems, and SaaS security posture tools, covered in SSPM explained. This guide does not rank them.

Backup: what the vendor keeps, and what it does not

The most common client question after an incident is “can you get it back?” The answer depends on what was set up before the incident.

Microsoft 365. Microsoft 365 Backup protects SharePoint sites, OneDrive accounts and Exchange mailboxes. It costs $0.15 per GB per month for all protected data, and restores are free. The recovery window is set per backup policy: 3 months, 6 months, 1 year or 2 years. It is billed pay-as-you-go, by consumption, not per user. Partner backup applications can also be built on the same storage platform; in that case the partner’s application manages and bills it.

Google Workspace. Google Vault handles retention, legal holds and eDiscovery search and export. Google’s overview says “Vault isn’t a data archive”, and that “Vault doesn’t retain data until you set up retention rules.” Retention keeps deleted data available to search and export. It is not the same as restoring a user’s files to where they were.

For the edition and seat details of each suite, see Microsoft 365 as SaaS and Google Workspace as SaaS.

Who does what

The table sets out a common split of duties. The middle column describes the vendor’s tools named above; the right column is a starting point for your contract, not a rule from any vendor.

Area	What the SaaS vendor provides	What the MSP usually takes on	Evidence to keep
Admin access	Delegated admin roles (GDAP in Microsoft’s partner program)	Role design per client, quarterly access review	List of active relationships and roles per client
Security settings	Baselines and alerts (Lighthouse’s SMB baseline, risky sign-in views)	MFA rollout, alert response, exceptions	Baseline status report per client
Backup	Microsoft 365 Backup (paid per GB); Vault retention rules (Google)	Policies, retention choices, restore tests	Restore test log with dates and times
Billing	Per-user subscriptions; per-GB backup charges	Resale, pass-through or bundling	Monthly reconciliation of vendor bills to client invoices

Worked example: backup inside a flat per-user fee

Example: a labeled hypothetical that uses Microsoft’s published backup price. A client has 40 users and 2.5 TB of data across SharePoint, OneDrive and Exchange. You charge a flat $60 per user a month for managed services and want to include backup. Assume 1 TB = 1,000 GB.

Backup cost today: 2,500 GB x $0.15 = $375 a month.
Your fee: 40 x $60 = $2,400 a month.
Backup per user: $375 / 40 = $9.38, or $9.38 / $60 = 15.6% of the fee.

Now suppose the client’s data grows 3% a month.

After 12 months: 2,500 x 1.03^12 = 2,500 x 1.4258 = 3,564 GB.
Backup cost: 3,564 x $0.15 = $534.60 a month.
Per user: $534.60 / 40 = $13.37, or 22.3% of the same $60 fee.

The fee did not move, the headcount did not move, and backup grew from 15.6% to 22.3% of your revenue from the client. A per-GB cost inside a per-user price shifts the growth risk onto you. Pass it through at cost, or include a storage allowance and bill above it.

Checklist for each new client

Set up delegated access with the narrowest roles that cover the contract.
Remove any shared or legacy global admin accounts.
Apply a security baseline and record what is excluded and why.
Decide on backup in writing: which services, which recovery window, who pays.
Run a test restore in the first month and log how long it took.
Agree how per-user and per-GB charges appear on the invoice.

Common mistakes

One global admin account used for every client. If it is phished, every client is exposed at once. Why it happens: it is the fastest way to start. Instead: use delegated, least-privilege roles per client and review them each quarter.
Treating retention as backup. Vault keeps nothing until a rule exists, and keeping data for search is not the same as restoring it. Why it happens: both promise that deleted data is “still there”. Instead: decide on a backup tool per client and write down what it covers.
Bundling a per-GB cost into a flat per-user fee with no cap. In the example, backup rises from 15.6% to 22.3% of the fee in a year. Why it happens: one flat price is easier to sell. Instead: pass storage costs through or set an included allowance.
Never testing a restore. The first restore is the one the client is watching. Why it happens: backups report success every night, so nobody checks. Instead: restore a mailbox and a site for each client once a quarter and keep the log.

Sources

Microsoft Learn, GDAP introduction, checked October 17, 2026.
Microsoft Learn, Overview of Microsoft 365 Lighthouse, checked October 17, 2026.
Microsoft Learn, Overview of Microsoft 365 Backup, checked October 17, 2026.
Google Workspace Admin Help, Vault overview, checked October 17, 2026.

In three sentences

An MSP running client SaaS needs separate, least-privilege admin access per client, one console to watch many tenants, and a backup decision made before anything is lost. Microsoft offers GDAP for access, Lighthouse as a no-cost console and Microsoft 365 Backup at $0.15 per GB a month, while Google Vault keeps nothing until retention rules exist. In the example, backup inside a flat $60 fee grows from 15.6% to 22.3% of it in a year, so pass per-GB costs through and test restores quarterly.

AI SaaS examples: 10 products and what their AI actually does

Ricardo Machado — Thu, 29 Oct 2026 11:00:00 GMT

Every SaaS vendor now says its product has AI, and your renewal quotes show new AI lines. You need to see, product by product, what the AI does and how you pay for it. Then you can compare like with like, and spot where you are paying twice.

AI SaaS, here, means software delivered as a service, as explained in What is SaaS?, in which a language model or image generator does part of the work. The ten products below are well-known SaaS tools that added AI, not a ranking. For the wider list of SaaS products, see SaaS examples.

AI in SaaS in plain terms

Think of buying a car. Some models come with cruise control as standard. Others sell it in a package for a fixed price. A few charge you by the mile for using it. The feature is similar in all three; what changes is how it shows up on the bill.

AI features follow the same three patterns:

Included: the AI comes with the plan or a higher tier.
Add-on: a fixed fee per user on top of the plan.
Metered: you pay by usage, counted in credits (prepaid units converted into AI actions) or in finished results.

Ten products and their AI

Every fact comes from the vendor’s own page, checked on October 17, 2026. AI plans change often; re-check before you buy.

Product	What the AI does	How it is priced
Microsoft Copilot	Assistant in Microsoft 365 apps; work-based chat over data the user’s account can access	Add-on license for eligible Microsoft 365 plans (Microsoft 365 E7 includes it); web-based Copilot Chat included at no extra cost
Google Workspace	Gemini in Gmail on Business Starter; Gemini in Gmail, Docs, Sheets, Slides, Vids, Drive, Meet and Chat on Standard and Plus	Included in the plan; access widens by tier
Slack	Conversation summaries, daily recaps and AI search on every plan; AI workflow generation on Business+	Included in the per-user plan; higher Slackbot limits on Business+ invoice plans need Flex Credits bought through Salesforce
Notion	Notion Agent for multi-step tasks, AI Meeting Notes, Enterprise Search (beta)	Trial on Free and Plus; included on Business at $20 per member a month; Custom Agents at $10 per 1,000 Notion credits
Atlassian Rovo	Search, chat and agents across Jira, Confluence and connected tools	Included with Standard, Premium and Enterprise Cloud plans; Jira and Confluence get 25, 70 or 150 credits per user a month; $0.01 per extra credit
GitHub Copilot	Code completion, chat, and an agent that works on a task and opens a pull request	Free, Pro $10, Pro+ $39 and Max $100 a month; chat and agent use drawn from AI Credits at $0.01 each
Figma	Figma Make turns a prompt into a prototype or web app; AI image editing	AI credits per seat: 3,000 a month on a Professional Full seat, 3,500 on Organization, 4,250 on Enterprise
Intercom	Fin AI Agent answers customers and completes workflows	$0.99 per outcome, on top of seats at $29, $85 or $132 a month
Salesforce Agentforce	AI agents inside Salesforce’s sales, service and other apps	Flex Credits at $500 per 100,000 (20 credits per standard action); add-ons at $125 per user a month; or $2 per conversation
HubSpot	Customer, prospecting, data, content and revenue agents, plus an agent builder	Agent Hub included in Starter, Professional and Enterprise; many agents run on HubSpot Credits

What the list shows

Suites put AI in the seat. Google, Slack and Notion’s Business plan include their AI in the per-user price, with more of it in higher tiers. The cost is hidden in the upgrade.

Tools for makers meter with credits. GitHub, Figma and Atlassian give each seat an allowance and price what goes beyond it. Figma warns that the number of credits a request uses “varies by request”.

Support and CRM agents charge for work done. Intercom bills per outcome and Salesforce per action or conversation. These agents act for your customers, so their volume follows your customer base, not your headcount.

The words change as fast as the prices. On October 17, 2026, Microsoft’s licensing page said the Microsoft 365 Copilot app “is now called Microsoft Copilot”. On the same day, GitHub’s plans page metered usage in AI Credits, and GitHub Docs had moved the older “premium requests” billing, at $0.04 a request, to pages marked legacy. Read the plan page and the docs on the same day, and keep the date.

Worked example: how far an included allowance goes

Example: a labeled hypothetical using Atlassian’s published numbers. Your company has 25 people on Jira Standard. Each gets 25 Rovo credits a month, and Atlassian pools all allowances in an organization into one shared pool. A basic AI interaction costs 10 credits.

Monthly pool: 25 users x 25 credits = 625 credits.
Basic interactions covered: 625 / 10 = 62.5, so 62 interactions for the whole company, or about 2.5 per person a month.
Suppose the team uses 300 basic interactions: 300 x 10 = 3,000 credits.
Credits over the allowance: 3,000 - 625 = 2,375. At $0.01 each: 2,375 x $0.01 = $23.75 a month.

Two readings follow. The included allowance covers very little regular use, so “included” does not mean “unlimited”. But the overage is small next to the seat price, as long as extra usage stays turned on. With it turned off, Atlassian pauses the credit-consuming features until the monthly reset, and your team loses the feature mid-month instead.

Checklist: before you pay for an AI feature

Find the unit: seat, tier, credit, action, conversation or outcome.
Find the conversion: how many credits one task uses.
Check whether allowances pool across the company or stay with each user.
Check what happens at the limit: a pause, or an overage bill.
Check the data terms by tier. Notion lists zero data retention with its AI model providers only on Enterprise.
Check whether a tool you already pay for includes the same AI. Google Workspace Standard already includes Gemini in Docs and Gmail.
Write down the date you checked each price.

For how one of these suites is priced overall, see Microsoft 365 as SaaS and Google Workspace as SaaS.

Common mistakes

Comparing seat prices and ignoring credits. Two tools at the same seat price can differ widely once usage starts. Why it happens: the seat price is the headline on the pricing page. Instead: estimate a month of real use and price it in each tool’s unit.
Reading “included” as “unlimited”. In the example, an included allowance covers about 2.5 basic interactions per person a month. Why it happens: “included” is the word on the plan card. Instead: find the allowance and the limit behavior before you roll the feature out.
Paying twice for the same AI. A team buys a separate writing assistant while its suite already includes one. Why it happens: different teams buy different tools. Instead: list the AI each existing tool includes before approving a new one.
Relying on an old price or plan name. Microsoft renamed its Copilot app, and GitHub moved Copilot from premium requests to AI Credits. Why it happens: last quarter’s comparison sheet still circulates. Instead: date every price and re-check it before each purchase or renewal.

Sources

All checked October 17, 2026:

Microsoft Learn, License options for Microsoft Copilot.
Google Workspace, Pricing; Slack, Pricing; Notion, Pricing.
Atlassian, Rovo pricing; GitHub, Copilot plans and Copilot requests (legacy); Figma, Pricing.
Intercom, Pricing; Salesforce, Agentforce pricing; HubSpot, AI agents.

In three sentences

Ten well-known SaaS products ship AI in three ways: included in the plan (Google, Slack, Notion), as a per-user add-on (Microsoft, Salesforce), or metered by credits and outcomes (GitHub, Figma, Intercom). In the example, 25 Jira Standard users share 625 Rovo credits, enough for about 62 basic AI interactions a month, with overage at $0.01 a credit. Compare AI features by their unit, allowance and limit behavior, check what your existing tools already include, and date every price you rely on.

SaaS directories and review sites: where to list your product and what it is worth

Ricardo Machado — Wed, 28 Oct 2026 21:00:00 GMT

Your product is live, and a dozen sites offer to list it. Some are free, some charge, some promise backlinks. You have limited hours and a small budget. You need to know which listings bring buyers, which only bring email, and which ways of asking for reviews break the rules.

A SaaS directory is a website that catalogs software products so buyers can find and compare them. Some add customer reviews, some run launch days, and some let buyers pay through an account they already have. If the subscription model itself is new to you, start with What is SaaS?.

A directory in plain terms

Think of how a new restaurant gets found. A guide with diners’ reviews brings people who are comparing options. An opening-day stall at a street fair brings a crowd for one afternoon. A list run by a trade association reaches a few people who need exactly your dish. A department store food hall puts you on the shelf where buyers already shop, and takes a cut of each sale.

Software listings work the same way. The four types reach different buyers at different moments, and each one asks for a different kind of payment: time, money or a share of revenue.

Four types of listing

Every rule and fee below comes from the platform’s own page, checked on October 17, 2026.

Type	What it does for you	What it costs	Example and its rules
Review platform	Puts you in front of buyers who are comparing products, with reviews as evidence	Your time to collect reviews; paid programs vary, so read the vendor’s terms	G2 caps any review incentive at $100 and bars undisclosed incentives, positive-only solicitation, and reviews from your employees or a direct competitor’s (G2 community guidelines)
Launch site	A one-day spike of attention from early adopters	Preparation time	Product Hunt requires a personal account to post; its day runs in Pacific time and posts go live at 12:01 AM (Product Hunt help)
Niche directory	A small audience in one industry or one tech stack	Often free or a flat fee	Judge each on whether your buyers actually use it
Cloud marketplace	Lets a buyer purchase through their cloud account	A share of the contract value	AWS Marketplace charges 3% on SaaS public offers; private offers pay 3% under $1M, 2% from $1M to under $10M, 1.5% at $10M or more, and 1.5% on all renewals (AWS docs)

AWS adds a 0.5% uplift when a channel partner resells the offer, so a SaaS private offer under $1M through a partner pays 3.5%. A 1% regional fee applies on top for buyers in South Korea.

What listings do for search

A listing can send you two things: visitors and a link. Google asks sites to mark paid placements with rel="sponsored" and user-generated links, such as comments and forum posts, with rel="ugc" (Google Search Central). A link you paid for is a paid link under that guidance. So judge a paid listing by the buyers it sends, not by the link.

Reviews work differently. A buyer who reads twenty reviews of your product on a third-party site is doing research you cannot do for them on your own website. That is the real value of a review platform: evidence from people who are not you.

Worked example: what each listing costs per customer

Example: two labeled hypotheticals. The first uses AWS’s published fees; the second uses invented directory numbers.

A marketplace deal. A buyer wants to purchase your $48,000-a-year contract through AWS Marketplace as a private offer.

Year 1: the contract value is under $1M, so the fee is 3%: $48,000 x 3% = $1,440. You receive $48,000 - $1,440 = $46,560.
Through a channel partner instead: 3.5% x $48,000 = $1,680.
Year 2 renewal: 1.5% x $48,000 = $720.
Two years direct: $1,440 + $720 = $2,160 on $96,000, or 2.25%.

A paid directory listing. A directory charges $8 per click. Of 1,000 clicks, 2% start a trial and 10% of trials buy.

Cost: 1,000 x $8 = $8,000.
Trials: 1,000 x 2% = 20. Customers: 20 x 10% = 2.
Cost per customer: $8,000 / 2 = $4,000.

Compare the two. If your average customer pays $48,000 a year, $4,000 per customer may be fine. If they pay $600 a year, it takes almost seven years ($4,000 / $600 = 6.7) to earn the click cost back. The marketplace fee is a percentage of revenue you already won. The click cost is paid whether anyone buys or not.

How to prioritize

Ask your last ten customers where they compared options. Their answer outranks any directory’s traffic claim.
Claim and complete the free profiles first. Add accurate pricing, screenshots and the integrations you support.
Add a cloud marketplace when buyers ask for it. Check the fee against your margin first, as in the example.
Use launch sites when you have something new to show. A launch day without a clear story is one quiet day.
Pay for placement last, and only with tracking that follows a click to a paying customer.

For what your own site needs before you send directory traffic to it, see SaaS website examples.

Checklist: asking for reviews within the rules

The FTC’s Consumer Reviews and Testimonials Rule took effect on October 21, 2024 (FTC Q&A). Platform rules add their own limits.

Ask every customer in a segment, not only the happy ones. G2 bars any method that “segments out potentially negative reviews”.
If you offer an incentive, never make it depend on a positive review, disclose it, and keep it within the platform’s cap ($100 on G2).
Do not buy reviews, write them, or pay a broker to supply them.
Ask employees and other insiders who post about the product to disclose their relationship to you.
Never threaten a reviewer or make an accusation about one that you know is false.
Do not present a review site you control as independent.
Reply to negative reviews with facts and a fix, in public.

Common mistakes

Buying listings for the backlink. Google’s guidance tells sites to mark paid links as sponsored. Why it happens: link-building advice predates that guidance. Instead: pay only for listings your buyers read.
Asking only happy customers for reviews. G2 removes reviews when it finds a seller soliciting only positive ones. Why it happens: an NPS survey makes the happy customers easy to find. Instead: send the same request to a whole segment, such as every customer who renewed this quarter.
Listing everywhere and maintaining nowhere. Old prices and dead screenshots on a profile cost trust. Why it happens: a listing feels like a one-time task. Instead: review every profile each quarter, starting with the ones that send trials.
Measuring listings by visits. Traffic that never starts a trial has no value. Why it happens: visits are the only number most directories report. Instead: tag every directory link and report cost per trial and per customer, as in the example. For the trial-led funnel itself, see PLG SaaS.

Sources

G2, Community guidelines, checked October 17, 2026.
Product Hunt, How to post a product, checked October 17, 2026.
AWS Marketplace Seller Guide, Listing fees, fees effective January 5, 2024, checked October 17, 2026.
Google Search Central, Qualify your outbound links, checked October 17, 2026.
Federal Trade Commission, Consumer Reviews and Testimonials Rule: Questions and Answers, checked October 17, 2026.

In three sentences

SaaS directories come in four types: review platforms, launch sites, niche directories and cloud marketplaces, and each reaches a different buyer at a different cost. In the example, an AWS Marketplace private offer costs $1,440 on a $48,000 first year and $720 on renewal, while a paid directory at $8 a click costs $4,000 per customer. List where your customers say they research, measure cost per customer rather than visits, and ask for reviews from everyone in a segment within the FTC’s and each platform’s rules.

Multi-tenant SaaS architecture: tenancy models, data isolation and trade-offs

Ricardo Machado — Wed, 28 Oct 2026 16:00:00 GMT

You are designing a SaaS product, or rebuilding one, and you have to decide whether customers share a database. A large prospect asks whether their data sits next to anyone else’s. Your cloud bill depends on the answer, and so does your next security review.

A tenant is one customer account in a SaaS product: in business software, a company and all of its users. Running many tenants on one shared system is a large part of what makes SaaS cheaper to operate than one installation per customer, as explained in What is SaaS?. How much you share, and how you keep tenants apart, is the architecture decision this guide covers.

Multi-tenancy in plain terms

Think of housing. In a street of detached houses, each family has its own walls, pipes and bills. In an apartment building, families share the foundation and the plumbing, and each has a locked door. Some buildings mix the two: most flats share everything, a few penthouses have a private lift. Detached houses are private and expensive. Apartments are cheap, and only as safe as their locks.

Cloud vendors use names for the same three choices. In AWS’s terms, the silo model gives a tenant dedicated resources, the pool model shares resources among tenants, and the bridge model mixes the two. AWS adds that a silo still shares one identity, onboarding and operations layer for all tenants. Without that layer, you are running a managed service, not SaaS.

The tenancy models compared

Microsoft’s Azure Architecture Center splits the middle ground in two. The table maps both vendors’ terms.

Model (AWS / Microsoft)	What is shared	How tenants are kept apart	Cost per tenant	Main risk
Silo / automated single-tenant	Identity, onboarding, operations	Separate infrastructure per tenant	Highest: Microsoft notes 100 tenants “probably require 100 times that cost”	Updates and fixes across many deployments
Pool / fully multitenant	Everything	Application code and a tenant ID	Lowest	A bug leaks data; one heavy tenant slows the rest; one bad change hits everyone
Bridge / vertically partitioned	Most tenants pooled, some on dedicated deployments	Both, depending on the tenant	Middle	Code must support both modes, and moving a tenant is a migration
Bridge / horizontally partitioned	The application tier; each tenant gets its own database	Separate data, shared compute	Middle	Automating many per-tenant components

The vertical split is often a pricing decision too. Microsoft points out that you can charge more for a single-tenant deployment to recover its cost.

Three ways to isolate data in a database

Row level. All tenants share the same tables, and every row carries a tenant ID. This is the cheapest option and the easiest to get wrong, because one query without the tenant filter returns everyone’s data.
Schema per tenant. One database holds a separate set of tables for each tenant. A missing filter no longer leaks data, but every schema change runs once per tenant.
Database per tenant. Each tenant has its own database, the horizontally partitioned model above. Isolation and per-tenant backups are simple; the fleet of databases is not.

For row-level isolation, the database can enforce the filter for you. PostgreSQL’s row security policies restrict which rows normal queries return. With row security enabled and no policy defined, PostgreSQL applies “a default-deny policy”, so no rows are visible. But superusers and roles with the BYPASSRLS attribute always bypass it, and table owners normally do too, unless the table is set to FORCE ROW LEVEL SECURITY. If your application connects as the table owner, the policies may not apply to it.

AWS makes a point that many teams miss. Authentication tells you who the user is, and authorization tells you what they may do. Neither stops a request from reaching another tenant’s data. In AWS’s words, “a user could be authenticated and authorized, and still access the resources of another tenant.” Isolation means every data access is scoped by the current tenant’s context, enforced separately from login.

Noisy neighbors

In a shared system, one tenant’s load becomes everyone’s problem. Microsoft’s example: if a large tenant runs a heavy query or operation, “it might affect other tenants.” The usual controls start with per-tenant rate limits and quotas. Beyond that, you can move the heaviest tenants to dedicated resources (the vertical split). Or you can give each tenant its own copy of the component under the most load (the horizontal split).

Worked example: 200 tenants, three designs

Example: a labeled hypothetical with round prices. You have 200 tenants. A shared database cluster that serves all of them costs $1,500 a month. The smallest dedicated database costs $25 a month. Each schema migration takes 3 minutes to run and check per database.

Pool: $1,500 / 200 = $7.50 per tenant a month. One migration run per release.
Database per tenant: 200 x $25 = $5,000 a month, or $25 per tenant. Each release runs 200 migrations: 200 x 3 = 600 minutes, or 10 hours of pipeline time.
Bridge: 190 tenants stay on the $1,500 cluster, and 10 enterprise tenants get a dedicated $400 database each. Cost: $1,500 + 10 x $400 = $5,500 a month. If each of the 10 pays a $1,000 monthly isolation premium, that is $10,000 a month of revenue against $4,000 of dedicated cost.

The pool is cheapest by a wide margin: $1,500 against $5,000. Database per tenant costs 3.3 times as much ($5,000 / $1,500) and adds 10 hours to every release. The bridge keeps the pool’s economics for 190 tenants ($1,500 / 190 = $7.89 each) and turns isolation into a product the 10 large tenants pay for.

Which model to start with

Many small customers who sign up on their own: pool, with row-level isolation enforced in the database and tested.
A few customers ask for isolation in security reviews: bridge. Keep the pool and sell dedicated databases or deployments as a higher tier.
Regulated customers who require dedicated infrastructure: silo, automated from day one. Microsoft’s example is software for legal firms whose customers insist on their own infrastructure.
A handful of very large customers: silo can be fine, because the per-tenant cost is small next to each contract.

Where the infrastructure runs matters as well. For the AWS building blocks, see SaaS on AWS. For serving each tenant on its own domain, see Cloudflare for SaaS. If a customer asks for a copy in their own data center, that is a different model, covered in SaaS vs on-premise.

Common mistakes

Treating login as isolation. An authenticated user with the right role can still reach another tenant’s rows if a query forgets the filter. Why it happens: the identity provider feels like the security layer. Instead: scope every data access by tenant, and enforce it in the database where you can.
Running the application as the table owner. In PostgreSQL, owners normally bypass row security, so the policies you wrote may never run. Why it happens: the migration user and the app user are the same account. Instead: give the application its own role, or force row security on the table.
Choosing silo without automation. Every deployment needs updates, and Microsoft warns that maintenance “can be time consuming”. Why it happens: the first five tenants are easy to manage by hand. Instead: script provisioning and upgrades before tenant number ten.
Never testing isolation. A leak shows up in a customer’s screenshot, not in your logs. Why it happens: tests use one tenant at a time. Instead: add automated tests that log in as tenant A and try to read tenant B, as Microsoft’s guide advises.

Sources

AWS Well-Architected SaaS Lens, Silo, pool, and bridge models, checked October 17, 2026.
AWS whitepaper, SaaS Architecture Fundamentals: Tenant isolation, marked “for historical reference only” by AWS, checked October 17, 2026.
Microsoft Azure Architecture Center, Tenancy models for a multitenant solution, checked October 17, 2026.
PostgreSQL documentation, Row security policies, checked October 17, 2026.

In three sentences

Multi-tenant SaaS runs many customers on shared infrastructure, and the choice is how much to share: everything (pool), nothing but identity and operations (silo), or a mix (bridge). In the example, 200 tenants cost $1,500 a month pooled and $5,000 on dedicated databases, while a bridge keeps pooled costs and charges 10 large tenants for isolation. Whatever you choose, enforce tenant scope on every data access, keep the app from bypassing database policies, and test that one tenant cannot read another’s data.

AI agent examples: seven real use cases in support, sales, engineering and finance

Ricardo Machado — Wed, 28 Oct 2026 11:00:00 GMT

You keep hearing that AI agents will take over work in your company, but the examples you find are demos or vague promises. You need concrete cases: what the agent does, where a person still steps in, and who said so, and when. Then you can judge which of your own tasks fit.

An AI agent is software that uses a language model to pursue a goal by taking steps, such as looking up data, calling another app or drafting a reply. Most agents reach companies inside SaaS products they already pay for, a delivery model explained in What is SaaS?. The examples below come from vendors’ own pages and announcements, each with its date.

An AI agent in plain terms

Think of a new junior assistant with a checklist and keys to a few rooms. A chatbot answers what you ask. An assistant with a goal decides the next step, opens the rooms it has keys for, and checks whether the job is done. A fixed workflow, by contrast, repeats the same steps every time, whatever it finds.

Two terms come up in every example:

Tool call: the agent’s request to another system, such as searching a help center, reading a CRM record or opening a pull request.
Human in the loop: a point where a person approves, reviews or takes over the agent’s work.

Seven examples by department

“Human role” quotes what the source says. Where the source says nothing, the table says so, and you should treat that as a question for the vendor.

Department	Agent	What it does	Human role stated by the source	Source and date
Support	Klarna AI assistant	Handled 2.3 million conversations in its first month, two-thirds of Klarna’s customer service chats, in 23 markets and more than 35 languages	Not stated in the release	Klarna press release, February 27, 2024
Support	Intercom Fin	Answers customers and completes workflows; billed at $0.99 per outcome	Handoffs to the human team count as a completed workflow	Intercom pricing, checked October 17, 2026
Sales	HubSpot prospecting agent	“Monitor buying signals and launch personalized outreach automatically”	Not stated on the page	HubSpot AI, checked October 17, 2026
Engineering	GitHub Copilot cloud agent	Researches a repository, plans changes, edits files and runs tests in a temporary cloud environment, then opens one pull request per task; sessions stop at 59 minutes	“Review and test the output before using it in production”; admins can disable it per repository	GitHub Docs, checked October 17, 2026
Finance	Ramp Policy Agent	Reviews each expense against company policy and recommends approval, rejection or review; auto-approves clearly in-policy expenses under a threshold	Controllers set what it may auto-approve and where exceptions escalate; reviewers handle “the 10-15% of transactions that actually require judgement”	Ramp blog, January 13, 2026
Finance	HubSpot revenue agent	“Collect payments faster by automating invoice follow-up and reminders”	Not stated on the page	HubSpot AI, checked October 17, 2026
Operations	Notion Agent	Completes multi-step tasks in a Notion workspace; listed on the Business plan	Not stated on the page	Notion pricing, checked October 17, 2026

What the seven have in common

A narrow task with a finish line. Resolve a conversation, approve an expense, open a pull request. None of them is “run the sales team”.

Access limited to a few systems. The GitHub agent works on one branch at a time. If a ruleset or branch protection rule is incompatible with it, GitHub blocks the agent’s access.

A defined way out. Ramp’s controllers decide where exceptions escalate. When a policy does not cover a case, the agent escalates it and flags the gap. Fin’s handoffs pass a conversation to people.

Results reported by the vendor. Klarna’s numbers are Klarna’s. Ramp says teams using its agent report “reclaiming 4-5 hours per week from manual reviews” and that more than 1,000 finance teams use it. These are claims, not independent benchmarks.

You can still learn from them. Klarna reported 2.3 million conversations as two-thirds of its chats, so the month’s total was about 2.3 million / 2 x 3 = 3.45 million. It also said resolution time fell from 11 minutes to under 2, a saving of at least 9 minutes per errand, and repeat inquiries dropped 25%. That last metric matters most, because a customer who has to ask again was not helped.

Worked example: sizing a support agent for your queue

Example: a labeled hypothetical that uses one public price. Your team handles 4,000 support conversations a month. Each costs you $6 in staff time. You test an agent billed per outcome at Intercom’s listed $0.99, and it resolves 35% of conversations.

Billed outcomes: 4,000 x 35% = 1,400. Agent cost: 1,400 x $0.99 = $1,386.
Left for people: 4,000 - 1,400 = 2,600. Staff cost: 2,600 x $6 = $15,600.
Before the agent: 4,000 x $6 = $24,000. After: $15,600 + $1,386 = $16,986.
Saving: $24,000 - $16,986 = $7,014 a month, or 29%.

Now read the outcome definition. Intercom also bills a completed handoff. Suppose 300 of the 1,400 billed outcomes were handoffs that your team then answered.

People now handle 2,600 + 300 = 2,900 conversations: 2,900 x $6 = $17,400.
Total: $17,400 + $1,386 = $18,786. Saving: $24,000 - $18,786 = $5,214, or 21.7%.

The agent still saves money, but a quarter less than the first estimate: $5,214 / $7,014 = 74%. The difference came from one clause in the definition of an outcome. Measure handoffs separately in any pilot.

Questions to ask before you deploy an agent

What is the one task, and how will you know it was done right?
Which systems can it read, and which can it change?
At what point does it hand over to a person, and who receives the handoff?
How will you sample its work each week?
What does it cost per finished task, not per action or per seat?

For how agents fit into the CRM data they read and write, see CRM SaaS. For the connections between apps that agents depend on, see SaaS integration.

Common mistakes

Using a vendor’s case study as your forecast. Klarna’s volume and Ramp’s hours describe their customers, not your queue. Why it happens: the numbers are public and specific. Instead: run a pilot on your own work and measure it.
Giving the agent more access than the task needs. An agent that can change any record can make any mistake. Why it happens: broad permissions make setup faster. Instead: start with read access plus one write action, and use controls like GitHub’s per-repository switch.
No escalation path. The agent meets a case nobody planned for and guesses. Why it happens: pilots test the happy path. Instead: set thresholds for automatic action, as Ramp’s controllers do, and route everything else to a named person.
Measuring deflection instead of resolution. A customer who gives up is counted as handled. Why it happens: deflection is the number the dashboard shows. Instead: track repeat contacts, as Klarna did, and read a sample of closed conversations every week.

Sources

Klarna, AI assistant press release, February 27, 2024, checked October 17, 2026.
Intercom, Pricing; HubSpot, AI agents; Notion, Pricing, all checked October 17, 2026.
GitHub Docs, About Copilot cloud agent, checked October 17, 2026.
Ramp, Policy Agent general availability, January 13, 2026, checked October 17, 2026.

In three sentences

The AI agents with public track records each do one narrow task, such as resolving a chat or reviewing an expense, and hand over to a person at a defined point. Their published results are vendor claims, and in the example a support agent saves $7,014 a month on paper but $5,214 once billed handoffs are counted. Before you deploy one, define the task, limit its access, name who receives escalations and measure resolution, not deflection.

SaaS revenue recognition: ASC 606 and IFRS 15 basics for subscriptions

Ricardo Machado — Tue, 27 Oct 2026 21:00:00 GMT

You closed an annual contract, the cash is in the bank, and your accountant says you earned only a small part of it this month. Your investor update shows bookings, your income statement shows revenue, and the two never match. You need to know why, so you can read your own numbers and ask your accountant the right questions.

Revenue recognition is the set of rules that decides when money from a customer counts as revenue. Under U.S. GAAP the rules sit in ASC Topic 606; under international standards, in IFRS 15. Both apply to subscription software as described in What is SaaS?. This guide explains the shared model in plain words. It is not accounting advice: how the rules apply to your contracts is a judgment for your accountant and auditor.

Revenue recognition in plain terms

Think of a gym that sells a year’s membership for $600 in January. The gym has the cash on day one, but it still owes you eleven more months of access. Each month it delivers, it earns $50. Until then, the unearned part sits on its balance sheet as something it owes you.

Two terms carry the whole topic:

Deferred revenue: money billed or received for service not yet delivered. Some filings, such as Salesforce’s, call it unearned revenue.
Performance obligation: a distinct promise in the contract, such as software access or an onboarding project.

The five steps

The IFRS Foundation summarizes IFRS 15 in five steps. FASB’s Topic 606, issued as Accounting Standards Update 2014-09 in May 2014, uses the same model. The IFRS Foundation says IFRS 15 was issued “together with” Topic 606 and applies to annual periods beginning on or after 1 January 2018. The two are not identical in every detail, and FASB publishes a comparison of them, so check which standard your company reports under.

Step	What the standard asks	The SaaS question
1. Identify the contract	Which agreement or agreements exist with the customer	Is the contract the order form, the online terms, or both?
2. Identify the performance obligations	Which distinct promises the contract makes	Is onboarding, support or a term license separate from access?
3. Determine the transaction price	How much consideration you expect to receive	What about discounts, credits and usage fees you cannot know yet?
4. Allocate the price	Split it across the promises by relative stand-alone selling price	Does a “free” onboarding package still take a share of the price?
5. Recognize revenue	As each promise is fulfilled, when the customer obtains control	Is access delivered over the term or at one point in time?

The core principle, in the IFRS Foundation’s words, is that a company “recognises revenue to depict the transfer of promised goods or services to the customer”, in the amount it expects to be entitled to.

How a public SaaS company applies it

Salesforce’s annual report for the year ended January 31, 2026, shows the model at scale (Form 10-K):

Revenue from cloud services is generally recognized ratably over the contract term.
Term licenses are “generally recognized at the point in time when the software is made available to the customer.”
Customers are generally invoiced “in advance, in annual installments”, which is why unearned revenue builds up on the balance sheet.
Remaining performance obligation, the contracted revenue not yet recognized, was about $72.4 billion. About $35.1 billion of it, or 48%, was expected to become revenue in the next 12 months.

The last figure shows the gap between signing and earning: $35.1 billion / $72.4 billion = 0.485, so roughly half of what customers had committed would turn into revenue within a year.

Worked example: a 12-month contract with onboarding

Example: a labeled hypothetical, for illustration only. On January 1 you sign a 12-month contract. Your list prices are $12,000 for a year of access and $3,000 for onboarding, $15,000 in total. You give a 10% discount, so the customer pays $13,500 up front. Assume your accountant concludes that onboarding is a distinct promise, completed in January, and that list prices are the stand-alone selling prices. If the conclusion is instead that onboarding is not distinct, it is combined with access. Its fee is then recognized with the access, not in January, and the table below would change.

Step 4 splits the $13,500 by relative stand-alone selling price:

Access: $12,000 / $15,000 = 80%, and 80% x $13,500 = $10,800, or $10,800 / 12 = $900 a month.
Onboarding: $3,000 / $15,000 = 20%, and 20% x $13,500 = $2,700, recognized when delivered in January.

Date	Event	Revenue this month	Deferred revenue after the event
January 1	Invoice paid, $13,500 cash	$0	$13,500
January 31	Onboarding done, one month of access	$2,700 + $900 = $3,600	$13,500 - $3,600 = $9,900
February 28	One month of access	$900	$9,900 - $900 = $9,000
Each month to December	One month of access	$900	falls by $900
December 31	Last month of access	$900	$0

Check the total: $3,600 + 11 x $900 = $3,600 + $9,900 = $13,500, the full contract. The discount did not land only on onboarding or only on access. Both carry 10% less than list, because step 4 spreads it in proportion.

Bookings in January are $13,500. Revenue in January is $3,600. Neither number is wrong; they answer different questions. Metrics such as MRR and ARR are management measures and are not defined by either standard, so label them when you report them. For how billing events like upgrades and proration show up in those metrics, see SaaS subscription.

Usage fees and multi-year deals

Usage fees. A usage charge is unknown when you sign. Step 3 asks for the amount you expect to be entitled to, so estimates enter the analysis. This is a judgment area: document how you bill usage and take the contracts to your accountant.

Multi-year contracts. A three-year deal billed annually does not change when access is delivered. Revenue still follows delivery, month by month, while billing follows the payment schedule. Remaining performance obligation counts all contracted revenue not yet recognized, billed or not, so it also includes the later years not yet invoiced. The license metric and term in the contract, covered in SaaS licensing, feed directly into steps 2 and 3.

Common mistakes

Booking an annual invoice as revenue in the month it is paid. It makes one month look large and the next eleven look empty. Why it happens: a cash-based ledger records money when it arrives. Instead: record deferred revenue and release it as the service is delivered.
Treating a bundled “free” service as worth nothing. If the package is a distinct promise, step 4 allocates by stand-alone selling price, so it can still take a share of the contract. Why it happens: the invoice line shows $0. Instead: keep a list price for every promise you make.
Reporting bookings or ARR as revenue. Investors and auditors read them as different numbers. Why it happens: bookings are the figure sales celebrates. Instead: show bookings, revenue and deferred revenue side by side, each labeled.
Deciding setup-fee or usage treatment alone. These are the judgment areas of the standards. Why it happens: they look like bookkeeping. Instead: write down the contract terms and get your accountant’s view before the first audit or due diligence.

Sources

IFRS Foundation, IFRS 15 Revenue from Contracts with Customers, checked October 17, 2026.
FASB, Accounting Standards Update 2014-09, Revenue from Contracts with Customers (Topic 606), May 2014.
Salesforce, Inc., Form 10-K for the fiscal year ended January 31, 2026, SEC EDGAR, checked October 17, 2026.

In three sentences

ASC 606 and IFRS 15 share one five-step model: identify the contract and its promises, set and allocate the price, and recognize revenue as each promise is delivered. In the example, a $13,500 prepaid contract produces $3,600 of revenue in January and $900 a month after that, with deferred revenue falling to zero by December. Keep bookings, revenue and deferred revenue apart, and take setup fees, usage charges and bundles to your accountant, because those are the judgment calls.

AI pricing in SaaS: credits, usage and outcome-based models compared

Ricardo Machado — Tue, 27 Oct 2026 16:00:00 GMT

Your team has shipped an AI feature, and finance wants to know how to charge for it. A flat seat price ignores that every AI request costs money to run. A pure meter scares buyers who want a predictable bill. You need to know the models vendors use, and what each one does to your customer’s invoice and to your margin.

AI pricing is how a SaaS vendor charges for features that run on machine-learning models: assistants, agents and generators. It sits on top of the subscription basics in What is SaaS?. The general price structures (seat, tier, usage, freemium) are covered in SaaS pricing models. This guide covers only the AI layer.

AI pricing in plain terms

Think of it like a phone plan. Some plans include calls in the monthly fee. Others give you a bundle of minutes and charge for extra. A few charge only when the call connects. The network costs the carrier money every minute either way. The plan only decides who carries that cost.

AI features work the same way. Each request to a model has a running cost, called inference. A credit is a prepaid unit that the vendor converts into actions at a published rate. An outcome is a finished result, such as a resolved support conversation, that the vendor defines and counts.

The five models vendors use

Every example below comes from the vendor’s own page, checked on October 17, 2026. AI prices change often, so check the date before you rely on one.

Model	What you pay for	Public example	Who carries the usage risk
Bundled in the seat	The per-user price, AI included	Slack lists AI conversation summaries, recaps and AI search inside its per-user plans, with “Advanced AI” on Business+ (Slack)	Vendor
Per-user add-on	A fixed monthly fee per person on top of a base plan	Salesforce lists Agentforce add-ons at $125 per user per month (Salesforce); Microsoft sells Copilot as an add-on to eligible Microsoft 365 plans (Microsoft Learn)	Vendor, for heavy users
Allowance plus credits	A monthly allowance, then a price per extra credit	Atlassian Rovo includes 25 credits per user a month on Jira and Confluence Standard, then $0.01 per credit (Atlassian); GitHub Copilot Pro at $10 a month lists $15 of AI Credits ($10 base plus $5 flex) at $0.01 each (GitHub)	Shared
Per action	Each step an agent takes	Salesforce Flex Credits: $500 per 100,000 credits, 20 credits per standard action, which works out to $0.10 an action	Customer
Per outcome	Each result the vendor counts as done	Intercom prices Fin at $0.99 per outcome (Intercom)	Customer pays per result; vendor absorbs failed attempts

The rows run from most predictable for the buyer to most closely tied to use. Salesforce shows that one vendor can sell several at once: the same page lists per-user add-ons, Flex Credits and a $2 per conversation option.

What each model means on an invoice

Bundled and per-user prices give your customer a fixed bill. The vendor pays for every heavy user out of the same fee. That works while average use stays low.

Credits split the risk. The included allowance covers normal use, and the meter starts above it. Two details decide how this feels in practice. First, whether allowances pool: Atlassian combines an organization’s allowances “into a single shared pool”. Second, what happens at the limit: with extra usage turned off, Atlassian pauses credit-consuming features until the monthly reset. GitHub lets Business and Enterprise admins decide whether paid usage beyond the allowance is allowed; if it is not, Copilot pauses until the next cycle.

Per-action pricing bills the agent’s work, not its success. An agent that takes eight steps to do a three-step job costs more than twice as much.

Per-outcome pricing bills results, so the definition of a result is the contract. Intercom counts an outcome when the customer confirms the issue is resolved, when they do not ask for more help after Fin responds, or when Fin completes a workflow, including handoffs. It charges once per conversation. Its option for teams on another help desk adds a minimum monthly commitment, “e.g. 50 outcomes”.

Worked example: one product priced three ways

Example: a labeled hypothetical. A help-desk vendor sells an AI agent to a customer with 20 support agents. The AI handles 3,000 conversations a month and resolves 1,800 of them, or 60%. Each conversation takes 5 model actions on average, and each action costs the vendor $0.04 in inference.

Vendor’s inference cost: 3,000 x 5 x $0.04 = $600 a month, in every option.
Option A, per-user add-on at $30: 20 x $30 = $600. AI margin: $600 - $600 = $0.
Option B, per action at $0.10: 3,000 x 5 = 15,000 actions x $0.10 = $1,500. Margin: $1,500 - $600 = $900, or 60%.
Option C, per outcome at $0.90: 1,800 x $0.90 = $1,620. Margin: $1,620 - $600 = $1,020, or 63%.

Now change one input at a time.

Scenario	A: per user	B: per action	C: per outcome	Vendor cost
Base: 3,000 conversations, 60% resolved	$600	$1,500	$1,620	$600
Volume doubles: 6,000 conversations, 60% resolved	$600	$3,000	3,600 x $0.90 = $3,240	$1,200
Quality drops: 3,000 conversations, 30% resolved	$600	$1,500	900 x $0.90 = $810	$600

Read the rows. When volume doubles, option A loses $600 a month ($600 - $1,200), because the seat price does not move with use. When quality drops, option B still bills $1,500, while option C falls to $810 and leaves the vendor $210. For the buyer, the cost per resolved conversation in the base case is $600 / 1,800 = $0.33 under A, $1,500 / 1,800 = $0.83 under B and $0.90 under C.

So the seat model protects the buyer’s budget and exposes the vendor. Per-action pricing exposes the buyer to an inefficient agent. Per-outcome pricing ties the vendor’s revenue to the agent’s quality, but only as far as the outcome definition is honest.

Questions to ask before you buy or set an AI price

What exactly is one unit: a credit, an action, a conversation or an outcome? Get the definition in writing.
How many credits does one task use? Salesforce charges 20 credits for a standard action and 30 for a voice action.
Do included allowances pool across users, or does each person keep their own?
At the limit, does the feature pause or bill overage? Who decides?
Is there a minimum commitment?
Can the conversion rate change? Figma’s pricing page says “Included AI credits are subject to change”, and Salesforce marks its page as subject to change.

For how these meters fit into renewals and proration, see SaaS subscription.

Common mistakes

Bundling AI into the seat without measuring use. In the example, doubling volume turns a break-even add-on into a $600 monthly loss. Why it happens: seat prices are easy to sell and easy to forecast. Instead: meter AI use per account internally, even if you do not bill for it.
Comparing credit prices without the conversion rate. One cent per credit means nothing until you know how many credits a task uses. Why it happens: the credit price is on the pricing page, the conversion is in the docs. Instead: convert every offer to a cost per finished task.
Accepting an outcome definition you have not read. Intercom’s definition counts a conversation where the customer does not ask for more help, and a completed handoff. Why it happens: “pay only for results” sounds safe. Instead: sample billed outcomes each month and check that they were resolved.
Ignoring what happens at the limit. A paused agent in the middle of a busy week can cost more than the overage. Why it happens: limits only matter once you hit them. Instead: decide in advance whether a pause or an overage bill hurts more, and set the budget control to match.

Sources

Intercom, Pricing, checked October 17, 2026.
Salesforce, Agentforce pricing, checked October 17, 2026.
Atlassian, Rovo pricing, checked October 17, 2026.
GitHub, Copilot plans, checked October 17, 2026.
Slack, Pricing; Figma, Pricing, checked October 17, 2026.
Microsoft Learn, License options for Microsoft Copilot, checked October 17, 2026.

In three sentences

SaaS vendors charge for AI in five ways: bundled in the seat, as a per-user add-on, as an allowance plus credits, per action, or per outcome. In the example, the same agent earns $600, $1,500 or $1,620 a month depending on the model, and doubling usage turns the seat add-on into a $600 loss. Before you buy or set a price, convert every offer to a cost per finished task and read the unit definition and the limit behavior in writing.

Workflow automation tools: how no-code automation works, from triggers to AI steps

Ricardo Machado — Tue, 27 Oct 2026 11:00:00 GMT

Every day someone on your team copies a form entry into the help desk, pastes a summary into chat and sends the same reply by hand. You have heard that tools such as Zapier, Make and n8n can do this, and you want to know how a flow is built and what it costs to run. Workflow automation tools connect your SaaS apps with rules you set: when something happens in one app, they carry out steps in others, without code.

Knowing the parts of a flow tells you what to build, what can break and how the tool will bill you. This guide covers triggers, actions, filters, AI steps and error handling, then counts the billable units of one flow, step by step. For the basics of the apps being connected, see What is SaaS?.

Workflow automation in plain terms

Think of a mailroom clerk with a card of rules on the desk. When a letter arrives, the clerk reads the envelope. Bills go to finance, complaints go to the manager with a copy to the log, and junk goes in the bin. The clerk never decides what the rules should be; the clerk follows the card, every time, all day.

A workflow automation tool is that clerk for your apps. The letter arriving is the trigger. Sorting is a filter or a branch. Each delivery is an action. The card of rules is the flow you build.

The rules are fixed in advance. Anthropic’s Building effective agents (December 19, 2024) calls these “predefined code paths”, and that is what separates a workflow from an AI agent, which picks its own next step.

The building blocks

Trigger. The event that starts a run: a new form entry, a new row, an incoming email, a schedule.
Actions. What happens in other apps: create a ticket, add a CRM contact, send a message.
Filters and branches. Conditions that stop a run or send it down one of several paths.
Data mapping. Choosing which field from one step fills which field in the next, and formatting dates, names and amounts on the way.
AI steps. A language model call inside the flow. The three common uses are classify (which category is this?), extract (pull the order number out of an email) and draft (write a first reply).
Error handling. What happens when a step fails: retry, take an error path, alert a person.

AI steps change one thing about a flow: their output is not guaranteed. A classifier can put a refund request in the wrong bucket. Keep a person in front of anything that leaves the company. Microsoft’s AI agent shared responsibility model recommends human approval for actions such as “external sends”, and the same rule fits AI steps in a workflow.

How tools count what you pay for

Each tool bills a different unit, which is why the same flow can cost very different amounts. Checked on October 17, 2026:

Tool	Billing unit	What counts	Source
Zapier	Task	Each successful action; triggers, filters and paths do not count; AI step usage depends on the model tier	Zapier help, updated August 21, 2026
Make	Credit	By default one operation equals one credit for fixed-usage modules; AI modules can also consume credits by tokens	Make help, credits
n8n	Execution	“a single run of your entire workflow”, whatever the number of steps	n8n pricing

n8n’s cloud plans listed 2,500 executions a month on Starter at 20 euros a month and 10,000 on Pro at 50 euros, billed annually. A full price comparison of the three tools belongs in a separate guide; the point here is the unit.

One flow, counted step by step

Example: a hypothetical support intake flow with 600 form submissions a month.

The flow:

Trigger: new form submission.
Filter: stop entries that look like spam.
AI step: classify the request as billing, technical or urgent.
Action: create a ticket in the help desk.
Branch: if urgent, post a message to the on-call chat channel.
Action: send an acknowledgement email to the customer.

Assumptions: the filter stops 20% of entries, 15% of the remaining entries are urgent, and the AI step uses 1 task at the chosen model tier (check the tier you pick, since Zapier says usage depends on it).

Entries that pass the filter: 600 x 80% = 480.
Tasks per passing entry without the branch: AI step + ticket + email = 3.
Base tasks: 480 x 3 = 1,440.
Urgent entries: 480 x 15% = 72, each adding 1 chat message = 72 tasks.
Spam entries: 120 runs, using 0 tasks, because the trigger and the filter do not count.
Total in Zapier’s unit: 1,440 + 72 = 1,512 tasks a month.

In n8n’s unit, every run of the workflow is one execution. All 600 submissions start a run, so the flow uses 600 executions a month, whether a run stops at the filter or goes all the way.

Same flow, two very different numbers: 1,512 in one tool, 600 in another. Neither is cheaper in general. Per-step units reward short flows; per-run units reward long ones.

Error handling that holds up

A flow that works on day one breaks later, usually because something outside it changed: a field renamed, a token expired, an app down for an hour. Build for that from the start:

Retries for temporary failures, with a limit.
An error path that records the failed entry and its data, so nothing is lost silently.
An alert to a named person, not a shared inbox nobody reads.
A weekly check of failed runs, even when no alert fired.

Error paths can cost money too. Zapier counts successful actions inside error handler paths as tasks, so include them in your estimate.

For how apps connect underneath (APIs, OAuth and webhooks), see SaaS integration. Flows that write to your CRM are covered in CRM SaaS, and rolling a new tool out to a team in SaaS implementation.

Common mistakes

Estimating cost from runs instead of the tool’s unit. A six-step flow can bill three units per run in one tool and one in another. Why it happens: “runs per month” is the number people know. Instead: count units per run for each path, then multiply by volume, as in the example.
Letting an AI step send messages unreviewed. A misclassified complaint can get the wrong reply. Why it happens: the demo worked on the first ten entries. Instead: route AI drafts to a person for approval, or limit them to internal steps.
No error path. Failed runs disappear and nobody notices until a customer chases. Why it happens: flows are built for the happy path. Instead: add an error path, an alert to a named owner and a weekly review.
Automating a process nobody has written down. The flow copies today’s confusion faster. Why it happens: the tool makes building quick. Instead: write the steps and the exceptions on one page first, then build.

Sources

Zapier, How is task usage measured in Zapier, updated August 21, 2026, checked October 17, 2026.
Make, Credits, checked October 17, 2026.
n8n, Pricing, checked October 17, 2026.
Anthropic, Building effective agents, December 19, 2024.
Microsoft Learn, AI agent shared responsibility model, checked October 17, 2026.

In three sentences

Workflow automation tools run fixed rules across your SaaS apps: a trigger starts a run, filters and branches route it, actions do the work and AI steps can classify, extract or draft. Each tool bills a different unit, so the same 600-submission flow costs 1,512 tasks in Zapier’s unit and 600 executions in n8n’s. Count units per path before you buy, keep a person in front of AI output that leaves the company, and give every flow an error path with a named owner.

SaaS on Azure: what Microsoft's cloud offers SaaS builders and buyers

Ricardo Machado — Mon, 26 Oct 2026 21:00:00 GMT

You searched for “Azure SaaS” and found three different things: Microsoft’s own apps, guides to building software on Azure, and a marketplace full of other companies’ products. You want to know which one applies to you. Azure, Microsoft’s cloud, mostly sells infrastructure and platform services that other companies build on. “Azure SaaS” usually means a software company running its product on Azure, selling it through Microsoft Marketplace, or both.

The difference decides who secures what and who takes a cut of your revenue. This guide covers where SaaS sits in Azure’s service models, Microsoft’s four tenancy models for SaaS builders, the Marketplace fee with the arithmetic, and a short comparison with AWS. For what SaaS is, see What is SaaS?. For the line between SaaS and the platforms it runs on, see SaaS vs PaaS.

Azure and SaaS in plain terms

Think of a shared commercial kitchen. The owner rents cooking stations to independent chefs, supplies the ovens and the power, and keeps the building safe. The owner also cooks a few dishes of its own under its own brand. At the front, a counter sells the tenants’ dishes to walk-in customers and keeps a small fee per sale.

Azure is the kitchen. Microsoft’s own dishes are Microsoft 365 and Dynamics 365, which are SaaS. The independent chefs are SaaS companies that rent compute and databases and sell their own applications. The front counter is Microsoft Marketplace.

Microsoft’s shared responsibility page (updated August 24, 2026) sorts its services the same way. Infrastructure as a service (IaaS) means you manage virtual machines, operating systems and applications. Platform as a service (PaaS) means you “deploy applications without managing VMs or operating systems”, with examples such as Azure App Service, Azure Functions and Azure SQL Database. SaaS means “You use ready-made applications”, with Microsoft 365 and Dynamics 365 as examples.

Who secures what

When you build a SaaS product on Azure PaaS, Microsoft’s responsibility matrix puts the operating system, physical hosts and datacenter on Microsoft’s side. Applications and network controls are shared. Customer data, configurations and identities stay with the customer in every model. The page adds: “For all cloud deployment types, you own your data and identities.”

For a SaaS company, the customer in that matrix is you. Your tenants’ data, your access rules and the way you keep tenants apart are your job, whatever Azure runs underneath.

Four ways to arrange tenants

A tenant is one customer of your SaaS product, usually a company and its users. Microsoft’s Azure Architecture Center separates the ideas: “SaaS is a business model”, while multitenancy “is a way of architecting a solution to share components between multiple tenants”. Its tenancy models guide names four common models. The last column is a rough match to the terms AWS uses, added for readers who know both clouds.

Azure model	What tenants share	Microsoft’s stated trade-off	Closest AWS term
Automated single-tenant deployments	Nothing: each tenant gets its own infrastructure	Strong isolation; low cost efficiency	Silo
Fully multitenant	Everything	Lowest cost; a change or failure can reach every tenant	Pool
Vertically partitioned	Most tenants share; some get dedicated deployments	Shared savings plus isolation where it is paid for; code must support both	Mixed tiers (pool and silo)
Horizontally partitioned	Shared application tier, separate components such as a database per tenant	Limits noisy neighbors on the heavy component	Between bridge and silo

Microsoft puts the cost of the first model bluntly: “If a single tenant requires a specific infrastructure cost, 100 tenants probably require 100 times that cost.” For the vertically partitioned model, Microsoft suggests cheaper shared resources for customers on a trial, and a higher rate for customers who want a single-tenant deployment.

Selling through Microsoft Marketplace

Microsoft Marketplace lets Azure customers buy your SaaS product with Microsoft billing them. Microsoft’s transact capabilities page (updated August 18, 2026) sets the rules:

Fee: “Microsoft charges a 3% standard store service fee when customers purchase your transact offer.” A 50% discount on that fee can apply to private offer renewals for qualifying customers.
Requirements for SaaS: the product “Must be a multitenant solution, use Microsoft Entra ID for authentication, and integrate with the SaaS Fulfillment APIs”.
Pricing models: flat rate, per user and usage-based, with metered billing on up to 30 custom dimensions per offer.
Infrastructure: your Azure costs are billed to you, not to the buyer, so they belong inside your price.
Terms: free trials of 1 to 180 days, and contract durations of up to five years.

Example: you sell a three-year SaaS contract worth $240,000 as a private offer.

Standard fee: $240,000 x 3% = $7,200, so you receive $240,000 - $7,200 = $232,800 before your own costs.
At renewal, with the 50% fee discount: 3% x 50% = 1.5%, so $240,000 x 1.5% = $3,600.
Microsoft’s own illustration: a $100.00 monthly license pays out $97.00, with $3.00 kept by Microsoft.

Azure and AWS, briefly

The two marketplaces start at the same rate for this deal and differ at the edges. AWS figures are from its listing fees page, checked October 17, 2026, and are covered in AWS SaaS.

Item	Microsoft Marketplace	AWS Marketplace
Standard SaaS fee	3%	3% public offer; private offers 3% under $1M
Large private offers	3% standard, unless otherwise specified	2% from $1M; 1.5% from $10M
Renewals	50% discount on the fee for qualifying private offer renewals	1.5%
Identity requirement for SaaS	Microsoft Entra ID	Not part of the fee page
Tenancy guidance names	Single-tenant, fully multitenant, vertical, horizontal	Silo, bridge, pool

On a $1,200,000 private offer, the standard rates give $1,200,000 x 3% = $36,000 at Microsoft and $1,200,000 x 2% = $24,000 at AWS. Large deals can carry negotiated terms, so model your own case with the current pages.

If your buyers already run Microsoft 365, Entra ID sign-in is one less integration for them; see Microsoft 365 as SaaS.

Common mistakes

Calling a product SaaS because it runs on Azure. Software installed on the buyer’s own Azure virtual machines is still software the buyer runs. Why it happens: “cloud” covers both. Instead: ask who operates the application and whether the buyer only signs in.
Assuming Microsoft secures your tenants. Data, identities and configuration stay with you in every model. Why it happens: a large provider feels like a guarantee. Instead: write down which controls are yours and who owns each one.
Leaving Azure costs out of the Marketplace price. For SaaS offers, infrastructure is billed to you, not to the buyer. Why it happens: on other offer types the buyer pays the Azure bill. Instead: price the license to cover hosting, the 3% fee and margin.
Choosing single-tenant deployments for everyone. Cost grows with each tenant, and every deployment needs updates. Why it happens: full isolation is the easiest answer to a security questionnaire. Instead: share by default and sell dedicated deployments as a paid tier.

Sources

Microsoft Learn, Shared responsibility in the cloud, updated August 24, 2026, checked October 17, 2026.
Microsoft Learn, SaaS and multitenant solution architecture and Tenancy models for a multitenant solution, checked October 17, 2026.
Microsoft Learn, Microsoft Marketplace transact capabilities, checked October 17, 2026.
AWS, Listing fees for AWS Marketplace sellers, effective January 5, 2024, checked October 17, 2026.

In three sentences

Azure mostly sells infrastructure and platform services, and “Azure SaaS” usually means a SaaS company that runs its product on Azure, sells it through Microsoft Marketplace, or both. Microsoft describes four tenancy models, from a dedicated deployment per tenant to fully shared, and you keep responsibility for data, identities and tenant isolation in all of them. Marketplace SaaS offers pay a 3% standard fee, so a $240,000 private offer pays $7,200, and the product must be multitenant, use Entra ID and integrate the SaaS Fulfillment APIs.

SaaS SLAs: uptime, support and service credits explained

Ricardo Machado — Mon, 26 Oct 2026 16:00:00 GMT

A vendor promises “99.9% uptime”, your team depends on the product every day, and you need to know what that promise is worth when the service goes down. The answer is in the service level agreement (SLA): the part of the contract that sets a measurable commitment, such as uptime, and what the vendor owes you when it misses it.

Most SaaS SLAs promise less than the headline suggests, and pay less than an outage costs you. This guide turns uptime percentages into minutes, takes an SLA apart clause by clause, compares two published SLAs and works a service credit through. For the basics of software delivered as a service, see What is SaaS?.

An SLA in plain terms

Think of a pizza shop that promises delivery within 30 minutes or your next pizza is free. If the pizza is late, you do not get your party back. You get a voucher, and only if you ask for it, and not if the delay was caused by a snowstorm.

An SLA works the same way. The vendor commits to a number. If it misses, you can claim a service credit: extra days of service or a discount on a future bill. The credit is a small refund, not compensation for what the outage cost your business.

The parts of an SLA

Read every SLA for these seven parts:

The commitment. Usually a monthly uptime percentage, such as 99.9%.
The measurement window. Most measure per calendar month, so a bad day is averaged over the month.
The definition of downtime. This decides what counts. A total outage counts everywhere; a slow or partly broken service may not.
Exclusions. Scheduled maintenance, force majeure, your own network and third-party products are commonly excluded.
Service credits. A table that maps uptime ranges to a credit.
The claim process. Who must ask, how and by when. Credits are rarely automatic.
Caps and sole remedy. A maximum credit, and often a clause that the credit is your only remedy for the outage.

Support response times are a separate commitment, sometimes in the SLA and sometimes in a support policy. Check whether they promise a first response or a fix, and for which severity levels.

What uptime means in minutes

A 30-day month has 30 x 24 x 60 = 43,200 minutes. A 365-day year has 525,600. The allowed downtime is the share of those minutes not covered by the commitment.

Uptime commitment	Allowed downtime per 30-day month	Allowed downtime per year
99%	43,200 x 1% = 432 minutes (7.2 hours)	5,256 minutes (87.6 hours)
99.5%	216 minutes (3.6 hours)	2,628 minutes (43.8 hours)
99.9%	43.2 minutes	525.6 minutes (8.76 hours)
99.95%	21.6 minutes	262.8 minutes (4.38 hours)
99.99%	4.32 minutes	52.56 minutes

Each extra nine cuts allowed downtime by a factor of ten. Moving from 99.9% to 99.99% takes the monthly allowance from 43.2 minutes to under 5.

Two published SLAs compared

Two vendors publish their SLA terms in full. Their numbers are close; their mechanics differ.

Clause	Google Workspace	Atlassian cloud
Commitment	99.9% monthly uptime	99.9% on Premium, 99.95% on Enterprise
Downtime means	More than a 5% user error rate	A minute with an error rate above 5%
Credit, below 99.9% down to 99.0%	3 days of service added	10% (Premium and Enterprise)
Credit, below 99.0% down to 95.0%	7 days	25%
Credit, below 95.0%	15 days	50%
Extra tier	None	Enterprise: 5% below 99.95% down to 99.9%
Claim deadline	Support case within 30 days of becoming eligible	Ticket within 15 days after the end of the month
Cap	15 days of service per month	Read the full terms
Page date	Last modified August 31, 2026	Effective April 30, 2026

Sources: Google Workspace SLA and Atlassian cloud SLA, both checked October 17, 2026. Atlassian excludes routine scheduled maintenance and reasonable emergency maintenance under its maintenance policy.

Not every vendor publishes a number. Slack’s public service level page (effective July 11, 2024) promises “commercially reasonable efforts” to keep the service available around the clock, with no percentage. Paid enterprise contracts may say more. The point stands: the SLA that binds you is the one in the contract you sign.

A credit, worked through

Example: a hypothetical team pays $12,000 a month for a SaaS product. In a 30-day month, the service is down for 2 hours.

Downtime: 2 x 60 = 120 minutes.
Share of the month: 120 / 43,200 = 0.28%.
Uptime: 100% - 0.28% = 99.72%, below 99.9% and above 99.0%.
Under tiers like Atlassian’s Premium table, assuming the credit applies to the full monthly fee: $12,000 x 10% = $1,200.
Under tiers like Google’s: 3 days of service. At $12,000 / 30 = $400 a day, that is worth 3 x $400 = $1,200.

Now the cost of the same outage to the business. If 200 staff lose 2 hours each at a loaded cost of $50 an hour: 200 x 2 x $50 = $20,000. The credit covers $1,200 / $20,000 = 6% of it. Plan for outages with your own workarounds; the credit will not fund them.

Checklist

Before you sign, tick each line:

The uptime percentage, measurement window and downtime definition are written down, not only on a marketing page.
Partial outages that block your main use case count as downtime.
Scheduled maintenance has a notice period and a cap on hours.
You know the claim deadline, and someone owns the claim.
Support terms state response times per severity level.
You run your own monitoring, so you can prove the outage minutes.
Your plan for a long outage does not depend on the credit.

For monitoring, the vendor’s status page is a start, but it reports what the vendor sees. A simple external check that signs in and loads a page every few minutes gives you your own record. Put SLA review into vendor selection, see how to evaluate SaaS solutions, and into the contract stage of enterprise SaaS deals.

Common mistakes

Reading 99.9% as “almost never down”. It allows 43.2 minutes a month, more than 8.7 hours a year. Why it happens: the percentage looks close to 100. Instead: convert every commitment to minutes before comparing vendors.
Missing the claim deadline. Credits are rarely automatic: 30 days at Google, 15 days after month end at Atlassian. Why it happens: nobody owns the claim during the incident. Instead: assign an owner and log outage times as they happen.
Treating the credit as insurance. A $1,200 credit against a $20,000 loss covers 6%. Why it happens: the SLA reads like a guarantee. Instead: plan workarounds and, for critical systems, negotiate higher credits or termination rights for repeated misses.
Ignoring the downtime definition. A slow or partly broken service may not count. Why it happens: the definition sits deep in the document. Instead: read it first, and ask how the vendor measures error rates.

Sources

Google, Google Workspace Service Level Agreement, last modified August 31, 2026, checked October 17, 2026.
Atlassian, Cloud service level agreement, effective April 30, 2026, checked October 17, 2026.
Slack, Service level agreement, effective July 11, 2024, checked October 17, 2026.

In three sentences

A SaaS SLA sets a measurable commitment, usually monthly uptime, and the service credit you can claim when the vendor misses it. A 99.9% commitment still allows 43.2 minutes of downtime a month, and the downtime definition, exclusions and claim deadline decide what you can actually recover. Credits are small next to the cost of an outage, such as $1,200 against $20,000 in the example, so convert every promise to minutes, monitor it yourself and plan your own workarounds.

AI copilots in SaaS apps: what they are, how they work and what they cannot do

Ricardo Machado — Mon, 26 Oct 2026 11:00:00 GMT

The apps you already pay for now have a sidebar that drafts emails, summarizes meetings and answers questions about your files. You need to know what it can see, how far you can trust it and whether the extra seat price is worth paying. An AI copilot is an assistant built into a software product that uses a language model to help a person do a task in that product. The person reviews the result and decides what happens next.

That last sentence is the line between a copilot and an agent, and it decides most of the risk. This guide covers how copilots work, what they typically do, what they cannot do, and how to check the seat cost before you buy. For the basics of the software they sit in, see What is SaaS?.

Copilots in plain terms

Think of a co-driver in a rally car. The co-driver reads the notes, calls the next bend and warns about the ditch. The driver keeps both hands on the wheel. If the co-driver misreads a note, the driver can still brake.

A copilot is the co-driver. It suggests, drafts and summarizes; you accept, edit or ignore. An agent, by contrast, takes the wheel for a stretch. Microsoft’s AI agent shared responsibility model describes an agent as one that “invokes tools, calls APIs, writes data, and triggers workflows without a human approving each step”.

GitHub’s description of GitHub Copilot shows both modes in one product. For assistive features, “You review and apply each suggestion.” For its agentic features, where Copilot works through several steps toward a goal, “You remain responsible for reviewing and approving.”

How a copilot works

Microsoft’s data, privacy and security page for its Microsoft 365 assistant (updated October 8, 2026) names three parts, a pattern most copilots share:

A large language model that reads and writes text.
Your organization’s content, “such as emails, chats, and documents that you have permission to access”.
The app you are working in, such as Word or PowerPoint.

The page also records a rename: Microsoft 365 Copilot is now called Microsoft Copilot, and some licenses may keep the old name during the transition.

The second part is the one to understand. Before the model answers, the copilot retrieves content that matches your request and adds it to the prompt. This is called grounding. Microsoft states that its copilot “only surfaces organizational data to which individual users have at least view permissions”. It also states that prompts, responses and data accessed through Microsoft Graph “aren’t used to train foundation LLMs”. Other vendors make their own commitments, so read each vendor’s terms rather than assuming the same.

What copilots typically do

Microsoft’s Copilot overview (updated October 14, 2026) lists in-app features. Together with GitHub’s, they show the usual pattern: draft, summarize, analyze, explain.

App	What the copilot does (vendor’s description, checked October 2026)	Who acts on the result
Word	Draft, rewrite and summarize documents	You
Excel	Analyze data, create formulas and visuals	You
Outlook	Draft emails and summarize threads	You send
Teams	Summarize and transcribe meetings, capture action items	You follow up
GitHub	Inline code suggestions; answers about files and repositories	You review and apply
GitHub, agentic features	Works through several steps, edits files, prepares pull requests	You review and approve

The last row is where a copilot product starts to behave like an agent. The approval step is still yours, but more happens before it.

What copilots cannot do

Guarantee accuracy. Microsoft’s own page says the responses that generative AI produces “aren’t guaranteed to be 100% factual”, and that users should use their judgment before sending output to others. A summary can drop the one sentence that mattered. A formula can look right and reference the wrong column.

Fix your permissions. A copilot that respects permissions also respects bad ones. If a salary spreadsheet is shared with the whole company, the copilot can surface it to anyone who asks the right question. Microsoft points admins to SharePoint Advanced Management, which “helps you reduce oversharing”, for this reason. The copilot did not create the exposure; it made it easy to find.

Know what it was not given. A copilot sees what it retrieves for that request. Content in a system it is not connected to does not exist for it.

Act on its own, by design. That is a feature. When you need actions taken without review, you are buying an agent, with a different risk profile.

The seat cost, worked through

Copilots are usually sold as a per-user add-on. Prices change often, so check the vendor’s page on the day you buy.

Example: GitHub lists Copilot Business at $19 per granted seat per month and Copilot Enterprise at $39 (checked October 17, 2026). A team of 40 developers, with a hypothetical loaded cost of $75 an hour per developer:

Business, yearly: 40 x $19 x 12 = $9,120.
Enterprise, yearly: 40 x $39 x 12 = $18,720.
Break-even on Business: $19 / $75 = 0.25 hours, about 15 minutes saved per developer per month.
Break-even on Enterprise: $39 / $75 = 0.52 hours, about 31 minutes per developer per month.

The seat price is a floor, not a cap. GitHub’s plans documentation says each Business seat adds 1,900 AI Credits to a shared pool. Use beyond the pool is billed at $0.01 a credit if your admins allow it. The break-even is low, which is why the real question is usage, not price. If only 25 of the 40 developers use it, the Business cost per active user is $19 x 40 / 25 = $30.40 a month. Measure active use for a month or two before you buy seats for everyone. For how seat-based licenses work in general, see SaaS licensing.

Common mistakes

Rolling out before cleaning up sharing. The copilot surfaces whatever each person can already open. Why it happens: oversharing was invisible until search got this good. Instead: review sharing on sensitive sites and files before switching the copilot on.
Treating output as fact. Drafts and summaries can be wrong in ways that read well. Why it happens: the text is fluent and confident. Instead: check anything that leaves your team, and keep the human review step in every process.
Buying seats for everyone on day one. Unused seats raise the real cost per active user. Why it happens: the vendor’s bundle price looks simpler. Instead: start with a pilot group and use the vendor’s usage reports to decide on the rest.
Calling a copilot an agent, or the reverse. The approvals and permissions you need differ. Why it happens: vendors use both words for the same product. Instead: ask who acts on the output and whether a person approves each action.

For how Microsoft’s and Google’s suites package their tools, see Microsoft 365 as SaaS and Google Workspace as SaaS.

Sources

Microsoft Learn, Data, privacy and security for Microsoft Copilot and What is Microsoft Copilot?, checked October 17, 2026.
Microsoft Learn, AI agent shared responsibility model, checked October 17, 2026.
GitHub Docs, What is GitHub Copilot? and GitHub Copilot plans, checked October 17, 2026.

In three sentences

An AI copilot is an assistant inside a SaaS app that drafts, summarizes and analyzes using your data, while a person reviews and acts on the result. It sees what you already have permission to open, so oversharing becomes visible, and its output is not guaranteed to be accurate. Seat prices such as GitHub’s $19 a month break even at minutes of saved work, so measure who actually uses it before you buy seats for everyone.

Headless SaaS: what API-first software means for builders

Ricardo Machado — Sun, 25 Oct 2026 21:00:00 GMT

A vendor has told you its product is “headless” or “API-first”, and you need to know whether that helps your team or just adds work. The terms describe one design choice. Headless SaaS is a hosted service that runs the back end (data, rules, checkout, accounts) and hands you an API instead of a finished front end. You build the screens your customers see.

That choice moves cost and control from the vendor to you. This guide explains what headless means for content, commerce and payments, what you gain, what it costs, and how to tell whether it fits. For the basics of software delivered as a service, see What is SaaS?. For the difference between a SaaS product and a platform you build on, see SaaS platform.

Headless in plain terms

Think of a restaurant kitchen that does not have a dining room. It cooks for anyone who orders: a delivery app, a food truck, a stand at a stadium. Each outlet has its own look and its own menu board. The kitchen only promises that when an order comes in, the food goes out.

A traditional SaaS product is the restaurant with the dining room: the kitchen and the tables come together, and the tables look the way the owner decided. A headless product is the kitchen alone. The “head” is the front end, the part people see and click. The API (application programming interface) is the order window: a defined way for your code to ask the service for data or to make it do something.

Shopify’s developer documentation puts it in one line: “Headless commerce separates your storefront’s frontend from its backend” (Shopify, headless).

API-first is the design habit behind it. The vendor designs the API as the main product, and any screens it ships are built on that same API.

Where you meet headless SaaS

Content. A headless content management system (CMS) stores articles, product copy and images, and returns them as structured data. The same entry can feed your website, your app and an in-store screen.
Commerce. Shopify’s Storefront API “serves products, collections, search, and the cart, and hands customers off to checkout”. Shopify offers Hydrogen, its toolkit for building the storefront in JavaScript, and Oxygen to host it, or you host it elsewhere.
Payments. Stripe’s online payments guide offers a spectrum. At one end is a prebuilt payment page it hosts. At the other is a lower-level API, Payment Intents, where you build the checkout yourself. Stripe recommends its Checkout Sessions API for most integrations. It warns that the lower-level path means much more code and ongoing maintenance, because you rebuild discounts, tax and currency logic yourself.
Accounts and search. Sign-in, permissions and search are also sold as services you call from your own screens.

The pattern is the same each time. The vendor runs the hard back-end parts, and the more of the front end you take on, the more control and the more work you get.

Coupled vs headless

Question	Coupled SaaS (vendor’s front end)	Headless SaaS (your front end)
Who builds what customers see	The vendor, through themes and templates	Your developers
Time to launch	Days to weeks	Longer: you build and test every screen
Design freedom	Within the vendor’s templates	Anything your team can build
Channels	Usually one: the vendor’s site	Any: web, app, kiosk, partner sites
Hosting the front end	Included	Yours, or the vendor’s add-on
Who fixes a broken page	The vendor	You
Cost profile	Mostly the subscription	Subscription plus build, hosting and maintenance

Shopify is unusually candid about the last row: “A headless storefront costs more to build and run than a theme.” It says to confirm the merchant accepts the added cost and complexity, and has developers to maintain the storefront after launch.

The cost, worked through

Two costs surprise teams that move to headless: API traffic and maintenance hours.

Example: a hypothetical store with 300,000 page views a month. Each page makes 3 API calls to the commerce and content services.

Calls before caching: 300,000 x 3 = 900,000 a month.
With a cache in front that answers 95% of calls, the services receive 900,000 x 5% = 45,000 calls.
If a bug turns the cache off, the services suddenly receive all 900,000, 20 times the usual load.

Check each vendor’s rate limits and pricing against the uncached number, not only the cached one.

Maintenance is the second cost. Suppose the front end needs 12 developer hours a month for fixes, framework upgrades and new campaign pages, at a loaded cost of $90 an hour.

Monthly: 12 x $90 = $1,080.
Yearly: $1,080 x 12 = $12,960.

With a coupled product, most of that work is the vendor’s, priced into the subscription. With headless, it is a line in your budget for as long as the storefront exists.

Checklist

Tick each line before you choose a headless product:

You need a channel or a design the vendor’s templates cannot deliver.
You have developers who will own the front end after launch, not only build it.
You know which features the vendor’s front end gave you for free (search pages, account pages, checkout) and who rebuilds them.
You have priced front-end hosting, monitoring and a cache.
You have checked API rate limits against traffic with the cache off.
You know how you will preview content before it goes live.

If you tick fewer than four, a coupled product with an API for the parts you need is usually the safer start. Connecting it to the rest of your stack is covered in SaaS integration. For online stores in particular, see ecommerce SaaS.

Common mistakes

Choosing headless for speed. A headless launch is slower because you build every screen. Why it happens: “modern” sounds faster. Instead: choose it for control or channels, and plan a longer first release.
Budgeting only for the build. The front end keeps needing upgrades and fixes. Why it happens: the project ends, the code does not. Instead: put monthly maintenance hours in the budget before you sign.
Forgetting what the vendor’s front end did. Search pages, account pages and checkout edge cases vanish with the theme. Why it happens: nobody listed them because they just worked. Instead: inventory the vendor’s pages and decide which you rebuild and which you keep hosted.
Dropping to the lowest-level API too early. Stripe’s own guidance says the lower-level path means rebuilding tax, discount and currency logic. Why it happens: full control looks attractive on day one. Instead: start with the highest-level API that meets your needs and go lower only for a specific gap.

Sources

Shopify, Headless storefronts, checked October 2026.
Stripe, Online payments, checked October 2026.

In three sentences

Headless SaaS runs the back end, such as content, commerce, payments or accounts, and gives you an API instead of a finished front end, so you build every screen your customers see. You gain design freedom and any number of channels, and you take on the build, the hosting and every fix after launch. Choose it when templates cannot do what you need and you have developers to own the front end; otherwise, start coupled and use the API only where you need it.

B2C vs B2B SaaS: business models, pricing and growth compared

Ricardo Machado — Sun, 25 Oct 2026 16:00:00 GMT

You are deciding whether your product should sell to consumers or to companies, or you are comparing your churn with a benchmark and the numbers make no sense. Both problems have the same cause: B2C and B2B SaaS run on different economics. B2C (business to consumer) SaaS sells subscriptions to individuals and households. B2B (business to business) SaaS sells them to organizations.

The split decides your price, how you acquire customers, how fast they leave and what support you owe them. This guide compares the two side by side, works the unit economics through for each, looks at public companies that report both kinds of customer, and explains B2B2C. For the basics of the delivery model itself, see What is SaaS?.

B2C and B2B SaaS in plain terms

Think of a coffee cart and an office caterer. The cart sells thousands of cheap cups to people walking by. Each sale is small, takes seconds, and the customer may never come back. The caterer signs a contract with a company to feed 200 staff every day. Winning that contract takes weeks of meetings, but it pays every month and is hard to walk away from.

B2C SaaS is the coffee cart: low prices, many buyers, fast decisions, high turnover. B2B SaaS is the caterer: higher prices, fewer buyers, slow decisions, longer relationships.

Microsoft’s Azure Architecture Center states the split plainly: “SaaS products are sold either to businesses in a business-to-business (B2B) model or directly to consumers in a business-to-consumer (B2C) model.” Its tenancy guidance shows the split reaches the architecture too. In B2B, one customer organization is usually one tenant with many users. In B2C, a tenant may be one person or a family, and personal data and data-sovereignty laws weigh more.

Side by side

The table below sets out the usual pattern. Individual products break these rules, so treat each row as a question to ask about your own business, not a law.

Dimension	B2C SaaS	B2B SaaS
Who pays	One person or household, with their own card	An organization, through a budget owner
Who decides	The same person, often in minutes	Several people: user, manager, IT, security, finance
Price point	Low monthly prices	Higher prices, often per seat or per account
Billing	Card, monthly or annual, self-serve	Card for small teams; invoices and contracts for larger ones
Acquisition	App stores, search, content, word of mouth, free tiers	Sales teams, partners, self-serve for small teams
Churn	High monthly churn is common	Lower churn, often tied to annual contracts
Expansion	Upgrades to a higher plan, family plans	More seats, more teams, higher tiers
Support	Help center and email, at low cost per user	Account managers, onboarding, uptime commitments
What the tenant is	A person or a family	A company and its employees

The economics, worked side by side

The two models can be equally healthy with very different numbers. The arithmetic shows why benchmarks from one side mislead the other.

Example: two hypothetical products, both at an 80% gross margin.

Input or result	B2C product	B2B product
Price	$12 per month	$600 per month per account
Monthly churn	6%	1.5%
Acquisition cost (CAC)	$40 per subscriber	$9,000 per account
Monthly gross profit	$12 x 80% = $9.60	$600 x 80% = $480
Lifetime value (LTV)	$9.60 / 0.06 = $160	$480 / 0.015 = $32,000
LTV:CAC	$160 / $40 = 4.0	$32,000 / $9,000 = 3.6
CAC payback	$40 / $9.60 = 4.2 months	$9,000 / $480 = 18.8 months

Both ratios look healthy. The difference is in volume and speed. To reach $1,000,000 in annual recurring revenue:

B2C: $1,000,000 / ($12 x 12) = 6,944 subscribers.
B2B: $1,000,000 / ($600 x 12) = 139 accounts.

Now count the customers you lose each month at that size. The B2C product loses 6,944 x 6% = 417 subscribers a month, so it must win 417 new ones just to stand still. The B2B product loses 139 x 1.5% = 2.1 accounts a month.

A 6% monthly churn rate would sink the B2B product. In the B2C product it is survivable, because each subscriber costs $40 to win and repays it in about four months. For the formulas behind these rows, see LTV in SaaS.

Companies that report both kinds of customer

Public filings show how a company that serves both splits the numbers.

Zoom separates customers by how they buy, not by who they are. In its fourth-quarter fiscal 2026 results (published February 25, 2026), “Enterprise” customers are business units engaged by Zoom’s direct sales team, resellers or strategic partners. “Online” customers are all other customers that subscribe directly through its website. The two groups behave differently:

Enterprise revenue was $757.3 million of $1,247.0 million total in the quarter, or $757.3 / $1,247.0 = 60.7%.
Online average monthly churn was 2.9% in the quarter.
Enterprise customers had a trailing 12-month net dollar expansion rate of 98%.

Zoom reports churn for the self-serve side and expansion for the sales-led side. Each side gets the metric that explains it.

Duolingo is a consumer subscription business. Its second-quarter 2026 shareholder letter reports 12.7 million paid subscribers at June 30, 2026 and 140.6 million monthly active users in the quarter. That is 12.7 / 140.6 = 9.0% of monthly users paying, a ratio Duolingo does not state itself. Subscription revenue was $258.0 million in the quarter. The free tier carries the acquisition work that a sales team does in B2B.

For how self-serve sign-up and free tiers replace sales in software, see product-led growth. For public B2B examples, see B2B SaaS companies.

B2B2C: selling to a business that serves consumers

B2B2C (business to business to consumer) sits between the two. You sell to a business, and that business offers your product to its own consumers.

Example: a hypothetical appointment-booking product sold to dental clinics. Each clinic pays $300 a month and is the tenant. Its patients use the booking page and never pay you.

50 clinics x $300 = $15,000 a month.
If each clinic has 1,500 patients who book online, the product serves 50 x 1,500 = 75,000 consumer users.

Your contract, invoice and churn sit with 50 businesses. Your support volume, privacy duties and app ratings sit with 75,000 people. Plan for both: sell like B2B, design and support like B2C.

Common mistakes

Comparing your churn with the other model’s benchmark. A 3% monthly churn rate can be strong for a consumer app and alarming for an enterprise product. Why it happens: published churn figures rarely say which model they describe. Instead: compare only with figures from the same model, and label the period.
Pricing a B2C product like B2B. A consumer will not wait for a quote or a demo. Why it happens: founders copy the pricing pages of the B2B tools they use at work. Instead: show the price, take a card and let people start without talking to anyone.
Selling to companies with only a self-serve funnel. Larger buyers need security reviews, invoices and contracts. Why it happens: self-serve works for small teams, so it seems enough. Instead: add an invoice option and a path to a human when deal size justifies it.
Treating B2B2C users as someone else’s problem. Consumers judge the product directly, and their complaints reach your customer. Why it happens: the business pays, so it feels like the only customer. Instead: measure consumer experience and support load per tenant.

Sources

Microsoft Learn, SaaS and multitenant solution architecture (December 16, 2025) and Tenancy models for a multitenant solution, checked October 2026.
Zoom Communications, fourth quarter and fiscal year 2026 results, Form 8-K exhibit 99.1, February 25, 2026.
Duolingo, Q2 2026 shareholder letter, Form 8-K exhibit, 2026.

In three sentences

B2C SaaS sells cheap subscriptions to many individuals who decide fast and leave fast, while B2B SaaS sells larger contracts to organizations that decide slowly and stay longer. Two products with similar LTV:CAC ratios can need 6,944 subscribers or 139 accounts to reach $1 million in annual revenue, so benchmarks from one model mislead the other. Companies that serve both, such as Zoom, report each side with its own metrics, and B2B2C products must sell like B2B while supporting consumers like B2C.

What is agentic AI? AI agents explained without the hype

Ricardo Machado — Sun, 25 Oct 2026 11:00:00 GMT

Every software launch now mentions “agents”, and someone on your team has asked whether you need one. You need a definition you can hold a product demo against, not a slogan. Agentic AI is software in which a language model decides its own next step and uses tools to act, in a loop, until a goal is met or a limit stops it.

That definition matters because it tells you what to test, what can go wrong and who is accountable. This guide covers the agent loop, the difference between an agent, a chatbot and a workflow, why errors compound over many steps, and what stays your responsibility. For the basics of software delivered as a service, see What is SaaS?.

Agentic AI in plain terms

Think of three kinds of help in an office. A receptionist answers questions when asked. A clerk follows a written checklist, step by step, the same way every time. A trusted assistant gets a goal, such as “get the team to the conference for under $1,500 each”. The assistant works out the steps alone: checks flights, compares hotels, books, and comes back when something blocks the plan.

The receptionist is a chatbot. The clerk is a workflow. The assistant is an agent.

Anthropic, which builds language models, draws the line between the last two in Building effective agents (December 19, 2024). Workflows are “systems where LLMs and tools are orchestrated through predefined code paths”. Agents are “systems where LLMs dynamically direct their own processes and tool usage”. An LLM (large language model) is the model that reads and writes text.

Microsoft’s AI agent shared responsibility model (updated August 26, 2026) adds what makes an agent different from a model that only answers. An agent “invokes tools, calls APIs, writes data, and triggers workflows without a human approving each step”. It also plans, keeps memory and holds an identity of its own when it signs in to other systems.

The agent loop

Strip away the branding and an agent runs one loop:

Goal. A person or a system states what should be true at the end.
Plan. The model breaks the goal into a next step.
Tool call. The model calls a tool: a search, an API, a database query, a script.
Check. The model reads the result and decides whether it moved closer to the goal.
Repeat or stop. It loops back to step 2, or stops because the goal is met, a limit is hit or it needs a human.

Anthropic’s guidance puts weight on step 4. An agent should get “ground truth” from its environment at each step, such as a tool result or the output of code it ran. It can pause for human feedback at checkpoints or when it hits a blocker. Stopping conditions, such as a maximum number of iterations, keep the loop under control.

The tools are what turn text into action. A model that can only write a reply cannot change anything. A model connected to your CRM, your email and your billing system can.

Agent, chatbot or workflow

The three are often sold under the same label. This table separates them by what each one does, not by what it is called.

Question	Chatbot	Workflow with AI steps	Agent
Who decides the next step?	The person asking	The designer, in advance	The model, at run time
Can it change data in other systems?	No, a person acts on the answer	Yes, along fixed paths	Yes, through any tool it has been given
Number of steps	One reply per question	Fixed	Varies per run
Cost per run	Predictable	Predictable	Varies with the number of loops
Typical failure	A wrong answer a person can spot	A broken path or bad input	A wrong action, repeated or chained
Fits best	Questions and drafts	Repeatable tasks with known steps	Open-ended tasks where the steps cannot be listed in advance

Read the last row first. If you can write the steps down, a workflow is cheaper to run and easier to test. Anthropic recommends “finding the simplest solution possible, and only increasing complexity when needed”. It adds that for many applications, “optimizing single LLM calls with retrieval and in-context examples is usually enough”.

Why errors compound

Anthropic states the trade-off: “The autonomous nature of agents means higher costs, and the potential for compounding errors.” The arithmetic shows why.

Example: a hypothetical agent that gets each step right 95% of the time, with steps treated as independent.

2 steps: 0.95 x 0.95 = 0.9025, so 90.3% of runs finish without an error.
5 steps: 0.95^5 = 0.774, so 77.4%.
10 steps: 0.95^10 = 0.599, so 59.9%.
20 steps: 0.95^20 = 0.358, so 35.8%.

A step that looks reliable on its own fails four runs in ten once it is chained ten times.

Now add a working check. Suppose the agent catches a bad step and retries it once, and the retry also succeeds 95% of the time. A step then fails only if both attempts fail: 0.05 x 0.05 = 0.0025. Each step succeeds 1 - 0.0025 = 0.9975 of the time. Over 10 steps: 0.9975^10 = 0.975, so 97.5% of runs finish cleanly.

The model did not get smarter between the two calculations. The check did the work. That is why step 4 of the loop, and the “ground truth” behind it, decides whether an agent is usable.

What stays your responsibility

Microsoft’s agent model lists what you keep whatever product you use. You own your data and the agent’s identity, including the scope of every credential it holds. You decide which actions it may take and which need a human, and you answer for what it does. It recommends human approval for “high-impact, irreversible, or sensitive actions” such as writes, deletes, payments, production changes and external sends.

The same document names the risks that are new with agents. Prompt injection, where text in a web page, document or email hijacks the agent, can now trigger actions instead of a bad answer. “Excessive agency” means the agent has more tools or permissions than the task needs. Its rule of thumb fits on one line: “Autonomy never reduces accountability.”

In practice, an agent that reads your support inbox and can issue refunds is a support tool and a payment tool at once. Treat its permissions the way you would treat a new employee’s on day one.

If you connect an agent to your SaaS apps, the plumbing is the same as any integration: APIs, OAuth grants and webhooks, covered in SaaS integration. Rolling it out follows the same discipline as any new system, see SaaS implementation.

Common mistakes

Calling every chatbot an agent. A system that only replies cannot act, so it carries different risks and costs. Why it happens: vendors use “agent” as a marketing label. Instead: ask which tools it can call and whether it decides its own next step.
Choosing an agent for a task with fixed steps. You pay for variable loops and accept compounding errors where a workflow would do. Why it happens: agents are what is being launched. Instead: write the steps down; if you can, build a workflow first.
Giving the agent a broad standing identity. One admin-level token lets a single injected instruction reach everything. Why it happens: broad access makes the demo work. Instead: grant each tool only the permissions its task needs, and require approval for writes, payments and external sends.
Running the loop with no limits. Without a step, time or cost ceiling, a confused agent keeps calling tools. Why it happens: limits feel like they block the goal. Instead: set a maximum number of iterations and a budget per run, and log every tool call.

Sources

Anthropic, Building effective agents, December 19, 2024, checked October 2026.
Microsoft Learn, AI agent shared responsibility model, updated August 26, 2026, checked October 2026.

In three sentences

Agentic AI is software in which a language model picks its own next step and uses tools to act, looping until it finishes or a limit stops it. A chatbot only answers and a workflow follows steps fixed in advance, so use an agent only when the steps cannot be written down. Errors compound across steps (95% per step becomes 59.9% over ten), so the check, tight permissions, human approval for risky actions and hard limits decide whether an agent is safe to run.

Bootstrapping a SaaS: from idea to first paying customers without funding

Ricardo Machado — Sat, 24 Oct 2026 21:00:00 GMT

You have an idea for a software product, some savings or a day job, and no wish to spend a year pitching investors. You want to know whether you can build a SaaS business on customer money alone, and what has to happen between the idea and the first invoice. Bootstrapping a SaaS means funding it from your own resources and then from revenue, which puts one goal above all others: paying customers, early.

That goal changes the order of work. You validate before you build, you charge before the product feels finished, and you pick a target small enough to reach. This guide sets out the steps, two public cases, the arithmetic of a first revenue target and a checklist for the weeks before you write code. For the basics of the model, see What is SaaS?.

Bootstrapping in plain terms

Think of it like opening a food stall instead of a restaurant. A restaurant needs a lease, a kitchen and staff before the first plate is sold, so it needs a loan or an investor. A stall needs a cart and one good dish. You learn what sells from the first day’s queue, and you buy the second cart with the first cart’s takings.

A bootstrapped SaaS is the stall. Revenue, not outside capital, pays for the next step. The price is speed: you grow only as fast as customers pay. The benefit is ownership and freedom: no investor sets your targets or your exit. A micro SaaS, a small SaaS business often run by one person or a small team, is a common bootstrapped shape.

Two public cases

Founder stories are easy to find and hard to check. The two below rest on what the companies state on their own pages.

Plausible Analytics. The company’s about page says Uku Taht started Plausible in December 2018. It describes the company as “self-funded and profitable, with no outside investors and no plans to sell”. It reports that Plausible “crossed $1 million in annual recurring revenue in 2022”, that more than 21,000 paying subscribers use it, and that it is “a team of 10” (Plausible, About). Its home page lists the Starter plan from $9 a month, a 30-day free trial with no credit card, and “2 months free” on yearly billing (Plausible, as of October 2026).

Zoho. Zoho is far larger, and its about page makes the same core claim: the company has never taken money from investors. The page also records that Zoho passed 100 million users in 2023 (Zoho company page).

The two cases differ in size by orders of magnitude, but they share the claim that matters here: neither company depended on investors to pay for growth. Plausible adds a pattern you can copy on day one: a product people can try and buy on their own, at a published price.

The steps, in order

Pick a problem you can reach. Choose a group of buyers you can contact directly: an industry you know, a community you belong to, a tool you use daily. If you cannot name 50 potential buyers, the problem is too abstract for a first product.
Validate with commitments, not compliments. Interview potential buyers about how they solve the problem today and what it costs them. A pre-order, a paid pilot or a signed letter of intent is evidence. A polite “sounds useful” is not.
Build the smallest product that solves one task. One workflow, done well, for the buyers you interviewed. Everything else goes on a list for later.
Charge from day one. A free trial is fine; a free product with no price is not a test of demand. Publish the price, even if you change it later. For the main ways to structure it, see SaaS pricing models.
Use channels that cost time, not money. Direct outreach, the communities you already belong to, content that answers your buyers’ questions, and integration marketplaces. Low-touch selling can work at scale: Atlassian’s 2015 IPO filing stated that it had no direct sales force and relied on “word-of-mouth and low-touch demand generation” (Atlassian Form F-1).
Decide when to stay small. A product that pays one or two people well is a finished business, not a failed startup. Reselling an existing product under your brand is another low-capital route, described in white-label SaaS.

Worked example: the arithmetic of a first target

Example: a labeled hypothetical. You set a first target of $5,000 in monthly recurring revenue (MRR). You assume 20% of free trials convert to paid, and 3% of paying customers cancel each month (monthly logo churn). Both assumptions are yours to replace with real data once you have it.

Price per month	Customers for $5,000 MRR	Trials needed at 20%	Customers lost per month at 3%	New trials per month to stay level
$9	5,000 / 9 = 555.6, so 556	556 / 0.2 = 2,780	556 x 3% = 16.7, so 17	17 / 0.2 = 85
$29	5,000 / 29 = 172.4, so 173	173 / 0.2 = 865	173 x 3% = 5.2, so 6	6 / 0.2 = 30
$99	5,000 / 99 = 50.5, so 51	51 / 0.2 = 255	51 x 3% = 1.5, so 2	2 / 0.2 = 10

Customer counts and losses are rounded up, because you cannot win part of a customer.

Read the last column. At $9, you need 85 new trials every month just to stand still. At $99, you need 10. A cheap product needs a large audience; an expensive one needs a buyer with a budget and a problem worth $99 a month. Pick the row your channels can feed. For what each customer is worth over time, see LTV in SaaS.

Yearly billing. Plausible’s “2 months free” offer shows the trade. At $9 a month, a year costs 12 x $9 = $108 on monthly billing and 10 x $9 = $90 on yearly billing. You give up $18, a 16.7% discount, and receive 12 months of cash on the first day. For a bootstrapped company, cash up front pays for the next month of work.

Checklist

Before you write code:

Write the problem in one sentence, in the words a buyer used in an interview.
List 50 potential buyers you can reach directly, by name or community.
Hold at least 10 interviews about how they solve the problem today.
Get at least one commitment that costs the buyer something: money, a signed pilot or their data.
Choose the one workflow your first version will do, and write down what it will not do.
Set a public price and a first MRR target, and run the arithmetic in the table above.
Decide the two channels you will use in the first three months.
Calculate how many months your savings or salary can cover before revenue must.

Common mistakes

Building for months before talking to buyers. The product solves a problem nobody pays to solve. Why it happens: building feels like progress, interviews feel awkward. Instead: interview first and collect a commitment before the first line of code.
Pricing too low to be sustainable. As the table shows, a $9 product needs 85 new trials a month to stay level at $5,000 MRR. Why it happens: a low price feels safer. Instead: price for the buyer with the problem, and test a higher price early.
Copying the playbook of funded startups. Paid ads and a sales team burn cash a bootstrapped company does not have. Why it happens: many widely shared startup stories are about funded companies. Instead: use channels that cost time, and spend money only where a channel already works.
Treating unverified founder stories as benchmarks. Revenue screenshots and growth threads are hard to check. Why it happens: they are everywhere. Instead: rely on what companies state on their own pages or in filings, as in the cases above, and on your own numbers.

Sources

Plausible Analytics, About and home page pricing, checked October 2026.
Zoho, company page, checked October 2026.
Atlassian Corporation Plc, Form F-1, filed November 9, 2015.

In three sentences

Bootstrapping a SaaS means funding it yourself and then from revenue, so validation, a published price and paying customers come before a polished product. In the example, $5,000 of MRR takes 556 customers at $9 a month or 51 at $99, and at 3% churn the $9 plan needs 85 new trials a month. Plausible and Zoho show on their own pages that companies can grow without investors, but your target, price and channels must fit the audience you can reach.

ARPA vs ARPU in SaaS: definitions, formulas and when to use each

Ricardo Machado — Sat, 24 Oct 2026 16:00:00 GMT

Your board deck shows “ARPU”, your investor’s template asks for “ARPA”, and the two numbers can differ by a factor of nine for the same company. You need to know which one to report, how each is calculated and why they can move in opposite directions. Average revenue per account (ARPA) divides recurring revenue by the number of paying customers; average revenue per user (ARPU) divides it by the number of people using the product.

The choice is not cosmetic. It decides whether a lost customer, a new small customer or a price change shows up in your numbers at all. This guide gives both formulas, works them through with the same company over two months, reads a real ARPU from an annual report and adds committed monthly recurring revenue (CMRR). For the basics of the SaaS model, see What is SaaS?.

ARPA and ARPU in plain terms

Think of it like a restaurant’s takings. You can divide the evening’s revenue by the number of tables served, or by the number of people who ate. A table of eight and a table of two are both one table, but 10 diners. The first number tells you what a booking is worth. The second tells you what a seat is worth.

In SaaS, the table is the account: the company or person that pays the invoice. The diner is the user: each person with a login.

ARPA = monthly recurring revenue (MRR) / number of paying accounts.
ARPU = MRR / number of paying users.

MRR is the recurring revenue you bill in a month, normalized to a monthly amount, without one-time fees. Use the same moment for the numerator and the denominator: end-of-month MRR with end-of-month counts, or a period’s revenue with the period’s average count.

When to use each

Situation	Use	Why
You sell to companies, one invoice per company	ARPA	The account is what you win, lose and spend on acquiring
You price per seat and want to test the seat price	ARPU	It isolates what one seat earns
Consumers, one person per subscription	Either	Accounts and users are the same count
You calculate customer lifetime value (LTV)	ARPA	Churn is counted in accounts, so revenue must be too
You compare yourself with a public company	Whatever the company defines	Read the filing’s definition first

In B2B SaaS, ARPA is usually the better fit for one reason: acquisition cost and churn are both measured per customer. Mixing per-user revenue with per-customer churn produces an LTV that means nothing. For that calculation, see LTV in SaaS.

Worked example: same company, two months

Example: a labeled hypothetical. A project-management tool charges $30 per user per month.

Month one: 200 paying accounts with 1,800 users in total, so MRR is 1,800 x $30 = $54,000.

During month two:

It wins 20 small accounts with two users each: 40 users, 40 x $30 = $1,200 of new MRR.
It loses one large account with 100 users: 100 x $30 = $3,000 of lost MRR.

Measure	Month one	Month two
Paying accounts	200	200 + 20 - 1 = 219
Paying users	1,800	1,800 + 40 - 100 = 1,740
MRR	$54,000	$54,000 + $1,200 - $3,000 = $52,200
ARPA	$54,000 / 200 = $270.00	$52,200 / 219 = $238.36
ARPU	$54,000 / 1,800 = $30.00	$52,200 / 1,740 = $30.00

ARPU did not move. Every user still pays $30, so a per-user metric cannot see the change. ARPA fell by ($270.00 - $238.36) / $270.00 = 11.7%, because the company swapped one large account for 20 small ones. Account count went up, MRR went down, and only ARPA tells that story.

The reverse also happens. If no customer leaves, a price rise from $30 to $33 per user moves ARPU and ARPA by the same 10%. Report both when you change prices, and ARPA alone when you report on your customer mix.

A real ARPU from a public filing

Dropbox reports ARPU in its annual report and defines it as revenue for the period “divided by the average paying users during the same period”. Average paying users is the count at the start of the period plus the count at the end, divided by two (Dropbox Form 10-K for 2025).

The filing’s figures for the year ended December 31, 2025:

Revenue: $2,521.0 million (2024: $2,548.2 million).
Paying users at year end: 18.08 million (end of 2024: 18.22 million).
Reported ARPU: $138.91 (2024: $140.23).

You can redo the calculation. Average paying users: (18.22 + 18.08) / 2 = 18.15 million. ARPU: $2,521.0 million / 18.15 million = $138.90. The cent of difference from the reported $138.91 comes from user counts rounded to two decimals. Per month, that is $138.91 / 12 = $11.58 per paying user. ARPU fell by $1.32, or 0.9%, from 2024.

Note what Dropbox counts. Paying users are “users who have active paid licenses”, so a team plan with 10 licenses counts as 10 users. That makes ARPU the natural metric for a product sold largely by the license. A company that sells mainly by the account would report ARPA.

CMRR: committed monthly recurring revenue

CMRR is MRR adjusted for what is already signed. Add contracts that are signed but not yet live; subtract revenue from customers who have given notice to cancel. It answers “what will MRR be if nothing else changes?”

Example: the same hypothetical company ends month two with $52,200 of MRR. It has signed $4,000 of new monthly contracts that start next month, and customers worth $1,500 a month have given notice.

CMRR = $52,200 + $4,000 - $1,500 = $54,700.

Keep ARPA on live MRR, not on CMRR. The signed accounts are not paying yet, and counting them would raise ARPA before any money arrives. Show CMRR next to MRR as a forward-looking line, and say which contracts it includes.

Common mistakes

Calling ARPA “ARPU” in a B2B deck. Readers compare your number with companies that define it differently. Why it happens: ARPU is the better-known acronym. Instead: write the definition under the number, as Dropbox’s filing does.
Mixing periods. Annual revenue divided by end-of-year accounts gives an annual ARPA that looks 12 times larger than a monthly one. Why it happens: finance reports yearly, dashboards monthly. Instead: label every ARPA with its period and the counting method.
Including one-time fees. Setup or onboarding fees in the numerator inflate ARPA in a month with many new customers. Why it happens: total revenue is the easiest number to pull. Instead: use recurring revenue only.
Reading a flat ARPU as “nothing changed”. As the example shows, ARPA can fall 11.7% while ARPU stays at $30. Why it happens: one metric gets all the attention. Instead: track both, plus the account and user counts behind them.

For how ARPA feeds into the rest of the model, see the SaaS business model.

Sources

Dropbox, Inc., Form 10-K for the fiscal year ended December 31, 2025, key metrics and definitions.

In three sentences

ARPA is monthly recurring revenue divided by paying accounts, and ARPU is the same revenue divided by paying users. In the example, swapping one 100-user account for 20 two-user accounts left ARPU at $30 but cut ARPA by 11.7%, from $270.00 to $238.36. Use ARPA when you sell to companies and calculate LTV, use ARPU to test a per-seat price, and keep CMRR as a separate line for contracts that are signed but not yet live.

How to evaluate SaaS solutions: a buyer's checklist and scoring template

Ricardo Machado — Sat, 24 Oct 2026 11:00:00 GMT

You have three SaaS vendors on a shortlist, three polished demos behind you and a decision due before the budget closes. Every vendor said yes to every question. You need a way to compare them on evidence rather than on the best presentation. Evaluating SaaS solutions comes down to six questions, answered with documents, and a scoring table that weighs them in the order that matters to you.

The cost of a wrong choice is often not the subscription. It is the migration, the training and the year spent working around a gap nobody tested. This guide gives you the six areas, a checklist to tick and a scoring template with the arithmetic shown. If SaaS itself is new to you, start with What is SaaS?.

Evaluating a vendor in plain terms

Think of it like buying a used car. The seller’s description is the demo. You still check the service history, take it for a drive on your own route, look underneath and ask what it costs to insure. Then you compare two cars on the same list, not on how friendly the sellers were.

A SaaS evaluation does the same. The service history is the vendor’s security evidence. The test drive is a trial with your own data. The insurance quote is the full contract price over the term. And the list is a scoring table you write before the first demo, so the demos cannot rewrite it.

The six areas to check

Requirements fit. Write the 5 to 10 tasks the tool must do, in your words, before you see any demo. Ask each vendor to show those tasks, in that order, with your sample data.
Security evidence. Ask for documents, not answers. The common ones are a SOC 2 report, an ISO/IEC 27001 certificate and a completed security questionnaire. SOC 2 is an audit report, issued by a CPA firm, against criteria the AICPA lists as “Security, Availability, Processing Integrity, Confidentiality, or Privacy” (AICPA SOC). The Cloud Security Alliance publishes a standard questionnaire, the CAIQ, a set of “Yes/No questions” mapped to its Cloud Controls Matrix (CSA CAIQ v4.1.0). How to read a certificate’s scope and dates is covered in ISO/IEC 27017 explained.
Pricing and contract. Get the total price for your expected seats or usage over the full term, including onboarding fees, add-ons and the renewal increase. Read the clauses on auto-renewal, seat reductions and price changes.
Integrations. Confirm which plan includes single sign-on (SSO), user provisioning and API access. Ask for the API documentation, and have your developer read it.
Data portability and exit. Ask how you export all your data, in which format, and how long the vendor keeps it after the contract ends. Then run an export during the trial.
References. Ask for two customers of your size and industry, and call them. Ask what broke in the first six months and how support handled it.

Checklist

Requirements list written and shared with every vendor before the demos.
Each vendor showed every required task with your sample data.
SOC 2 report received, its period and scope read, exceptions noted.
ISO/IEC 27001 certificate received, scope and expiry date checked.
Security questionnaire (the vendor’s own or the CSA CAIQ) completed and reviewed.
Three-year total price calculated for the seat count you expect in year three.
Auto-renewal notice period, renewal price cap and seat-reduction terms found in the contract.
SSO, provisioning and API access confirmed on the plan you will buy.
Full data export run during the trial and opened in another tool.
Two references called, and their answers written down.
Scoring table filled in by at least two people, separately, before discussing.

Worked example: a weighted scoring table

A weighted score turns six areas into one number you can defend. You choose the weights before the demos, score each vendor from 1 (poor) to 5 (strong) in each area, multiply, and add.

Example: a labeled hypothetical. A 50-person team compares two vendors. Vendor A costs $20 per user per month and Vendor B costs $28. Over a year, that is 50 x $20 x 12 = $12,000 for A and 50 x $28 x 12 = $16,800 for B, a difference of $4,800. The team set the weights below before the first demo.

Area (weight)	Vendor A score	A weighted	Vendor B score	B weighted
Requirements fit (30%)	4	0.30 x 4 = 1.20	4	0.30 x 4 = 1.20
Security evidence (25%)	3	0.25 x 3 = 0.75	5	0.25 x 5 = 1.25
Price and contract (20%)	5	0.20 x 5 = 1.00	3	0.20 x 3 = 0.60
Integrations (15%)	3	0.15 x 3 = 0.45	4	0.15 x 4 = 0.60
Data exit (10%)	2	0.10 x 2 = 0.20	4	0.10 x 4 = 0.40
Total (100%)		3.60		4.05

The weights add up to 100%: 30 + 25 + 20 + 15 + 10. References are not scored here; they confirm or correct the other scores.

Vendor A wins on price by $4,800 a year and still loses, 3.60 against 4.05. The gap comes from security evidence and data exit, the two areas that are hardest to fix after signing. Now the team can test the result. Is $4,800 a year worth a weaker security record and a harder exit? Writing the question that way is the point of the table.

Copy the template, keep the weights fixed once the demos start, and have two people score separately. If their scores differ by two points or more in one area, that area needs another look.

Common mistakes

Writing requirements after the demos. The best demo sets the list, and the list then favors that vendor. Why it happens: demos are booked before anyone has time to write. Instead: write the tasks first and send them to every vendor.
Accepting a questionnaire answer instead of evidence. A “yes” in a sales call is not an audit report. Why it happens: asking for documents feels confrontational. Instead: ask for the SOC 2 report or certificate, and read its scope and dates.
Comparing first-year prices only. Seat growth, add-ons and renewal increases change the total. Why it happens: quotes show year one. Instead: calculate the full term at the seat count you expect at the end, as the checklist says.
Never testing the exit. You find out how hard the export is on the day you leave. Why it happens: nobody plans to leave on day one. Instead: run a full export during the trial and give data exit a weight in the table.

For how per-seat and usage prices are built, see SaaS pricing models. For a worked comparison of one category, see CRM SaaS.

Sources

AICPA and CIMA, SOC suite of services, checked October 2026.
Cloud Security Alliance, STAR Level 1: Security Questionnaire (CAIQ v4.1.0), checked October 2026.

In three sentences

Evaluate a SaaS vendor on six areas, requirements fit, security evidence, price and contract, integrations, data exit and references, each backed by a document or a test. Set the weights before the demos and score each vendor from 1 to 5; in the example, Vendor B scores 4.05 against 3.60 despite costing $4,800 more a year. Ask for reports rather than answers, price the whole term and run a full export during the trial, so the decision rests on evidence you can show.

E-commerce SaaS: hosted platforms vs open source vs headless

Ricardo Machado — Fri, 23 Oct 2026 21:00:00 GMT

You want to sell online, or your current store has outgrown its setup, and every agency you ask recommends a different platform. You need to know what you are really choosing between and what each choice costs once the work is counted. There are three models: a hosted e-commerce SaaS platform, self-hosted open-source software, or headless commerce, where a separate front end sits on top of a commerce back end.

The choice decides who keeps the store running at 2 a.m. on a sale day, and that cost can be larger than the license fee. This guide explains the three models, works through a three-year cost comparison and ends with a decision table by store size. If SaaS is new to you, start with What is SaaS?.

The three models in plain terms

Think of it like opening a shop. You can rent a unit in a shopping mall: the mall handles security, cleaning and the electricity, and you follow its rules on signs and opening hours. You can buy a building and run it yourself: no landlord, but the roof is your problem. Or you can rent the mall’s stockroom and checkout and build your own storefront next door, designed exactly as you want.

Hosted e-commerce SaaS is the mall unit. The vendor runs the software, the servers, security updates and checkout. You pick a theme, add products and pay a monthly fee. Shopify is one example.
Self-hosted open source is the building you own. The software is free to download and change, and you or your developer run the hosting, updates and security. WooCommerce describes itself as “the world’s top open-source platform”, “powered by WordPress”, with no “monthly platform fees” (WooCommerce). Hosting is a separate bill.
Headless commerce is the custom storefront. Shopify’s developer documentation puts it in one line: “Headless commerce separates your storefront’s frontend from its backend” (Shopify, headless). The back end still handles products, cart and checkout; your developers build everything the customer sees.

How each model works in practice

Hosted SaaS. You pay a subscription, usually in tiers, and buy extra functions as apps from the vendor’s marketplace. Payment processing is charged per transaction. The vendor ships new features to every store at once. You cannot change the core code, so anything the platform and its apps do not support is hard to add. That marketplace model is what makes a product a platform, as What is a SaaS platform? explains.

Self-hosted open source. The license costs nothing, but nothing else is free. You choose a host, install the software, add extensions, apply security updates and fix what breaks. You can change anything, because you hold the code. The real cost is developer time, every month, for as long as the store runs.

Headless. The commerce engine can be a SaaS back end or an open-source one. On Shopify, the Storefront API “serves products, collections, search, and the cart, and hands customers off to checkout”. Hydrogen is “Shopify’s headless toolkit” and Oxygen is “Shopify’s hosting for Hydrogen storefronts”. Shopify’s own page states that a headless storefront “costs more to build and run than a theme”. You get full control of speed and design, and a front end that needs a development team.

Worked example: three years of running costs

Platform prices change often and differ by region, so this example uses labeled assumptions, not any vendor’s price list. Replace each line with the quotes you receive.

Example: a labeled hypothetical. A store with about 2,000 products and steady sales compares three years of costs. Payment processing is left out, because it applies to all three models at similar rates. Developer time is priced at $75 an hour.

Cost line (assumed)	Hosted SaaS	Self-hosted open source	Headless
Platform or license fee	$100 a month	$0	$100 a month (SaaS back end)
Hosting	included	$80 a month	$50 a month
Apps or extensions	$150 a month	$100 a month	$150 a month
Developer upkeep	none	8 hours x $75 = $600 a month	20 hours x $75 = $1,500 a month
Monthly running cost	$250	$780	$1,800
Three years of running	$250 x 36 = $9,000	$780 x 36 = $28,080	$1,800 x 36 = $64,800
One-time build (assumed)	$3,000	$8,000	$40,000
Three-year total	$12,000	$36,080	$104,800

Read the developer row first. The license fee is the smallest line in the self-hosted column, and labor is 77% of its running cost ($600 / $780). In the headless column, labor is 83% ($1,500 / $1,800). The hosted platform looks expensive only if you compare license fees and ignore people.

The comparison turns when the store needs something the hosted platform cannot do. If a custom checkout step or a product configurator would add sales worth more than the extra cost, the open or headless model pays for itself. Put that number on paper too, before you switch.

Decision table by store size

The table is a starting point, built from the trade-offs above. Your catalog, your team and your sales plan decide the final answer.

Store stage	Usually fits	Why	Watch for
First store, one or two people	Hosted SaaS	No servers, no developer, fast launch	App fees that add up month by month
Growing store, small team, standard needs	Hosted SaaS on a higher tier	Same platform, more staff accounts and reports	Features you cannot add without code
Unusual products or processes, a developer on hand	Self-hosted open source	Full control of the code and the data	Security updates and downtime are yours
Large brand, in-house developers, design and speed matter	Headless	Custom front end, any framework	Two systems to run and a team to keep

Moving between rows is possible but slow. A store migration touches products, customers, order history, URLs and search rankings. Choose the row you expect to be in for the next three years, not the one you are in today.

Common mistakes

Comparing license fees instead of total cost. The free license looks cheapest until developer hours are added; in the example, they are 77% of the open-source running cost. Why it happens: the license is the only number on the download page. Instead: price three years, including people, as in the table.
Going headless for speed alone. A custom front end can be fast, but so can a light theme on a hosted platform. Why it happens: headless is sold on performance. Instead: go headless when you need a design or experience a theme cannot deliver, and have the team to run it.
Installing apps without a budget. Each app adds a monthly fee and code that runs on your pages. Why it happens: apps fix problems in minutes. Instead: list every app with its monthly cost, and review the list every quarter.
Ignoring the exit. Product data, customer accounts and order history must move with you if you change platforms. Why it happens: nobody plans a move on day one. Instead: test a full export from the platform before you commit, and keep URL redirects in the migration plan.

For how monthly fees, tiers and usage charges are built, see SaaS pricing models.

Sources

WooCommerce, product page, checked October 2026.
Shopify, Headless commerce developer documentation, checked October 2026.

In three sentences

You can run an online store on a hosted e-commerce SaaS platform, on self-hosted open-source software or on a headless setup with a custom front end over a commerce back end. In the labeled example, three years cost $12,000 hosted, $36,080 self-hosted and $104,800 headless, and developer time is most of the difference. Start hosted unless you need something the platform cannot do, and price people, apps and the exit before you choose.

DaaS vs SaaS: what desktop as a service adds to the cloud stack

Ricardo Machado — Fri, 23 Oct 2026 16:00:00 GMT

Your staff work from laptops you do not control, a contractor needs a Windows machine for three months, or an old desktop application has no web version. Someone suggests “DaaS”, and you need to know how it differs from the SaaS tools you already pay for. Desktop as a service (DaaS) rents you a complete Windows desktop that runs in a provider’s data center; software as a service (SaaS) rents you one application.

The two solve different problems, and they often run side by side. This guide places DaaS in the cloud stack, shows who manages what, works through real prices from one provider and clears up the second meaning of the acronym. For the basics of SaaS itself, see What is SaaS?.

DaaS in plain terms

Think of it like the difference between renting a furnished office and using a print shop. The furnished office comes with a desk, a chair, a computer and a filing cabinet, and you arrange it as you like. The print shop does one job for you, and you never touch its machines.

DaaS is the furnished office. You get a whole desktop: an operating system, a start menu, files and any applications you install. You reach it from a laptop, a tablet or a browser, but the desktop itself runs on the provider’s servers. SaaS is the print shop: one application, such as email or a CRM, that the vendor runs and updates for you.

Where DaaS sits in the cloud stack

A widely cited reference for cloud service models is NIST Special Publication 800-145, “The NIST Definition of Cloud Computing”, published in September 2011. It names three service models: infrastructure as a service (IaaS), platform as a service (PaaS) and SaaS (NIST SP 800-145). DaaS is not one of them. It is a packaged offering that providers built later, on top of the same layers.

How DaaS is described depends on how much the provider runs:

Microsoft Windows 365 calls itself “a cloud-based software-as-a-service (SaaS)” that creates Cloud PCs, one Windows virtual machine per user. It is sold “as a separate license per user for a fixed monthly fee” (Microsoft Learn, What is Windows 365?). The Business edition is for companies of up to 300 seats.
Azure Virtual Desktop runs in your own Azure subscription. Microsoft’s documentation says you “only manage the image and virtual machines you use for the sessions”, not the gateway and broker roles (Microsoft Learn, What is Azure Virtual Desktop?). That is closer to IaaS with a managed control plane.
Amazon WorkSpaces offers both persistent personal desktops and shared pools, billed monthly or by the hour (AWS WorkSpaces pricing).

So DaaS is not a fourth layer with a fixed place. It is a product type that can look like SaaS or like IaaS, depending on who manages the virtual machines. For the line between the three NIST models, see SaaS vs PaaS.

Who manages what

The table compares a SaaS application with the two ends of the DaaS range. It is assembled from the documentation above; check your provider’s own shared-responsibility page before you sign.

Layer	SaaS application	DaaS, fully managed (Windows 365 style)	DaaS, self-managed (Azure Virtual Desktop style)
Data center, servers, network	Vendor	Provider	Provider
Virtual machines	Vendor	Provider, created automatically per license	You
Desktop image	Not applicable	Provider’s image, or your own on Enterprise	You
Applications installed on the desktop	Not applicable	You	You
The application itself	Vendor	You (or its own SaaS vendor)	You (or its own SaaS vendor)
Users, access and data	You	You	You

The bottom row never moves. In every model, you decide who has access and you own your data. The table shows the main trade: DaaS hands you a whole computer to manage remotely, while SaaS hands you a finished application.

Worked example: personal desktops vs a shared pool on AWS

AWS publishes worked pricing examples for its US West (Oregon) Region on the WorkSpaces pricing page (checked October 17, 2026). Two of them:

A Windows Standard personal desktop at a fixed $44 per month (AlwaysOn billing).
A Standard bundle in WorkSpaces Pools at $0.10 per hour, plus a Remote Desktop Services Subscriber Access License (RDS SAL) fee of $4.19 per user per month.

A personal desktop keeps the user’s machine and settings between sessions. A pool hands out a fresh desktop from a shared set, so it suits staff who use the same few applications and keep files elsewhere.

Example: a team of 25 people, each using a cloud desktop for 140 hours a month (about seven hours a day on 20 working days). The hours are an assumption; the prices are AWS’s examples.

Option	Calculation	Monthly cost
Personal desktops, AlwaysOn	25 x $44	$1,100
Pools, compute	25 x 140 hours x $0.10	$350
Pools, licenses	25 x $4.19	$104.75
Pools, total	$350 + $104.75	$454.75

At what usage do the two cost the same per user? Solve $4.19 + $0.10 x hours = $44: hours = ($44 - $4.19) / $0.10 = 398.1 hours a month. Below about 398 hours, the pool is cheaper per user in this example. The catch is not the price: a pool is non-persistent, so it fails users who need their own installed software or local settings. Price both on the AWS calculator for your Region before you decide.

The other DaaS: data as a service

The same acronym also stands for data as a service: a provider sells access to a dataset, usually through an API or a scheduled file delivery. Examples of the category include company records, address validation and market prices. Data as a service has nothing to do with desktops. When a vendor or a colleague says “DaaS”, ask which one, before anyone writes a budget line.

Common mistakes

Expecting DaaS to replace your SaaS tools. A cloud desktop still needs email, a CRM and storage, often bought as separate SaaS. Why it happens: “everything in the cloud” sounds like one purchase. Instead: list the applications that will run inside the desktop and price them separately.
Comparing per-user prices without the usage pattern. In the example, the same 25 people cost $1,100 or $454.75 a month depending on the billing type. Why it happens: price lists show one number per bundle. Instead: estimate hours per user first, then compare monthly and hourly billing.
Assuming the provider manages everything. With a self-managed service such as Azure Virtual Desktop, the image and the virtual machines are yours to manage. Why it happens: the word “service” suggests the provider does it. Instead: read the provider’s documentation on what you manage, as quoted above.
Forgetting license fees beside compute. AWS’s pool example adds $4.19 per user per month for a Remote Desktop license. Why it happens: hourly compute prices are the headline. Instead: add every per-user license to the comparison.

For how Microsoft splits responsibility in its office suite, see Microsoft 365 as SaaS.

Sources

NIST, SP 800-145, The NIST Definition of Cloud Computing, September 2011.
Microsoft Learn, What is Windows 365? and What is Azure Virtual Desktop?, checked October 2026.
AWS, Amazon WorkSpaces pricing, pricing examples for US West (Oregon), checked October 2026.

In three sentences

Desktop as a service rents you a whole cloud desktop that you manage remotely, while SaaS rents you one finished application that the vendor runs. DaaS is not one of NIST’s three service models: fully managed products such as Windows 365 describe themselves as SaaS, while Azure Virtual Desktop leaves the virtual machines to you. With AWS’s Oregon examples, 25 personal desktops cost $1,100 a month and a 140-hour shared pool $454.75, so estimate usage hours before you choose.

SaaS implementation: a step-by-step rollout plan for business teams

Ricardo Machado — Fri, 23 Oct 2026 11:00:00 GMT

Your company has signed for a new SaaS product, the contract start date is fixed, and you have been told to “get everyone on it”. You need a plan that turns a login page into a tool people use, without losing data on the way. A SaaS implementation is that plan: six phases, from writing down what the tool must do to measuring whether people use it.

The vendor runs the servers, so implementation is not about installing software. It is about configuration, data, connections and people. Those four are yours, whatever the contract says. If the split between what the vendor runs and what you run is new to you, start with What is SaaS? and SaaS in cloud computing.

Implementation in plain terms

Think of it like moving into a furnished apartment. The landlord owns the building, the plumbing and the furniture. You still have to decide which room is for what, carry your boxes in, label them, get the internet connected and show your family where things are. An apartment full of unopened boxes is not a home, however good the building.

In SaaS terms, the building is the vendor’s product. Your boxes are your data. The internet connection is your integrations. Showing the family around is training. Implementation ends when people live in the new place, not when the keys change hands.

The six phases

Each phase ends with a written output. If a phase has no output, it did not happen.

Requirements. List the processes the tool must support, in the order people do them today. Mark each as required, useful or later. Output: a requirements list signed by the business owner.
Configuration. Set up the product to match those processes: fields, workflows, roles, permissions and naming. Change your process before you customize the product, where the product’s default is reasonable. Output: a configuration record, so the next admin knows what was changed and why.
Data migration. Export from the old system, clean, map each field to the new one, test-import a sample, fix, then import everything. Output: a reconciliation report (records exported against records imported).
Integrations. Connect identity first: single sign-on (SSO), so people log in with their company account, and user provisioning. SCIM (System for Cross-domain Identity Management), an IETF protocol published as RFC 7644 in September 2015, lets your identity provider create and remove accounts automatically. Then connect the tools that feed or read the new system. Output: an integration list with owners.
Training. Train by role, on the tasks each role does every week, with the company’s real data. Output: a short guide per role and a list of who attended.
Adoption. Measure use after go-live and act on it. Output: a 30-day and a 90-day adoption report.

Who does what: a RACI table

A RACI table assigns one role per task: Responsible (does the work), Accountable (owns the result, one person only), Consulted (asked before) and Informed (told after). The table below is a starting point for a mid-size rollout. Adjust the roles to your company.

Task	Business owner	Project lead	IT / admin	Vendor
Requirements list	A	R	C	C
Configuration	C	A	R	C
Data migration	I	A	R	C
SSO and provisioning	I	C	A, R	C
Training	C	A	I	R
Adoption report	A	R	C	I

Two rules make the table useful. Only one person is accountable for each row. And the vendor is never accountable: the contract makes the vendor responsible for its service, not for your rollout.

Worked example: migration effort and unused seats

Example: a labeled hypothetical. A company moves 48,000 customer records into a new CRM and buys 120 seats at $30 per seat per month.

Migration. A test import of the full file rejects 4% of records (missing required fields, bad dates, duplicates).

Records to fix: 48,000 x 4% = 1,920.
At 2 minutes per record: 1,920 x 2 = 3,840 minutes.
In hours: 3,840 / 60 = 64 hours, or eight working days of 8 hours for one person.

That is eight days nobody put in the plan. A sample import of 500 records in phase 3 would have shown the 4% rate before the go-live date was set.

Adoption. Thirty days after go-live, 78 of the 120 licensed users were active in a given week.

Measure	Calculation	Result
Weekly active rate	78 / 120	65%
Inactive seats	120 - 78	42
Monthly cost of inactive seats	42 x $30	$1,260
Yearly cost of inactive seats	$1,260 x 12	$15,120

The $15,120 is the cost of a rollout that stopped at go-live. Follow up with each inactive user’s manager before the renewal date, and reduce the seat count if the contract allows it. For how per-seat contracts are priced, see SaaS pricing models.

Go-live checklist

The requirements list is signed and every required item is configured and tested.
A full test import ran, and the reconciliation report shows exported and imported counts that match, or explains each difference.
The old system is set to read-only from the cutover date, so nobody writes to two places.
SSO works for every user group, and leaving staff lose access through provisioning, not by hand.
Every integration on the list has been tested with real records and has a named owner.
Each role has a one-page guide and a named person to ask in the first two weeks.
Admin rights are limited to the people who need them, and at least two people hold them.
An export of the new system’s data has been run and opened, so you know your exit works.
The 30-day adoption measure and its target are written down before go-live.

Common mistakes

Recreating the old system inside the new one. Every old custom field and workaround is copied across, and the new tool becomes as hard to use as the old one. Why it happens: it feels safer to change nothing. Instead: start from the product’s defaults and add a custom field only when a requirement needs it.
Migrating data without a sample test. The first full import fails on the night before go-live. Why it happens: migration is planned as one step. Instead: import a sample early, measure the rejection rate and budget the fixing time, as in the example.
Training on features instead of tasks. People sit through a tour of every screen and remember none of it. Why it happens: the vendor’s standard training is feature-based. Instead: train each role on the five tasks it does every week, with its own data.
Declaring success at go-live. Logins on day one say nothing about week six. Why it happens: the project team moves on. Instead: keep the adoption report in the plan, with a named owner, until the 90-day mark.

For a worked case of a per-seat tool that grows with the team, see CRM SaaS.

Sources

IETF, RFC 7644: System for Cross-domain Identity Management: Protocol, September 2015.

In three sentences

A SaaS implementation has six phases, requirements, configuration, data migration, integrations, training and adoption, and each one ends with a written output. In the example, a 4% rejection rate on 48,000 records means 64 hours of fixing, and 42 inactive seats at $30 cost $15,120 a year. Test a data sample early, give each task one accountable owner and keep measuring use after go-live, because the rollout is finished only when people work in the new tool.

Product-led growth (PLG) in SaaS: how it works and when it fails

Ricardo Machado — Thu, 22 Oct 2026 21:00:00 GMT

You have a product people can try on their own, a small budget and no sales team, and someone has told you to “go product-led”. You need to know what that means in practice, which numbers prove it works, and when it will not work for your product. Product-led growth (PLG) is a way of selling software in which the product itself does most of the selling: people sign up, get value on their own and pay when they need more.

PLG is a go-to-market choice, not a feature. It shapes your pricing, your onboarding and who you hire. This guide explains the mechanics, works through a funnel with numbers and lists the signs that a product needs salespeople instead. For the basics of the delivery model behind it, see What is SaaS?.

Product-led growth in plain terms

Think of it like the tasting stand at a supermarket. Nobody pitches you. You try a piece of cheese, you like it, and you put a block in your basket. The stand works only if the sample is good, quick to taste and close to the shelf.

PLG applies the same idea to software. Four pieces make it up:

Free entry. Either a free trial (time-limited access to the paid product) or freemium (a permanent free plan with limits). The two are not interchangeable: a trial ends on a date, a free plan ends when you hit a limit.
Self-serve onboarding. A new user reaches a useful result without a call, a demo or a setup fee.
Self-serve purchase. A card form and a public price list, so a user can pay in minutes.
In-product expansion. More seats, more usage or a higher tier, bought from inside the product as the team grows.

The opposite model is sales-led growth: a salesperson qualifies the buyer, runs a demo and negotiates a contract. Many companies run both, which this guide covers below.

How a PLG funnel works

A PLG funnel has four stages. Each one has a metric, and each metric needs a definition you write down before you measure it.

Sign-up. Someone creates an account. Count accounts, not page visits.
Activation. The user completes the action that shows the product working for them. For a scheduling tool, that might be “booked a first meeting through the link”. Activation rate is activated users divided by sign-ups in the same cohort.
Conversion. The account starts paying. Free-to-paid conversion is paying accounts divided by sign-ups (or by activated accounts; say which).
Expansion. The paying account adds seats, usage or a higher tier. That is expansion revenue, the added revenue from existing customers.

Some teams also track product-qualified leads (PQLs). A PQL is a free or trial account whose usage matches the pattern of accounts that later paid, such as five active users in one workspace. In a hybrid model, PQLs are the accounts a salesperson calls first.

What two public filings show

Two software companies described this model in their registration statements before going public. Their numbers show the scale a free entry can reach, and how a self-serve company still adds sales later.

Slack, Form S-1 (2019). As of January 31, 2019, Slack reported “more than 600,000 organizations with three or more users”. Of those, more than 88,000 were Paid Customers and more than 500,000 used the free plan (Slack Form S-1). The filing described a “self-service approach, for both free and paid subscriptions”. It also said Slack would expand its direct sales force to reach large organizations, with efforts “targeted at C-suite executives and business unit leaders”.

The paid share is a rough calculation, because both counts are lower bounds: 88,000 / (88,000 + 500,000) = 88,000 / 588,000 = about 15%. About one organization in seven paid. The other six were the free entry.

Atlassian, Form F-1 (2015). Atlassian stated that it had no “direct salesforce” and that its sales model did “not include traditional, quota-carrying sales personnel”. It reported more than 51,000 customers and total revenues of $319.5 million for fiscal 2015, which ended June 30, 2015 (Atlassian Form F-1). Dividing one by the other gives a rough ceiling on revenue per customer: $319,500,000 / 51,000 = about $6,265 a year. That is a low-price, high-volume business, which is the shape PLG fits.

Worked example: a PLG funnel

Example: a labeled hypothetical. A team collaboration tool gets 10,000 sign-ups a month. Of those, 25% activate within seven days, and 6% of activated accounts start paying within 90 days. A paying account has four seats at $10 per seat per month.

Stage	Calculation	Result
Sign-ups	given	10,000 accounts
Activated	10,000 x 25%	2,500 accounts
Paying	2,500 x 6%	150 accounts
Revenue per paying account	4 seats x $10	$40 a month
New monthly recurring revenue (MRR)	150 x $40	$6,000
Overall free-to-paid	150 / 10,000	1.5%

Now change one input at a time.

Activation from 25% to 35%: 10,000 x 35% = 3,500 activated; 3,500 x 6% = 210 paying; 210 x $40 = $8,400. New MRR rises by $2,400, or 40%.
Price from $10 to $12 per seat, same conversion: 150 x 4 x $12 = $7,200. New MRR rises by $1,200, or 20%.

In this example, the onboarding fix is worth twice the price rise. The arithmetic points to a pattern worth testing: growth can sit in the first 10 minutes of the product, not only on the pricing page. Run the same calculation with your own numbers before you decide where to spend.

The hybrid model: PLG plus sales

Pure PLG often stalls above a certain contract size. A buyer who signs a large annual contract wants a security review, a custom agreement and someone to call. Slack’s filing shows one answer: keep the self-serve entry and add a sales team for larger organizations.

In a hybrid model, the product brings in accounts and the PQL signal decides which ones a salesperson contacts. The free plan stays open to everyone. Sales spends time only where usage already shows intent. For how this changes acquisition cost and payback, see LTV and the LTV:CAC ratio.

When PLG fails: a fit test

PLG is not a fit for every product. Use this table to test yours. Each row is a condition from the mechanics above; the more rows land in the right-hand column, the more you need sales.

Question	PLG fits when	Sales-led fits when
Can one person get value alone?	Yes, in one session	Value needs a team, data import or setup project
How long until the first useful result?	Minutes to a day	Weeks
Who decides to buy?	The user, on a card	A committee, through procurement
What does a contract cost?	Low enough to expense	High enough to need approval
Does use spread inside a company?	Yes, people invite colleagues	No, each seat is a separate decision
What does a free user cost you?	Little (light hosting, no support)	A lot (compute, data, support time)

The last row decides whether you can afford a free plan at all. If each free account costs real money in compute or support, a time-limited trial limits the bill. The trade-offs between free plans, trials and paid tiers are set out in SaaS pricing models.

Common mistakes

Calling a free plan “PLG” without self-serve onboarding. If users must book a demo to see value, the free plan only collects email addresses. Why it happens: a free tier is easy to add, onboarding is hard. Instead: measure activation first and fix the path to the first result.
Measuring conversion against the wrong base. Free-to-paid against all sign-ups and against activated accounts can differ fourfold, as in the example (1.5% against 6%). Why it happens: dashboards pick one without saying which. Instead: write down the base and the time window next to every rate.
Giving away the feature people would pay for. If the free plan solves the whole problem for most users, few upgrade. Why it happens: generous limits look good at launch. Instead: put the limit where a team’s need grows, such as seats, history or admin controls.
Hiring sales too late, or too early. Without sales, large accounts stall in procurement; with sales too early, reps chase tiny accounts. Why it happens: PLG is treated as all or nothing. Instead: add sales when PQLs and contract sizes justify it, as Slack’s filing describes.

For how free entry, conversion and churn add up month by month, see the SaaS business model.

Sources

Slack Technologies, Form S-1, 2019, figures as of January 31, 2019.
Atlassian Corporation Plc, Form F-1, filed November 9, 2015.

In three sentences

Product-led growth lets people sign up, reach a useful result and pay on their own, through a free trial or freemium plan, self-serve onboarding and in-product expansion. In the worked funnel, raising activation from 25% to 35% adds 40% more new MRR, twice the effect of a 20% price rise. PLG fits products that one person can value in minutes and buy on a card; when contracts need committees and setup projects, add sales on top of the free entry, as Slack did.

Shadow SaaS: how unapproved apps get in and how to manage them

Ricardo Machado — Thu, 22 Oct 2026 16:00:00 GMT

Your finance team pays for a tool nobody in IT has heard of. A salesperson connected a note-taking app to the company calendar with two clicks, and it now reads every meeting invite. When someone leaves, you close their email account, but you have no list of the other apps they signed into. You need to know what is in use before you can decide what to allow.

Shadow SaaS is software-as-a-service used for work without the knowledge or approval of the people responsible for IT and security. It is the cloud form of shadow IT, and it is easy to start: a work email and a card are enough. If SaaS itself is new to you, start with What is SaaS?.

Shadow SaaS in plain terms

Think of the keys to an office. Every time someone has a copy cut for a contractor or a friend, the building gets one more key you do not control. Nobody meant harm. But when you change the staff, the copies still open the door.

An OAuth grant is that copy of the key. OAuth is the standard behind buttons such as “Sign in with Google”: the app asks for access to part of your account, such as calendar or files, and keeps it until someone revokes it. The scope is which doors the key opens. A grant that reads only your name and email is a small key. A grant that reads all mail and files is a master key.

The four routes in

Card and expense purchases. A team lead buys a subscription on a company card and claims it on expenses. The app holds company data, and the contract sits with one person.
Free sign-ups with a work email. Freemium tools need only an address. Data goes in long before any money changes hands.
OAuth grants. “Sign in with Google” or “Sign in with Microsoft” connects a third-party app to the company account, often with access to mail, calendar or files.
Add-ons inside approved tools. Browser extensions, marketplace apps and integrations installed inside software you already approved.

None of these routes requires the IT team. That is why a policy that bans shadow SaaS is not enough on its own.

How to find it

No single source sees everything. The table compares four discovery methods. It is assembled from the vendor documentation cited in each row and from how each method works.

Method	What it sees	What it misses
Expense and card records	Paid apps, cost, who bought them	Free tools, OAuth grants, apps paid by personal cards
Identity provider app reports	Apps connected with the company account and their scopes. Google Workspace lists configured and accessed apps under Security > Access and data control > API controls (Google)	Apps used with a personal login or a separate password
Network and endpoint logs	Traffic to known cloud apps. Microsoft Defender for Cloud Apps matches logs against a catalog of over 31,000 apps, scored on more than 90 risk factors (Microsoft Learn)	Apps not in the catalog, which “cannot” be discovered by default, and traffic outside your network unless endpoint agents report it
Asking teams	Why each tool is used, who owns it	Anything people forget or prefer not to mention

Use at least two methods. Expenses catch paid apps; identity reports catch the free ones connected to company accounts. Microsoft’s page adds that discovery data is analyzed and updated four times a day, so network-based discovery is continuous once it is running.

How to control it

Discovery gives you a list. Control means deciding, per app, whether it stays. Google Workspace gives a clear model. Each app can be set to one of four access levels (Google Workspace admin help, as of October 2026):

Trusted: access to all Google Workspace services, including restricted ones.
Limited: access only to unrestricted Google services.
Specific Google data: access only to the scopes you specify.
Blocked: no access to any Google service.

A separate setting covers apps nobody has configured yet. Its default is “Allow users to access any third-party apps”. The other two options allow only apps that request basic sign-in information, or none at all. If you have never looked at that setting, every app your users approve is allowed today. For the wider admin model of the suite, see Google Workspace as SaaS. For what a Microsoft 365 admin owns, see Microsoft 365 as SaaS.

Worked example: cost and review effort

Shadow SaaS has a cost line as well as a risk line. Example: a labeled hypothetical. An expense review finds three teams paying separately for the same note-taking tool, 4, 6 and 9 seats, each at $10 per seat per month billed monthly.

Seats: 4 + 6 + 9 = 19.
Current yearly cost: 19 x $10 x 12 = $2,280.
One company plan at a hypothetical $8 per seat per month, billed annually: 19 x $8 x 12 = $1,824.
Saving: $2,280 - $1,824 = $456 a year, or $456 / $2,280 = 20%.

The bigger gain is control. On the company plan, the 19 accounts can sit behind single sign-on and close when someone leaves.

The review itself takes time, so size it before you start. In a company of 120 employees, suppose each person has approved 3 OAuth apps on average.

Grants to review: 120 x 3 = 360.
At 2 minutes per grant: 360 x 2 = 720 minutes, or 720 / 60 = 12 hours.

Twelve hours is under two working days for one person, not a project. Sorting by scope first, mail and files before profile-only grants, puts the risky ones at the top.

Checklist: the first 30 days

Export 12 months of expense and card transactions and list every software vendor.
Export the OAuth app report from your identity provider and sort it by scope and number of users.
Check the setting for unconfigured third-party apps and decide whether the default stays.
Mark each app: approved, replace with an approved tool, or block.
Give every approved app an owner, a renewal date and a place in the offboarding checklist.
Publish the approved list and a request form with a promised answer time.
Repeat the expense and OAuth exports each quarter.

For the security controls a vendor should prove before an app is approved, see ISO/IEC 27017 explained.

Common mistakes

Blocking everything at once. Teams lose tools they rely on and move to personal accounts, which are harder to see. Why it happens: a long list of unknown apps looks like an emergency. Instead: block the high-risk scopes first and offer an approved alternative for the rest.
Relying on one discovery method. Network logs miss OAuth grants, and remote staff unless endpoint agents report; expenses miss free tools. Why it happens: each team owns one data source. Instead: combine expenses with identity provider reports at minimum.
Forgetting offboarding. A former employee’s account in an unapproved app keeps company data after they leave. Why it happens: offboarding lists only cover approved systems. Instead: add every approved app to the offboarding checklist and move shadow apps behind single sign-on.
Treating discovery as a one-time project. New tools arrive every month. Why it happens: the first cleanup feels like the finish line. Instead: run the expense and OAuth exports quarterly and keep the request form open.

Sources

Google Workspace admin help, Control which third-party and internal apps access Google Workspace data, checked October 2026.
Microsoft Learn, Cloud app discovery overview, checked October 2026.

In three sentences

Shadow SaaS is work software used without IT’s knowledge, and it arrives through card purchases, free sign-ups, OAuth grants and add-ons inside approved tools. Find it by combining expense records with your identity provider’s app report; in the example, consolidating 19 scattered seats saves 20% and reviewing 360 grants takes about 12 hours. Decide per app, block risky scopes first, give each approved app an owner and repeat the review every quarter.

SaaS valuation multiples: how revenue multiples work and what moves them

Ricardo Machado — Thu, 22 Oct 2026 11:00:00 GMT

You read that a software company sold for “five times revenue”, and you want to know what that means for your own company, or for one you are thinking of investing in. You also suspect that two people quoting a multiple are not always dividing the same numbers. They often are not, and the difference can move a valuation by millions.

A SaaS valuation multiple is the price of a company divided by a measure of its size, most often revenue or annual recurring revenue (ARR). It is a shorthand for comparing companies of different sizes. If SaaS itself is new to you, start with What is SaaS?.

A revenue multiple in plain terms

Think of houses priced per square foot. Two houses of the same size can sell for very different prices because of the street, the school district and the state of the roof. The price per square foot lets you compare them quickly. It does not explain why one is worth more. A revenue multiple does the same job for companies: it summarizes the price, and the reasons sit elsewhere, in growth, retention and margins.

Three definitions come first:

Equity value: what the shares are worth, the share price times the number of shares, or the price paid for all of them in a sale.
Enterprise value (EV): equity value plus debt minus cash. It is the price of the business itself, whoever finances it.
ARR (annual recurring revenue): the yearly value of active subscriptions at a point in time. Revenue, by contrast, is what was recognized over a period and can include services and one-time fees.

The formulas

The common multiples divide enterprise value by a size measure:

EV / revenue (trailing): enterprise value divided by revenue over the last 12 months or the last fiscal year.
EV / revenue (forward): enterprise value divided by expected revenue for the next 12 months.
EV / ARR: enterprise value divided by current ARR, used often for private SaaS companies.
EV / EBITDA: enterprise value divided by earnings before interest, taxes, depreciation and amortization. It only works for companies with positive earnings, which many growing SaaS companies do not have.

Use enterprise value, not equity value, on top. Revenue belongs to the whole business, whether it is financed by shareholders or by lenders, so the price you divide must include both.

Worked example: two companies with the same ARR

Example: two labeled hypothetical companies, each with $10 million of ARR.

Item	Company A (fast growth)	Company B (slow growth)
ARR today	$10.0M	$10.0M
ARR growth, next 12 months	40%	10%
Equity value	$60.0M	$28.0M
Debt	$5.0M	$4.0M
Cash	$15.0M	$2.0M
Enterprise value	$60.0M + $5.0M - $15.0M = $50.0M	$28.0M + $4.0M - $2.0M = $30.0M
EV / ARR today	$50.0M / $10.0M = 5.0x	$30.0M / $10.0M = 3.0x
ARR in 12 months	$10.0M x 1.40 = $14.0M	$10.0M x 1.10 = $11.0M
EV / forward ARR	$50.0M / $14.0M = 3.6x	$30.0M / $11.0M = 2.7x

Read the table from top to bottom. Same ARR, different prices. Company A’s higher multiple is mostly paying for growth: on next year’s ARR its multiple falls from 5.0x to 3.6x. Also look at equity against enterprise value. Company A’s equity value of $60.0M divided by ARR gives 6.0x, a full turn higher than its EV multiple, because A holds $10.0M more cash than debt. Quote equity over revenue as if it were EV over revenue, and your comparison is wrong before it starts.

How much one turn is worth

A “turn” is one point of multiple. On a company with $10 million of ARR, each turn is $10 million of enterprise value. For Company A, whose cash exceeds its debt by $10.0M, the shareholders’ value is enterprise value plus that $10.0M.

EV / ARR	Enterprise value ($10.0M ARR)	Equity value for Company A (EV + $10.0M net cash)
3.0x	$30.0M	$40.0M
5.0x	$50.0M	$60.0M
8.0x	$80.0M	$90.0M

The jump from 3.0x to 8.0x more than doubles the equity value, from $40.0M to $90.0M, with no change in ARR. That is why the factors behind the multiple matter more than the multiple itself.

A real deal, with the arithmetic shown

Public filings let you rebuild a multiple yourself. In May 2025, Salesforce agreed to acquire Informatica. Salesforce’s quarterly report on Form 10-Q states that Informatica’s Class A and Class B-1 holders would receive $25 in cash per share. It adds that the transaction “represents an equity value of approximately $8 billion”, net of the Informatica shares Salesforce already held (Salesforce Form 10-Q, quarter ended July 31, 2025).

Informatica’s results for fiscal 2024, filed with the SEC, give the denominators (Informatica Q4 and full-year 2024 results, Exhibit 99.1):

Total revenue for 2024: $1,640.0 million.
Total ARR at December 31, 2024: $1,725.5 million.
Net debt at December 31, 2024: $1,823 million term loan minus $1,232 million of cash and short-term investments = $591 million.

Example: an approximate multiple from those figures.

Enterprise value: $8,000M equity + $591M net debt = $8,591M.
EV / 2024 revenue: $8,591M / $1,640.0M = 5.2x.
EV / ARR: $8,591M / $1,725.5M = 5.0x.
Equity value / revenue, for comparison: $8,000M / $1,640.0M = 4.9x.

Treat these as approximations. The equity value is rounded in the filing and excludes the shares Salesforce already owned, and the balance sheet is from December 2024, five months before the agreement. This is one deal’s price, not a benchmark for the market or for your company.

What moves a SaaS multiple

The multiple summarizes what buyers believe about future cash. These factors explain most of it:

Growth. Faster ARR growth means more revenue in later years, as Company A shows.
Retention. Net revenue retention above 100% means existing customers grow on their own. Low retention means growth has to be bought again each year.
Gross margin. More of each dollar is left after hosting and support.
Profitability. A common heuristic, the Rule of 40, adds the growth rate and the profit margin. In two labeled hypotheticals, 40% growth with a -5% free cash flow margin and 10% growth with a 25% margin both score 35. The score is the same; the businesses are not.
Revenue quality. Recurring subscription revenue is more predictable than services and one-time fees, which is why EV / ARR and EV / revenue can differ.
Size and market conditions. Buyers price scale and the cost of borrowing at the moment of the deal, and both change outside your control.

For the retention and unit economics behind these factors, see LTV in SaaS and the SaaS business model. For the share of subscription revenue at five large public companies, see What is a SaaS company?.

Common mistakes

Dividing equity value by revenue and calling it a revenue multiple. In the example, Company A shows 6.0x on equity and 5.0x on enterprise value. Why it happens: the share price is the number in the headline. Instead: compute EV first, then divide.
Mixing trailing and forward multiples. A forward multiple looks lower for a growing company. Why it happens: reports do not always say which one they quote. Instead: label every multiple with its denominator and period.
Applying a public company’s multiple to a small private one. Public shares can be sold any day; a small private stake cannot, and its size and risk differ. Why it happens: public multiples are the only ones easy to find. Instead: use them as context and discount for size and liquidity, with the reason stated.
Counting services and one-time fees as ARR. It raises the denominator and flatters the business. Why it happens: total revenue is easier to pull from the accounts. Instead: count only active recurring subscriptions in ARR.

Sources

Salesforce, Form 10-Q for the quarter ended July 31, 2025, checked October 2026.
Informatica, Fourth quarter and full-year 2024 results, Form 8-K Exhibit 99.1, checked October 2026.

In three sentences

A SaaS revenue multiple is enterprise value (equity plus debt minus cash) divided by revenue or ARR, and it must say which denominator and period it uses. Two hypothetical companies with $10 million of ARR are worth 5.0x and 3.0x because one grows 40% a year and the other 10%, and Informatica’s filings give about 5.2x revenue. Compute EV yourself, label every multiple and look at growth, retention and margins to explain it.