Founder insights11 min read

Your SaaS Generates Revenue. Is It Actually Profitable?

Revenue, gross profit, operating profit and cash are four different numbers. How AI usage costs can turn a growing subscription into a loss, with a worked example and safer pricing.

November 04, 2026Nawa Studio in Jeddah
A slim brass balance scale on a walnut desk in warm sunlight, tilted by a heavy stack of dark sage stones with fine circuit lines on the right, outweighing folded ivory invoice cards and brass tokens on the left.

Ten customers pay every month. The dashboard shows growth. The bank balance keeps shrinking. Both can be true at the same time.

Picture a founder with ten paying subscribers to an AI assistant for small clinics. Every renewal goes through on time, nobody has churned, and the monthly revenue chart only points up. Then the founder adds up what it actually costs to answer those customers' requests, and finds that each new account makes the month a little worse.

This scenario is a hypothetical, not a real company, but the mechanism is common enough to deserve a careful look. Revenue growth, gross profit, operating profit and cash flow are four different things. In traditional SaaS they often move together. In AI-native software, where costs scale with every token, tool call and task, they can drift apart quickly, and a fixed monthly subscription with no metering or caps can quietly produce negative margins.

Four numbers that are not the same number

Before you can judge whether a product is profitable, separate four measures. Founders who blend them make confident decisions on the wrong figure.

  1. Monthly recurring revenue (MRR). The predictable subscription revenue from active paying customers in a month. It excludes one-time onboarding or setup fees. If VAT applies, MRR is measured before VAT, because VAT collected belongs to the tax authority, not to you.
  2. Cost of goods sold (COGS). The direct cost of delivering the service: AI inference, hosting, the integrations that run each request, payment processing and the support that keeps customers working. Stripe's guide to SaaS gross margin draws this line between direct delivery costs and operating expenses.
  3. Gross profit and gross margin. Gross profit = revenue − COGS. Gross margin = (revenue − COGS) ÷ revenue. This tells you whether each riyal of revenue survives the cost of serving it.
  4. Operating profit. Gross profit minus operating expenses: sales and marketing, general and administrative costs, research and development that is not part of running the live service, and any other applicable operating costs. Income taxes and zakat sit separately again.

And one more distinction: profit is not cash in the bank. An annual contract paid upfront improves cash today without changing monthly profit. A large customer paying sixty days late can leave you short of cash while your accounts show a profit. Track both.

The hidden AI expense stack

A classic SaaS product mostly pays for servers that grow slowly with users. An AI product pays for work. The Bessemer Venture Partners AI pricing playbook makes the point that AI products carry real incremental costs, both inference and the human review that often sits behind it, which traditional software pricing was never designed to absorb.

The stack usually includes:

  • Input and output tokens. Long prompts, attached documents and verbose answers all count. Output is often priced differently from input.
  • Model choice. Rates vary widely between models and change over time. Check the provider's live page, such as the OpenAI API pricing documentation, rather than a number you remember from last quarter.
  • Context length. Sending the full conversation history or a whole knowledge base on every request multiplies cost.
  • Retries and tool calls. An agent that searches, calls an API, fails, and tries again may run five model calls for one visible answer.
  • Human review. If a person checks outputs before they reach the customer, that time is a direct cost.
  • Integrations and messaging. Third-party APIs, SMS or WhatsApp delivery and data connectors.
  • Hosting and databases, including vector storage and logs.
  • Payment processing on each charge.
  • Direct customer support that keeps the service working day to day.

Not all of this tracks seats or subscriptions. Two customers on the same plan can differ several times over in usage. That is why per-customer attribution matters: you need to know which accounts are profitable, not only whether the total is.

Draw the boundary clearly. Paid ads, sales commissions, office rent, legal fees and work on future features are operating expenses, not COGS. Write down your cost accounting assumptions once, so that next month's margin is comparable with this month's.

A worked example: ten customers, one subscription price

Hypothetical example. This is an illustrative Saudi B2B tool, not a real Nawa venture or customer. All figures are monthly, in Saudi riyals, and exclude any applicable VAT.

Ten customers each pay SAR 199 a month, giving SAR 1,990 in MRR. Direct costs to serve them:

  • AI inference: 300
  • Hosting and database: 150
  • Messaging and integrations: 100
  • Direct customer support: 250
  • Payment processing: 60
  • Total COGS: 860
  • Gross profit: 1,990 − 860 = 1,130
  • Gross margin: 1,130 ÷ 1,990 = 56.8%

Now add SAR 1,400 of separate operating expenses for marketing, administration and other overhead. The illustrative operating result is 1,130 − 1,400 = an operating loss of SAR 270.

That is not a disaster. The service covers its direct costs, and more customers at the same cost profile would eventually cover overhead. The question is whether the cost profile holds.

The stress case: same revenue, heavier usage

Keep the same ten customers and the same SAR 1,990. Suppose two accounts start running long documents through the assistant and an agent loop retries failed tool calls without limit. AI inference rises from SAR 300 to SAR 1,200.

  • AI inference: 1,200
  • Hosting, messaging, support and payments: unchanged at 560
  • Total COGS: 1,760
  • Gross profit: 1,990 − 1,760 = 230
  • Gross margin: 230 ÷ 1,990 = 11.6%
  • Operating result with the same SAR 1,400 overhead: a loss of SAR 1,170

