What Does a SaaS Licence Really Cost? Understanding Cost Per Licence and Its Impact on Pricing

Every SaaS licence has a cost. The challenge is knowing what that cost actually includes.

When developing a SaaS application, considerable attention is usually given to functionality, user experience, security, and scalability. Pricing is often determined by looking at competing products, estimating what customers might be prepared to pay, or selecting a figure that appears commercially attractive.

But how much does it actually cost to provide each licence?

For many SaaS businesses, particularly those managing several applications, the answer is more complicated than dividing their cloud hosting bill by the number of paying customers.

Infrastructure, databases, authentication services, monitoring, security, third-party APIs, payment processing, support, and development all contribute to the cost of operating a SaaS business.

Some costs belong exclusively to one application. Others are shared across several applications. Some increase with customer numbers, while others remain relatively constant.

Understanding these differences is essential for determining whether a SaaS application is genuinely profitable.

Why Cost Per Licence Matters

Imagine two SaaS applications.

Application A costs £500 per month to operate and generates £2,000 in monthly subscription revenue.

Application B costs £1,500 per month to operate and generates £4,000 in monthly subscription revenue.

At first glance, Application B appears more attractive because it generates twice as much revenue.

However, the picture changes when we examine the economics of each licence.

Application B has a lower operating cost per licence, but Application A generates a higher contribution per licence and a better percentage margin.

Neither application is necessarily the better business. Application B may have greater growth potential, while Application A may be more profitable relative to its revenue.

The important point is that revenue alone does not tell you whether your SaaS pricing is sustainable.

Understanding the cost per licence provides a much clearer picture.

What Should Be Included in SaaS Cost Per Licence Calculations?

A useful cost model should recognise several different categories of expenditure.

1. Direct Application Infrastructure Costs

These are costs associated specifically with operating an individual SaaS application.

Typical examples include:

• Application hosting and compute resources.

• Database hosting and storage.

• Serverless functions and background processing.

• File and object storage.

• Data transfer and bandwidth.

• Application-specific backup and disaster recovery services.

• Dedicated logging and monitoring.

• Application-specific email delivery services.

• Dedicated security services.

For example, an application might use a managed database, a cloud hosting platform, and an object storage service.

If these resources are used exclusively by that application, their costs can be attributed directly to it.

However, many modern SaaS businesses share infrastructure between applications.

This introduces the next category.

2. Shared Infrastructure and Platform Costs

Shared costs are frequently overlooked when calculating SaaS profitability.

A business operating three SaaS applications might use the same:

• Cloud infrastructure account.

• Authentication platform.

• Monitoring and alerting service.

• DNS and CDN provider.

• Email delivery service.

• Backup platform.

• Security monitoring service.

• Development and deployment infrastructure.

• Logging and observability platform.

These services might generate a single monthly invoice even though they support several different applications.

Ignoring these shared costs makes individual applications appear more profitable than they actually are.

The solution is to allocate shared expenditure across the applications that benefit from it.

There are several approaches.

Equal allocation

The simplest method divides the cost equally between applications.

For example, a shared monitoring platform costs £120 per month and supports three applications.

Each application is allocated £40.

This approach is easy to understand but may be inaccurate when applications have significantly different usage levels.

Usage-based allocation

Where reliable usage information exists, allocating costs according to actual consumption is generally more accurate.

For example, three applications share a cloud infrastructure service costing £600 per month.

Usage could be measured through compute consumption, storage, API requests, transactions, or another relevant metric.

Licence-based allocation

Another approach allocates shared costs according to the number of active licences.

If one application has 1,000 licences and another has 500, the first receives two-thirds of the shared cost.

This can be useful where consumption is reasonably proportional to licence numbers.

However, it is less appropriate when one application is significantly more resource-intensive than another.

Revenue-based allocation

Shared costs can also be allocated according to each application's proportion of total revenue.

This may be appropriate for certain commercial overheads, but it is generally less suitable for technical infrastructure costs.

A high-priced application does not necessarily consume more infrastructure than a low-priced application.

The best allocation method depends on what drives the cost.

Where possible, use consumption-based allocation for technical services and a consistent, documented methodology for costs that cannot be measured directly.

3. Third-Party Services and API Costs

Modern SaaS applications increasingly depend on external services.

These might include:

• AI models and language model APIs.

• Geolocation and mapping services.

• SMS and messaging platforms.

• Document processing services.

• Email verification services.

• Data enrichment providers.

• External monitoring APIs.

• Payment processing services.

Some services charge a fixed monthly subscription.

Others charge according to usage.

AI services are a particularly important example.

An application that incorporates AI analysis might generate a relatively small API cost for an occasional user but a substantially higher cost for a customer running hundreds of analyses every day.

If the application is sold at a fixed monthly licence price, heavy users can become disproportionately expensive to support.

This makes it important to distinguish between:

Fixed third-party costs: Charges that remain broadly constant regardless of customer activity.

Variable third-party costs: Charges that increase with usage, transactions, API calls, or data consumption.

Both should be included in cost calculations, but they influence pricing decisions differently.

4. Security, Compliance and Operational Resilience

Security and compliance are essential components of operating a commercial SaaS application.

They are also costs that are easy to underestimate.

Relevant expenditure might include:

• Vulnerability scanning.

• Penetration testing.

• Security monitoring.

• Identity and access management.

• Backup and recovery testing.

• Compliance assessments.

• Security certifications.

• Audit logging.

• Business continuity services.

• Cyber insurance.

Some of these costs are incurred monthly, while others arise annually.

For example, an annual penetration test costing £2,400 represents an effective monthly cost of £200.

That cost should be reflected in the application's economics rather than being ignored until the invoice arrives.

If the assessment covers multiple applications, its cost should be allocated appropriately.

A further distinction is important: a cost may be necessary to operate the business without qualifying as a direct cost of delivering the service for accounting purposes.

For commercial decision-making, it is useful to maintain both direct service-delivery costs and a broader fully allocated operating cost.

5. Development, Maintenance and Support

A SaaS application is rarely finished.

Even when the initial development work is complete, there are continuing requirements for:

• Bug fixes.

• Security updates.

• Framework and dependency upgrades.

• API compatibility changes.

• Database maintenance.

• Performance improvements.

• Customer support.

• Documentation.

• Testing and quality assurance.

These activities have a cost, even when they are performed by the founder rather than an employee or external contractor.

Consider a founder spending 20 hours each month maintaining an application.

If the business assigns an internal cost of £50 per hour, that represents £1,000 per month of development and maintenance effort.

Whether that amount should be included in a particular cost-per-licence calculation depends on the purpose of the calculation.

For infrastructure optimisation, it may be excluded.

For understanding the long-term economic sustainability of the product, it should not be ignored.

Initial development investment is different from ongoing maintenance. It can be tracked separately and considered when evaluating investment recovery and longer-term profitability.

6. Sales, Marketing and Business Overheads

Not every business expense should be included in the direct cost of delivering a SaaS licence.

Sales, marketing, administration, accounting, legal services, and general management are often classified as operating expenses rather than cost of goods sold.

However, these expenses still need to be covered by the revenue the business generates.

For this reason, SaaS businesses benefit from understanding two different cost measures.

Direct Service Cost Per Licence

This represents the cost of delivering the SaaS service.

It typically includes attributable hosting, infrastructure, production third-party services, and other direct service-delivery expenses.

It is useful for calculating gross margin and understanding how efficiently the application operates.

Fully Allocated Operating Cost Per Licence

This includes direct service costs plus an appropriate allocation of other operating expenditure, such as development, administration, and shared business overheads.

It is useful for assessing whether the application's revenue can support the wider business.

These measures answer different questions.