Nothing about revenue changed. The loss more than quadrupled. And notice where it came from: a small number of heavy users and an unbounded retry policy. This is concentration risk in cost form. If your two most active customers drive most of your inference bill, adding more customers like them deepens the hole instead of filling it.

Four pricing models and when each fits

The BCG, Stripe and AWS report on SaaS pricing found that 57% of the hypergrowth companies in Stripe's survey had adopted hybrid pricing. That is a sample of fast-growing companies, not all SaaS businesses, but it reflects a real shift toward pricing that tracks variable AI cost and delivered value.

Flat subscription

One price for access. Use it when usage per customer is predictable and narrow, or when you enforce firm fair-use limits. Tradeoff: simple to buy, but your heaviest users are subsidised by your lightest, and margin depends entirely on usage staying stable.

Per usage or per task

Charge for a unit the buyer understands: a processed invoice, a generated report, a completed booking. Use it when value scales clearly with volume. Tradeoff: revenue becomes less predictable, and buyers need a way to estimate their bill. Never bill customers in raw tokens they cannot read or control.

Tiered or hybrid

A base subscription with a clear included allowance, then a published overage rate. Use it when you want predictable revenue and protection from extreme usage. Tradeoff: tiers need careful design, and the allowance must be stated in plain terms.

Outcome-based

Charge only when a defined result happens, such as a resolved support ticket. Use it only when outcomes are verifiable and both sides agree in writing how they are defined and measured. Tradeoff: strong alignment with value, but disputes are likely if definitions are loose. A completed AI task or a generated answer is not the same as a successful business outcome; do not price as if it were.

A seven-step cost control playbook

  1. Measure cost per event. Attribute model, tool and infrastructure cost to each task and each account, not only to the monthly invoice.
  2. Log tokens, tool calls and retries, safely. Record counts, model names, durations and outcomes. Do not store raw customer prompts, documents or API keys in logs unless strictly necessary, and then mask, restrict and expire them. If you process personal data in Saudi Arabia, review your obligations under the Personal Data Protection Law with qualified advice.
  3. Cap consumption. Set limits on retries, agent steps, document size and monthly allowance per plan. Tell customers what the limits are.
  4. Route simple requests to cheaper models where quality remains acceptable, and confirm that with a regular quality check, not assumption.
  5. Cache repeated safe answers where the content is not personal and caching is permitted.
  6. Test prompt and context efficiency. Trim instructions, retrieve only relevant passages and measure cost and quality before and after.
  7. Review account-level unit economics monthly. Rank accounts by gross margin, investigate outliers and test pricing or tier changes transparently, with customers informed of what changes and why.

Six metrics for the founder dashboard

Stripe's overview of essential SaaS metrics is a useful reference for definitions. Keep the dashboard short:

  • MRR: recurring subscription revenue, before VAT, excluding one-time fees.
  • Gross margin: (revenue − COGS) ÷ revenue, calculated with the same cost assumptions every month.
  • Cost per completed successful action: total direct cost of an action type, including failures and retries, divided by the number that actually succeeded.
  • Gross margin by account or cohort: shows whether profitability is broad or carried by a few customers.
  • Customer acquisition cost (CAC) and payback: sales and marketing spend per new customer, and the months of gross profit needed to recover it.
  • Churn and net revenue retention: how much recurring revenue you keep from an existing customer base, including upgrades and downgrades. State which customers are included and over what period; small bases make these numbers volatile.

The Nawa view: economics that scale with usage

At Nawa, a product earns more engineering only when its economics can grow with usage instead of against it. That means testing price against value early, measuring cost per account from the first pilot and treating heavy users as a design question rather than a surprise.

If you are still working toward your first paying customers, our guide to reaching your first SAR 1,000 in SaaS MRR covers that earlier stage, and seven Micro-SaaS ideas for Saudi Arabia shows narrow problems where costs are easier to bound.

Building an AI product and want a second view on its economics? Talk to Nawa.

FAQ

Does MRR equal profit?

No. MRR is recurring subscription revenue. Profit appears only after direct costs and operating expenses, and cash depends on when money actually arrives and leaves.

Is usage-based pricing always best for AI products?

No. It suits products where value scales with volume and buyers can predict their bill. Many teams prefer a hybrid: a base subscription with a clear allowance.

How do I estimate token costs before launch?

Run realistic tasks, record input and output tokens, retries and tool calls, then multiply by the provider's current rates. Repeat with heavy and light user scenarios, not only the average.

Can AI margins improve over time?

They can, through model routing, caching, shorter context and better pricing design. Provider prices also change. Do not plan on improvements you have not measured.

What is a healthy gross margin?

There is no universal threshold. It depends on stage, pricing, cost structure and how much human work sits inside the service. Track the trend and the spread across accounts.

Evidence limits

The sources below include vendor and investor perspectives and survey samples; they are not representative scientific findings. Figures such as the hybrid pricing share apply to the stated sample. API rates and pricing models change frequently. Every number in the examples above is illustrative.

Sources & further reading