Direct service cost tells you how efficiently you deliver the product. Fully allocated operating cost helps you understand whether the product can sustain the business.

It is important not to confuse the two.

How to Calculate SaaS Cost Per Licence

Let's work through a practical example.

Imagine a SaaS application with 400 active paid licences.

The business has identified the following monthly costs.

For this example, development, maintenance, and support are treated as additional operating costs rather than included in direct service costs. Accounting classifications may differ between businesses.

Step 1: Calculate Direct Service Cost Per Licence

The formula is:

Direct Service Cost Per Licence = Total Monthly Direct Service Costs ÷ Active Paid Licences

Using our example:

£650 ÷ 400 = £1.625 per licence per month

Rounded to the nearest penny, the direct service cost is £1.63 per licence.

Step 2: Calculate Fully Allocated Operating Cost Per Licence

The formula is:

Fully Allocated Operating Cost Per Licence = Total Monthly Allocated Operating Costs ÷ Active Paid Licences

£1,400 ÷ 400 = £3.50 per licence per month

The application therefore costs £3.50 per paid licence per month when the selected operating costs are included.

Step 3: Compare Costs Against Licence Revenue

Suppose the application sells licences for £8 per month, excluding VAT.

Monthly revenue:

400 × £8 = £3,200

The financial picture becomes:

This is a useful starting point.

The application generates £8 per licence, incurs £1.625 in direct service costs, and has a fully allocated operating cost of £3.50 per licence.

However, the analysis becomes more interesting when we consider growth.

What Happens to Cost Per Licence as a SaaS Application Grows?

One of the attractions of SaaS is that many operating costs do not increase proportionally with customer numbers.

A database supporting 400 licences might also support 800 licences without requiring twice the expenditure.

Similarly, monitoring, security, and administration costs may remain relatively stable as the customer base grows.

This creates economies of scale.

However, not every cost behaves this way.

API consumption, AI processing, storage, bandwidth, payment fees, and support requirements may increase with customer activity.

To illustrate this, assume our application has:

• Fixed and shared allocated operating costs of £1,000 per month.

• Variable costs averaging £1 per active paid licence per month.

The total monthly operating cost is therefore:

Total Operating Cost = £1,000 + (£1 × Number of Licences)

The results demonstrate an important principle.

As the number of licences increases, fixed costs are spread across a larger customer base, reducing the average cost per licence.

But this does not mean costs will continue falling indefinitely.

At some point, additional infrastructure capacity, support staff, database upgrades, or other investments may be required.

These create step changes in the cost structure.

A realistic SaaS financial model should therefore consider both variable costs and future increases in fixed capacity.

Why Average Cost Per Licence Is Not Enough

Average cost per licence provides a useful measure of overall application economics.

However, it can hide significant differences between customers.

Consider two customers paying £20 per month.

Customer A uses the application occasionally and generates £2 in monthly variable costs.

Customer B makes extensive use of AI processing and generates £15 in monthly variable costs.

Although both customers pay the same subscription, their contribution towards fixed costs and profit is very different.

This is particularly relevant to SaaS applications that use AI, process large volumes of data, or make extensive calls to third-party APIs.

For these applications, it is important to understand not only average cost per licence but also incremental cost per licence and cost per unit of consumption.

Incremental cost is the additional cost incurred by providing one more licence or supporting an additional unit of usage.

It helps determine whether adding a customer at a particular price will make a positive contribution.

A customer can contribute positively towards fixed costs even when their subscription price is below the current fully allocated average cost.

Conversely, a customer paying more than the average cost may still be unprofitable if their individual consumption is unusually high.

How Cost Per Licence Influences SaaS Pricing

Once you understand the economics of your application, pricing becomes a more informed commercial decision.

There are several approaches.

1. Cost-Plus Pricing

Cost-plus pricing starts with the cost of providing the service and adds a target margin.

For example, if the fully allocated operating cost is £4 per licence and the business wants a 60% margin on revenue, the calculation is:

Required Price = Cost Per Licence ÷ (1 − Target Margin)

£4 ÷ (1 − 0.60) = £10

The required selling price is therefore £10 per licence.

It is important to distinguish between margin and markup.

Adding a 60% markup to £4 produces a price of £6.40.

That generates a margin of only 37.5%, not 60%.

Cost-plus calculations can establish a useful pricing baseline, although the resulting price must still be tested against market demand and customer value.

2. Competitor-Based Pricing

Many SaaS providers use competitor pricing as a reference.

This is useful for understanding market expectations.

However, competitors may have very different cost structures.

An established SaaS provider with 100,000 licences can spread its fixed costs across a much larger customer base than a new provider with 200 licences.

Attempting to match an established competitor's pricing without understanding your own costs can create an unsustainable business model.

Competitor pricing should inform your strategy, not determine it.

3. Value-Based Pricing

Value-based pricing considers the commercial benefit delivered to the customer.

For example, an application that saves an IT team ten hours of work each month may provide considerably more value than its underlying infrastructure costs suggest.

Customers generally purchase outcomes, not cloud computing resources.

Understanding cost per licence helps establish the financial boundaries within which value-based pricing can operate.

It does not determine the maximum price a customer will pay.

4. Tiered Pricing

Cost analysis can also help determine how subscription tiers should be structured.

For example:

The prices above are illustrative.

The important consideration is whether the additional functionality and consumption included in each tier can be delivered at an acceptable margin.

Without understanding usage-related costs, a higher-priced tier can sometimes generate a lower margin than a basic subscription.

5. Usage-Based and Hybrid Pricing

Where consumption drives a significant proportion of costs, a purely fixed-price model may be inappropriate.

Alternatives include:

• Base subscription plus usage charges.

• Per-user licensing with API consumption allowances.

• Tiered transaction volumes.

• Credits for AI processing.

• Charges for additional storage or data retention.

• Overage charges beyond included allowances.

A hybrid model can provide customers with predictable baseline costs while protecting the SaaS provider from unusually high consumption.

The Importance of Licence Utilisation

Another consideration is the difference between licences purchased, licences allocated, and licences actively used.

These measures are not necessarily the same.

A customer might purchase 100 licences but allocate only 80.

Of those 80, perhaps only 60 are regularly active.

From the SaaS provider's perspective, the customer may generate revenue from all 100 licences while usage-related costs arise primarily from the 60 active users.

This distinction can be commercially important.

However, the denominator used in cost-per-licence calculations must be consistent with the question being answered.

For revenue and profitability analysis, paid licences are generally the appropriate denominator.

For understanding consumption costs, active users or actual units of usage may provide a more meaningful measure.

For capacity planning, provisioned licences or peak concurrent users may be more relevant.

A well-designed SaaS cost model should be able to distinguish between these measures rather than treating every licence as equivalent.

How Should Free Trials and Free Licences Be Treated?

Free trials, demonstration environments, internal accounts, and complimentary licences can all generate operating costs.

However, they do not generate corresponding subscription revenue.

If their costs are excluded from profitability calculations, the application may appear more profitable than it actually is.

Consider an application with:

• 400 paying licences.

• 100 free trial licences.

• Total monthly operating costs of £1,500.

Dividing the costs by all 500 licences produces an average of £3 per licence.

However, only 400 licences generate revenue.

For evaluating the economics of the paying customer base, the relevant calculation is:

£1,500 ÷ 400 = £3.75 per paid licence

This is a significant difference.

Free trials are not necessarily a problem. They may be an effective customer acquisition mechanism.

But their cost should be visible.

Where practical, trial-related expenditure should also be tracked separately so that the business can understand the cost of acquiring new customers.

Shared Costs Become More Important as Your SaaS Portfolio Grows

A founder operating a single SaaS application may initially manage costs using invoices and a spreadsheet.

Once the business operates several applications, this becomes more complicated.

A single cloud provider might support four applications.

One monitoring service may track all four.

A shared authentication platform may handle users across the entire portfolio.

Security services, domain registrations, API subscriptions, and operational tools may also be shared.

Without a consistent approach to cost allocation, it becomes difficult to answer basic commercial questions:

• Which application generates the highest margin?

• Which application consumes the most shared infrastructure?

• Is a growing application becoming more efficient?

• Are third-party API costs increasing faster than revenue?

• Which product could support a lower-priced licence tier?

• Would consolidating services reduce overall operating costs?

• Is an application genuinely profitable once shared overheads are included?

The problem is not simply collecting invoices.

It is understanding how those invoices relate to individual applications and their licences.

An effective cost model should allow costs to be assigned directly to an application or allocated across multiple applications using an appropriate methodology.

It should also ensure that shared expenditure is counted only once.

Monitor Cost Per Licence Over Time

A cost-per-licence calculation is not something that should be performed once and forgotten.

SaaS operating costs change continuously.

Cloud providers revise pricing.

AI models introduce new pricing structures.

Database consumption increases.

Applications gain additional functionality.

Customers change their usage patterns.

Security and compliance requirements evolve.

And the number of paying licences changes.

A SaaS application that is profitable today may become less profitable as its underlying costs increase.

Equally, an application that initially struggles to cover its fixed costs may become highly profitable as licence volumes grow.

Monitoring trends is therefore just as important as calculating the current figure.

Useful metrics include:

Monitoring these measures provides a much clearer understanding of the commercial health of a SaaS application.

It also allows pricing decisions to be based on evidence rather than assumptions.

SaaS Sentinel: Bringing SaaS Costs, Licences and Operational Visibility Together

This is one of the reasons SaaS Sentinel was developed.

Operating a single SaaS application is relatively straightforward to monitor using the tools provided by hosting platforms, infrastructure providers, and third-party services.

As the number of applications increases, however, the information becomes fragmented.

One service provides infrastructure costs.

Another provides application monitoring.

A third provides security information.

Payment platforms provide subscription revenue.

And shared services support several applications without necessarily identifying how their costs should be distributed.

The challenge becomes understanding the complete picture for each application.

SaaS Sentinel is designed to help SaaS operators bring operational, security, compliance, and financial visibility together.

The objective is to make it easier to understand whether an application is:

• Live: Available and performing as expected.

• Secure: Operating with appropriate security and compliance controls.

• Scalable: Capable of supporting growth without unexpected operational problems.

• Profitable: Generating sufficient revenue to support its operating costs and commercial objectives.

Cost per licence is an important part of that financial picture.

By understanding direct costs, shared expenditure, licence volumes, and pricing, SaaS operators can make better-informed decisions about how they develop, operate, and commercialise their applications.

The key is to move beyond monitoring individual invoices towards understanding the economics of each SaaS product.

Conclusion: Know Your Costs Before Setting Your Price

SaaS pricing should not be based solely on what competitors charge or what customers appear willing to pay.

Those factors matter, but they need to be considered alongside the actual cost of operating the application.

A reliable cost-per-licence model should:

1. Identify direct application operating costs.

2. Include an appropriate allocation of shared infrastructure and services.

3. Distinguish fixed costs from usage-related variable costs.

4. Account for security, compliance, maintenance, and support.

5. Separate direct service costs from wider business overheads.

6. Use appropriate licence and usage measures.

7. Consider the financial impact of free trials and complimentary licences.

8. Track changes in costs, revenue, and margins over time.

Most importantly, it should help answer a fundamental question:

Are we charging enough to deliver a reliable service, support future growth, and build a sustainable SaaS business?

Knowing your cost per licence will not tell you exactly what customers are prepared to pay.

But it will help you understand what your pricing needs to achieve.

And that is essential for building a SaaS application that is not just technically successful, but commercially sustainable.

Frequently Asked Questions