DEV Community: Ciroandrea

Your AI Execution Can Be Correct — and Still Lose Money

Ciroandrea — Mon, 10 Aug 2026 08:54:00 +0000

Everything Worked

Imagine a customer triggers an AI workflow in production.

The request reaches the authorization layer.

The customer has an active entitlement.

There is enough usage capacity available.

Authorization succeeds.

The workflow starts.

It retrieves the required context, calls the model, executes an external tool and produces the expected result.

Usage is recorded correctly.

The customer's balance is updated.

The result is delivered.

Observability shows green.

No exception was raised.

No duplicate execution occurred.

No usage event was lost.

No reconciliation issue appeared later.

From an engineering perspective, the system behaved exactly as designed.

Everything worked.

Now look at the same execution from a different perspective.

The workflow required several model calls.

The context was larger than usual.

One external API added another variable cost.

An intermediate step failed and had to be retried.

The final result required additional processing before it became useful to the customer.

None of this made the execution incorrect.

The customer was entitled to the workflow.

The infrastructure handled the retry safely.

Usage was measured accurately.

The customer was charged according to the product's rules.

And yet, after accounting for what it actually cost to produce the useful outcome, the execution generated less revenue than it consumed.

Nothing failed.

The execution simply wasn't economically healthy.

That distinction matters because production systems are usually designed to detect incorrect behaviour.

They are much less likely to tell you when technically correct behaviour is producing unhealthy economics.

Correct Execution Is Not the Same as Healthy Execution

AI infrastructure has become increasingly good at answering questions about runtime correctness.

Was the request authorized?

Was the customer entitled to use the feature?

Was consumption applied atomically?

Were retries handled idempotently?

Was usage recorded correctly?

Did application state remain synchronized with commercial state?

These are important questions.

Getting them wrong can produce duplicate consumption, incorrect access, lost revenue or broken customer experiences.

But even a system that answers all of them correctly still leaves another question unresolved:

Was this execution economically sustainable?

Consider two properties of the same workflow.

Runtime perspective	Economic perspective
Request authorized correctly	Cost justified by the revenue or value produced
Entitlement valid	Customer remains healthy to serve
Usage recorded correctly	Usage cost remains sustainable
Retry handled safely	Total retry cost remains acceptable
Execution completed	Completed outcome remains economically viable
Customer charged correctly	Revenue adequately covers cost-to-serve

The left side does not guarantee the right side.

A request can be perfectly authorized and still be expensive.

Usage can be perfectly metered and still represent an unhealthy consumption pattern.

A retry can be perfectly idempotent and still add legitimate cost to an already low-margin workflow.

A customer can be charged exactly according to plan and still cost more to serve than the revenue that plan generates.

This is not an argument against runtime correctness.

Quite the opposite.

Runtime correctness is foundational.

Without it, the economic picture cannot be trusted in the first place.

But correctness tells us whether the system behaved according to its rules.

It doesn't necessarily tell us whether those rules produced a healthy business outcome.

That is a different problem.

And AI makes that distinction increasingly difficult to ignore.

AI Makes This Problem Different

Traditional software has always had infrastructure costs.

Servers cost money.

Databases cost money.

Storage, bandwidth and third-party services cost money.

But for many SaaS products, the marginal cost of one additional customer action is relatively small.

A user opens another dashboard.

Creates another project.

Runs another database query.

Sends another internal request.

The infrastructure performs more work, but the economics of the business rarely depend on the profitability of that individual action.

AI changes this relationship.

A single customer request may trigger a chain of operations with directly measurable variable costs:

Model inference
Input and output tokens
GPU workloads
Vector search
Retrieval pipelines
External APIs
Agent tool calls
Image generation
Voice processing
Human review

And those costs are rarely uniform.

The same feature may be inexpensive for one execution and significantly more expensive for another.

A short support question may require one small model call.

A complex research task may require a long context window, multiple model calls, retrieval, several tools and repeated reasoning steps.

Both may appear in the product as the same feature.

Operationally, they are not the same workload.

Economically, they may be completely different.

This creates a tighter connection between architecture and business economics.

Model selection matters.

Context size matters.

Retry behaviour matters.

Workflow design matters.

Tool selection matters.

Exception handling matters.

Not because every expensive execution is necessarily bad.

An expensive workflow can be perfectly healthy if it creates enough value or supports sufficient revenue.

The important point is that execution now has an economic dimension that cannot always be inferred from whether the request succeeded.

The Cost of the Successful Request Is Not the Whole Cost

Suppose an AI workflow eventually completes successfully.

The final execution consumed $0.18 of model inference.

It would be tempting to record $0.18 as the cost of producing the result.

But production workflows rarely exist as isolated model calls.

The actual execution history may look more like this:

Customer Request
       ↓
Model Call
       ↓
Tool Call
       ↓
Tool Timeout
       ↓
Retry
       ↓
Second Model Call
       ↓
External API
       ↓
Human Correction
       ↓
Successful Outcome

The final model call may have cost $0.18.

But $0.18 is not necessarily what it cost the business to produce the outcome.

The failed attempt still consumed resources.

The retry still consumed resources.

The tool call may have generated a third-party charge.

The external API may have its own usage cost.

Human intervention may have introduced support or operational overhead.

The useful economic unit is therefore not always the final successful request.

Sometimes it is the entire path required to produce the successful outcome.

That distinction matters.

Imagine two executions producing the same customer-visible result:

Execution A

1 model call
1 successful tool call
No retry

Total execution cost: $0.24

Execution B

2 model calls
1 failed tool call
1 retry
1 successful tool call

Total execution cost: $0.61

From a product perspective, both workflows succeeded.

From a billing perspective, the customer may have paid exactly the same amount.

From an economic perspective, they are not equivalent.

This is where execution-level visibility becomes useful.

Not because every internal operation needs to become a financial metric.

That would create complexity of its own.

Attribution has a cost.

Instrumentation has a cost.

Human support can be difficult to allocate precisely.

Shared infrastructure costs rarely map perfectly to a single request.

The objective is not perfect accounting at arbitrary granularity.

It is enough visibility to understand where economically meaningful differences are coming from.

For some products, model and API costs may provide sufficient visibility.

For others, retries, workflow stages or human intervention may materially change the economics and deserve to be included.

The appropriate level of attribution depends on the product.

But the principle remains:

The cost of a successful AI outcome may include every meaningful attempt required to produce it—not only the request that finally succeeded.

This also changes how we think about failure.

A failed execution is not always financially neutral.

The customer may never receive an outcome.

The business may still have paid for the work performed before the failure.

At sufficient scale, that difference becomes important.

A technically correct usage ledger can tell you exactly what was consumed.

Understanding whether that consumption created sustainable value requires another layer of analysis.

Customer Profitability Is a Distribution Problem

Aggregate metrics are useful because they compress complexity.

Total revenue.

Average revenue per customer.

Average infrastructure cost.

Gross margin.

At a company level, these numbers can provide a reassuring picture.

But averages hide distribution.

And in AI products, that distribution can matter significantly.

Consider two customers on the same plan.

Both pay:

$200 / month

Both use the same product.

Both appear as equally valuable accounts in a revenue dashboard.

Their underlying economics, however, may look very different.

Customer A

Short context
Standard model
Predictable workflow
Few retries
Minimal support

Monthly cost-to-serve: $38

Customer B

Long context
Expensive model routing
Multiple tool calls
Frequent retries
Exception-heavy workflows
Regular support intervention

Monthly cost-to-serve: $176

The revenue is identical.

The economics are not.

Customer A contributes substantial margin.

Customer B may still be profitable, but only narrowly.

Add a few unusual execution paths, additional support requests or expensive failures and that account could become unprofitable without anything appearing wrong in the billing system.

The customer paid exactly what they were supposed to pay.

The product delivered exactly what was promised.

The problem exists in the relationship between revenue and cost-to-serve.

This is why customer profitability is fundamentally a distribution problem.

A portfolio can look healthy in aggregate while containing customers with radically different economic profiles.

For example:

100 Customers
      ↓
Average Gross Margin: 70%
      ↓
Looks Healthy

But underneath that average:

70 customers → high margin
20 customers → moderate margin
 8 customers → low margin
 2 customers → negative margin

The 70% average is not wrong.

It is simply incomplete.

It tells you about the portfolio.

It doesn't tell you where profitability comes from.

I explored this problem from the business side in Your AI Business Can Grow While Your Margins Shrink, where I looked at why averages can hide radically different customer and workflow economics.

That distinction becomes more important when AI consumption varies significantly between accounts.

It also means that high usage should not automatically be treated as a problem.

A power user may generate substantial cost while also generating substantial revenue, retention value or strategic importance.

Another customer may consume far less infrastructure but still be economically unattractive because of pricing, support overhead or inefficient workflows.

Usage alone doesn't determine profitability.

The relationship between revenue, consumption and cost-to-serve does.

The question isn't which customers use the most AI. It's whether the economics of serving them remain healthy.

Workflow Profitability May Matter More Than Model Cost

Customer-level profitability provides one useful perspective.

But it still leaves an important question unanswered.

Why is one customer more expensive to serve than another?

The answer often exists one level deeper.

Inside the workflows they execute.

AI engineering teams naturally monitor infrastructure metrics such as:

Token consumption
Model cost
Latency
API calls
GPU utilization
Retry rates

These metrics are valuable.

They help teams understand how the system behaves.

But they don't necessarily explain whether that behaviour creates enough value to justify its cost.

Consider two workflows.

Workflow A

Cost: $1.40

Outcome:
A qualified sales opportunity

Workflow B

Cost: $0.22

Outcome:
An internal summary that is rarely used

Workflow B is cheaper.

That doesn't automatically make it economically better.

The relevant question depends on what the product is trying to accomplish.

Customers don't usually purchase tokens, inference calls or tool executions as ends in themselves.

They purchase outcomes.

A resolved support ticket.

A processed document.

A completed research task.

A qualified lead.

A successfully completed agent workflow.

This suggests another useful unit of analysis:

Cost per useful outcome.

Instead of measuring only:

Cost per Model Call

some products may benefit from understanding:

Total Cost of Workflow
        ↓
Successful Outcome
        ↓
Cost per Useful Outcome

Suppose a support automation processes 1,000 conversations.

The infrastructure metrics show:

Total AI Cost: $420

That number is useful.

But imagine only 600 conversations are resolved without escalation.

Looking at successful outcomes provides additional context:

$420 total execution cost
        ÷
600 resolved conversations
        =
$0.70 per resolved conversation

Now the infrastructure cost can be compared with something closer to business value.

That might help answer questions such as:

Is automation still cheaper than the alternative?
Which workflows create the most expensive successful outcomes?
Do retries materially change outcome economics?
Does changing models improve cost without reducing completion quality?
Are some execution paths expensive but still economically justified?

This metric is not universally applicable.

Defining a "useful outcome" can be difficult.

Some products create value gradually rather than through discrete completions.

A research assistant may influence a decision without producing an easily measurable economic event.

An AI coding tool may save developer time that is difficult to attribute precisely.

Multi-step agent systems may produce value across several workflows.

Attribution can quickly become more complex than the insight it provides.

The objective is therefore not to force every AI product into a single profitability metric.

The architectural lesson is simpler.

Infrastructure cost becomes more useful when it can be connected to the customer activity and business outcome that produced it.

Token cost tells you what the model consumed.

Workflow cost tells you what the system consumed.

Outcome economics begin to tell you whether that consumption was worth it.

Those are different levels of understanding.

Visibility Before Optimization

Once teams discover that AI costs vary significantly across customers and workflows, the natural reaction is to optimize.

Use a cheaper model.

Reduce context size.

Introduce stricter limits.

Change pricing.

Route requests differently.

Reduce retries.

These may all be reasonable decisions.

But they assume something important:

That the team already understands where the economic problem actually is.

Often, it doesn't.

A rising model bill tells you that spending increased.

It doesn't tell you which customers caused the increase.

A high token count tells you that the system processed more context.

It doesn't tell you whether that context produced valuable outcomes.

A high retry rate tells you that executions required additional attempts.

It doesn't tell you whether those retries were necessary, wasteful or economically significant.

And a declining gross margin tells you that the business is becoming more expensive to operate.

It doesn't tell you why.

Before optimization, teams increasingly need enough visibility to connect several layers of the system:

Customer
    ↓
Workflow
    ↓
Execution
    ↓
Retries / Failures
    ↓
Usage
    ↓
Cost
    ↓
Outcome

The goal is not perfect attribution.

Perfect attribution may be impossible or unnecessarily expensive.

The goal is decision-quality visibility.

Enough information to distinguish between very different situations.

For example, suppose infrastructure costs increase by 20%.

Without additional context, the obvious response might be to move more traffic to a cheaper model.

But deeper visibility could reveal that the increase came primarily from one workflow experiencing repeated tool failures.

The model wasn't the problem.

Or perhaps one customer segment began using significantly longer contexts because of a new product behaviour.

The pricing model may need attention.

Or perhaps costs increased because customers are completing more high-value workflows.

In that case, higher infrastructure spending may be perfectly healthy.

The same cost increase can therefore represent:

Waste

or

Product Growth

or

Pricing Misalignment

or

Workflow Inefficiency

or

Healthy High-Value Usage

The number alone cannot tell you which one.

Context can.

This is why optimization without visibility is mostly guesswork.

Engineering Is Becoming Part of Economic Analysis

Once execution data is connected to customers and workflows, familiar engineering signals begin to acquire a second meaning.

A retry rate is no longer only a reliability metric.

It may also explain why a workflow costs more than expected.

A metering discrepancy is no longer only a data-quality issue.

It may distort the company's understanding of customer profitability.

A stale entitlement is no longer only an access-control problem.

It may allow expensive execution under commercial conditions that are no longer valid.

A reconciliation gap is no longer only an operational inconsistency.

It may prevent the business from knowing whether recorded revenue and actual consumption describe the same reality.

This does not mean engineering teams should become finance teams.

Nor does it mean every infrastructure decision should be reduced to margin.

Reliability, latency, quality and customer experience still matter independently.

The change is that these concerns can no longer always be evaluated in isolation.

In AI products, infrastructure behaviour increasingly influences the economic behaviour of the business.

Consider a model-routing decision.

Engineering might evaluate:

Latency
Quality
Reliability
Cost per call

Those are useful dimensions.

But once the same execution is connected to workflow outcomes, another comparison becomes possible:

Model A

Higher cost per call
Better completion rate
Fewer retries
Higher useful-outcome rate

versus:

Model B

Lower cost per call
Lower completion rate
More retries
More escalations

The cheaper model is not necessarily the cheaper workflow.

And the more expensive workflow is not necessarily the worse business decision.

The answer depends on the outcome economics.

This is where engineering telemetry begins to become business intelligence.

Not because infrastructure metrics suddenly become financial metrics.

But because connecting them provides context that neither side has independently.

From Runtime Correctness to Economic Correctness

Up to this point, we have been discussing two different properties of an AI system.

The first is familiar.

The system should behave correctly.

Requests should be authorized.

Consumption should be atomic.

Retries should be safe.

Usage should be accurate.

Commercial and application state should remain aligned.

Runtime authorization is one part of that problem. In The Most Expensive AI Request Is the One You Should Have Blocked, I explored why deciding whether an AI request should execute can itself become an economic decision.

We can think of this as Runtime Correctness.

It answers:

Did the system execute correctly?

But the examples throughout this article expose another question.

Suppose all of those guarantees hold.

The request was authorized.

The workflow executed correctly.

The retry was legitimate.

Usage was recorded accurately.

The customer was charged exactly according to plan.

And the completed outcome still cost more to produce than its economics could support.

The runtime was correct.

The business outcome was unhealthy.

A useful way to reason about this second property is Economic Correctness.

Not as an established industry category, but as a mental model.

It asks:

Did this technically correct execution also make economic sense?

The distinction looks simple:

Runtime Correctness	Economic Correctness
Was execution authorized?	Was execution economically justified?
Was consumption correct?	Was cost-to-serve sustainable?
Was usage accurate?	Did usage produce sufficient value?
Were retries safe?	Did retries preserve healthy outcome economics?
Was commercial state respected?	Did the resulting execution remain commercially viable?

Neither replaces the other.

Economic analysis built on incorrect runtime data cannot be trusted.

And technically correct execution without economic visibility can still produce an unhealthy business.

A sustainable AI product increasingly needs to understand both.

Correct Execution
        +
Economic Understanding
        ↓
Healthier AI Economics

This does not mean every request needs a real-time profitability calculation before it executes.

That would often be impractical, unnecessary or based on incomplete information.

Some economics can only be understood after the workflow completes.

Some costs arrive later.

Some outcomes are difficult to quantify.

Some customers should rationally be served at lower margins for strategic reasons.

Economic correctness is therefore not a binary runtime rule.

It is a way of asking whether the technical behaviour of the system remains aligned with the economic objectives of the business.

And asking that question requires connecting information that traditionally lives in different systems.

The Missing Connection Is Runtime Intelligence

The signals required to understand AI economics already exist in many production systems.

The problem is that they usually exist in different places.

Payment systems understand commercial state.

Authorization systems understand whether execution is allowed.

AI providers report model consumption.

Application logs describe execution behaviour.

Metering systems record usage.

Observability platforms capture failures and retries.

Product systems may know whether the workflow produced a useful outcome.

Finance sees revenue and aggregate cost.

Each system contains part of the story.

Very few contain the whole story.

A simplified execution may therefore generate information across several layers:

Commercial State
        ↓
Authorization
        ↓
Execution
        ↓
Metering
        ↓
Retries / Failures
        ↓
Outcome
        ↓
Economics

Individually, these signals answer useful questions.

Commercial state tells us what the customer purchased.

Authorization tells us whether the operation was allowed.

Execution telemetry tells us what actually happened.

Metering tells us what was consumed.

Failure data tells us what additional work occurred.

Outcome data tells us whether the workflow achieved its objective.

Economic data tells us what serving that activity ultimately cost.

The harder problem is connecting them.

Suppose a customer generates unusually high model spend.

That fact alone tells us very little.

Perhaps the customer is unprofitable.

Perhaps they are one of the company's most valuable accounts.

Perhaps a specific workflow is inefficient.

Perhaps a provider started producing more failures.

Perhaps retries increased after a deployment.

Perhaps usage increased because the product is delivering significantly more value.

The cost signal becomes useful only when it can be interpreted in context.

This suggests an architectural direction that goes beyond traditional observability.

We can think of it as Runtime Intelligence.

Not as an established infrastructure category, and not as a system that automatically knows which business decisions are correct.

Rather, as the ability to connect runtime behaviour with the commercial and economic context surrounding it.

Instead of observing only:

What happened?

the system begins helping teams understand:

What happened?

For which customer?

Inside which workflow?

Under which commercial conditions?

At what cost?

After which failures or retries?

And with what outcome?

That additional context can make infrastructure data substantially more useful to both engineering and business teams.

It can help reveal patterns such as:

Customers whose cost-to-serve changes significantly over time
Workflows where retries materially affect economics
Execution paths responsible for disproportionate infrastructure spending
Features whose usage grows faster than the value they produce
Expensive workflows that remain healthy because they generate high-value outcomes
Differences between expected and observed consumption

The objective is not to automate every decision.

Visibility may lead to a pricing change.

Or a workflow redesign.

Or different model routing.

Or better retry handling.

Or a product decision.

Or no change at all.

The important step is understanding the system well enough to make that decision deliberately.

Runtime Intelligence, in this sense, is less about autonomous optimization and more about connecting technical behaviour to economic consequence.

Closing

Return to the execution from the beginning.

The customer was authorized.

The entitlement was valid.

The workflow executed successfully.

Retries were handled correctly.

Usage was recorded accurately.

The customer was charged exactly according to the product's rules.

Observability showed green.

Everything worked.

That remains an important achievement.

But we can now ask one more question.

What did it actually cost to produce the useful outcome?

Perhaps the answer shows a healthy execution.

Perhaps the workflow was expensive but generated enough value to justify that cost.

Perhaps the customer remains highly profitable despite heavy usage.

Or perhaps several technically correct behaviours combined to produce an outcome whose economics are difficult to sustain.

Runtime correctness alone cannot distinguish between those situations.

It was never designed to.

That is why the next challenge for AI infrastructure may not simply be making execution more reliable.

It may be making the economics produced by that execution more visible.

Not every company needs request-level profitability.

Not every workflow has an easily measurable outcome.

Not every expensive customer should be optimized for margin.

And not every economic decision belongs inside the runtime.

But as AI products become more dependent on variable-cost execution, the connection between infrastructure behaviour and business health becomes harder to ignore.

The question evolves from:

Is my AI system working correctly?

to something broader:

Is my AI business actually healthy — and why?

That is the problem I'm currently exploring with Licenzy.

Licenzyis being developed around the idea of an AI Monetization Runtime: infrastructure for keeping commercial state and AI execution correctly aligned.

The direction we're exploring beyond that foundation is Runtime Intelligence — connecting reliable runtime behaviour with better visibility into the customer, workflow and economic outcomes it produces.

That work is still an exploration.

But the underlying question is already useful regardless of which infrastructure a team ultimately uses.

Your AI system may be working exactly as designed.

The harder question is whether you understand the economics it is producing.

Your AI Business Can Grow While Your Margins Shrink

Ciroandrea — Mon, 03 Aug 2026 07:56:21 +0000

Most founders love seeing graphs like this.

Revenue      ↗
Customers    ↗
Usage         ↗

Everything appears to be moving in the right direction.

More customers.

More subscriptions.

More AI requests.

More revenue.

For traditional SaaS businesses, those trends usually tell a reassuring story.

Growth often brings economies of scale.

Serving one additional customer typically costs very little.

Average metrics become reasonably good indicators of business health.

AI products are different.

An AI business can continue growing while quietly becoming less profitable.

Revenue increases.

Usage increases.

Customers remain happy.

Yet margins slowly deteriorate.

Not because pricing is wrong.

Not because customers stop paying.

But because the economics of AI are hidden inside the distribution of usage rather than the averages shown on most dashboards.

Growth tells you that the business is expanding.

It does not necessarily tell you that the business is becoming healthier.

Traditional SaaS trained us to think differently

For years, software companies learned to evaluate success through a relatively small set of financial metrics.

Dashboards typically focused on indicators such as:

Monthly Recurring Revenue (MRR)
Annual Recurring Revenue (ARR)
Average Revenue Per User (ARPU)
Gross Margin
Customer Growth

These metrics work remarkably well for many traditional SaaS products.

Once the software has been built, serving one additional customer usually introduces very little additional cost.

A customer logs in.

Views another dashboard.

Creates another project.

Runs another report.

The infrastructure certainly performs more work, but the marginal cost of those actions often remains relatively small.

That economic model shaped the way many founders learned to interpret growth.

If revenue increased while gross margins remained healthy, the business was generally moving in the right direction.

Average metrics provided a reliable picture of the company's overall health.

AI products challenge that assumption.

The cost of serving one additional request is no longer close to zero.

Every interaction may consume resources that directly affect profitability.

The averages still matter.

They simply stop telling the entire story.

AI products changed the economics

Unlike traditional SaaS, AI products often incur variable operational costs every time customers use the product.

A single interaction may trigger:

Model inference
Token consumption
GPU time
Retrieval pipelines
Agent execution
Image generation
Voice synthesis
External APIs

Each of those operations consumes infrastructure with a measurable financial cost.

Two customers paying the same subscription price may generate completely different operating costs.

One may submit a handful of lightweight requests each day.

Another may execute hundreds of long-running agent workflows.

From a revenue perspective, they appear identical.

From a profitability perspective, they may have almost nothing in common.

This is one of the biggest economic shifts introduced by AI.

Revenue becomes increasingly predictable.

This shift also changes how companies think about AI monetization after payment, something I explored in Why Payment Is Only the Beginning for AI Products.

Costs become increasingly variable.

That changes the questions founders need to ask.

Instead of looking only at how much revenue the business generates, they also need to understand where that revenue creates healthy margins—and where it quietly erodes them.

Why averages become dangerous

Most dashboards summarize a business using averages.

Average revenue per customer.

Average infrastructure cost.

Average gross margin.

Average usage.

Those metrics are useful.

The problem is that they can also be deeply misleading.

Imagine an AI product with one hundred paying customers.

The dashboard reports:

Revenue Growth        ↑
Average Margin        68%
Customer Growth       ↑

Everything appears healthy.

Now imagine looking beneath those averages.

100 Customers

↓

5 customers generate 42% of AI costs

↓

3 workflows consume 58% of total compute

↓

1 AI agent produces most retry-related spending

The business hasn't changed.

The perspective has.

The averages suggested a healthy company.

The distribution reveals where profitability is actually being won—or lost.

This is one of the biggest differences between traditional SaaS and AI products.

AI costs rarely distribute evenly across customers or workflows.

A small number of interactions often accounts for a disproportionately large share of infrastructure spending.

Revenue grows across the entire customer base.

Costs tend to concentrate.

Without visibility into that distribution, healthy-looking metrics can hide unhealthy economics.

Averages tell you how the business looks. Distributions tell you how the business behaves.

Workflow profitability is becoming more useful than token counts

When AI costs begin increasing, many teams instinctively monitor token consumption.

That is a reasonable starting point.

Tokens are measurable.

Easy to aggregate.

Easy to visualize.

Unfortunately, they rarely answer the question founders actually care about.

The business doesn't exist to optimize token counts.

It exists to produce profitable outcomes.

Consider two AI workflows.

Workflow A

120,000 tokens

↓

Generates a contract worth £500

Workflow B

35,000 tokens

↓

Produces an internal summary worth almost nothing

Looking only at token usage, Workflow A appears far more expensive.

Looking at business value, it may be significantly healthier.

The important question is no longer:

How many tokens did we consume?

It becomes:

Was the outcome worth the cost of producing it?

That shift changes what companies need to measure.

Instead of asking only:

Which model generated the cost?
How many tokens were consumed?

Teams increasingly need answers such as:

Which customer generated this cost?
Which workflow generated this cost?
Which feature generated this cost?
Did the completed workflow remain profitable?
Did retries significantly change its economics?
Would we make the same execution decision again?

This is why workflow profitability is becoming a far more meaningful metric than raw infrastructure usage.

Customers purchase outcomes.

Healthy AI businesses increasingly optimize the economics of those outcomes rather than the cost of individual model calls.

Visibility must come before optimization

When founders notice AI costs increasing, the first instinct is often to revisit pricing.

Should subscriptions become more expensive?

Should credits be introduced?

Should usage limits change?

Should top-ups become mandatory?

Those are reasonable questions.

But they all assume the company already understands where its costs come from.

In practice, many teams don't.

They know the cloud bill increased.

They know model usage is growing.

They know margins are changing.

They often don't know why.

Pricing decisions made without operational visibility are mostly educated guesses.

Before changing pricing, companies increasingly need answers to questions such as:

Which customers are consistently profitable?
Which workflows generate the highest costs?
Which AI features create the most business value?
Which execution paths require repeated retries?
Which providers contribute most to operational costs?
Which outcomes become unprofitable after infrastructure overhead is included?

Without this visibility, optimisation becomes reactive.

The business adjusts prices without understanding the underlying economics.

That may improve revenue.

It rarely fixes the real problem.

Understanding the distribution of costs should come before attempting to redistribute them.

Engineering is becoming part of business strategy

For many years, engineering and business strategy were largely separate conversations.

Engineering focused on building reliable systems.

Finance focused on revenue, margins and profitability.

Product teams focused on customer experience.

AI products increasingly blur those boundaries.

Today, infrastructure decisions directly influence business performance.

A metering error can distort customer profitability.

A retry policy can change workflow economics.

I've previously written about why retry behaviour is increasingly becoming an economic concern rather than just a reliability concern in Why Retry Safety Is Becoming a Business Problem for AI Products.

Incorrect usage accounting can make pricing appear successful when margins are quietly deteriorating.

A missing authorization check can turn profitable customers into unprofitable ones.

None of these issues begins in a pricing spreadsheet.

They begin inside the runtime.

This is one of the most significant shifts introduced by AI.

Infrastructure is no longer just responsible for delivering software.

It increasingly determines how healthy the business becomes as it scales.

Engineering decisions now influence questions that traditionally belonged to finance:

Which customers are profitable?
Which workflows should be encouraged?
Which features justify their operational cost?
Which execution paths should be redesigned?

The conversation is no longer simply about building systems that work.

It is about building systems whose economics continue to work as the company grows.

Engineering no longer supports business strategy. In AI products, it increasingly shapes it.

A new way of thinking

Traditional SaaS businesses often begin with a familiar question:

How much revenue are we generating?

That question still matters.

But for AI products, it is no longer sufficient.

A more useful question is:

Which customers and workflows are actually profitable?

Those questions produce very different decisions.

The first encourages growth.

The second encourages sustainable growth.

One useful mental model looks like this:

Revenue
      ↓
Customer
      ↓
Workflow
      ↓
Runtime Events
      ↓
Infrastructure Cost
      ↓
Business Outcome

Each layer provides context that averages alone cannot reveal.

Revenue tells you that customers are paying.

Runtime events explain what actually happened.

Infrastructure costs show what the company spent.

Business outcomes reveal whether those costs created value.

Healthy AI companies increasingly optimise across the entire chain—not just the first metric.

Growth remains important.

But understanding how growth is generated is becoming just as important as measuring how much growth exists.

Revenue tells you how fast your AI business is growing. Profitability distribution tells you how healthy it is becoming.

Closing

The first generation of AI products taught us how to integrate models.

The second generation is teaching us how to operate them sustainably.

Those are different challenges.

Building an AI application is becoming increasingly accessible.

Building an economically healthy AI business remains considerably harder.

The companies that succeed won't necessarily be the ones with the largest models or the lowest inference costs.

They'll be the ones that understand the economics hidden inside their own infrastructure.

That means looking beyond averages.

Looking beyond monthly revenue.

Looking beyond total token consumption.

Instead, they'll understand:

Which customers generate healthy margins.
Which workflows create sustainable value.
Which runtime behaviours quietly erode profitability.
Which engineering decisions influence business outcomes.

Growth is still important.

But growth without visibility can be misleading.

Revenue can continue increasing while the underlying economics quietly deteriorate.

Healthy AI businesses increasingly optimise for something more fundamental than growth alone.

They optimise for sustainable profitability.

Learn More

As AI products mature, a new infrastructure pattern is beginning to emerge.

Rather than treating payments, runtime execution and business analytics as completely separate systems, many teams are starting to connect them into a single operational layer.

Its objective isn't simply to process payments or record usage.

It's to keep commercial state, runtime execution and business economics aligned throughout the lifecycle of every AI request.

That increasingly includes capabilities such as:

Runtime authorization
Usage accounting
Cost attribution
Retry-safe execution
Idempotent consumption
Reconciliation
Workflow profitability
Revenue leakage prevention

Some companies build this infrastructure internally.

Others adopt specialised platforms designed for AI monetization.

Solutions such as Licenzy are part of this emerging AI Monetization Runtime category, helping engineering teams maintain economically correct AI execution while products continue to scale.

The category is still evolving.

The underlying problem, however, is already here.

Understanding how infrastructure shapes profitability is becoming just as important as understanding how infrastructure delivers software.

Why Retry Safety Is Becoming a Business Problem for AI Products

Ciroandrea — Mon, 27 Jul 2026 10:28:18 +0000

Retries are one of the oldest reliability patterns in modern software.

A request times out.

The client retries.

A webhook fails to arrive.

The provider delivers it again.

A worker crashes halfway through a job.

The queue schedules another attempt.

For decades, these behaviours have been considered normal.

Distributed systems are inherently unreliable.

Networks fail.

Services become temporarily unavailable.

Messages are delayed.

Retries exist because failures are inevitable.

They help systems recover automatically without exposing every transient error to the customer.

In many ways, they became one of the foundations of reliable software.

But AI products have changed the economics of retrying.

A retry is no longer just another attempt to complete a request.

It may trigger another model inference.

Another image generation.

Another agent execution.

Another external API call.

Another usage event.

Another infrastructure cost.

Reliability is still the objective.

But reliability alone is no longer enough.

Modern AI systems increasingly need something else.

They need economic correctness.

A retry should not only recover from failure.

It should recover without changing the economic outcome of the original request.

Reliability solved one problem

Distributed systems cannot assume that every operation succeeds on the first attempt.

Temporary failures happen constantly.

Connections drop.

Providers become temporarily unavailable.

Requests time out.

Queues delay delivery.

External APIs return transient errors.

Without retries, many of these situations would become customer-visible failures.

An AI response might never be delivered.

A payment confirmation might never reach the application.

A workflow could remain permanently incomplete because of a momentary network interruption.

Retry mechanisms were designed to solve exactly this problem.

Rather than failing immediately, the system simply tries again.

Used carefully, retries improve resilience by allowing infrastructure to recover from short-lived failures such as:

Network interruptions
Temporary provider outages
Rate limits
Queue delivery failures
Database contention
External API instability

This pattern has become so common that most engineers rarely question it.

Retries are simply considered good engineering practice.

And in most distributed systems, they are.

The objective is straightforward:

Complete the requested operation despite temporary failure.

For years, that objective was enough.

AI products introduced a second requirement.

Completing the operation is no longer sufficient.

The system also needs to complete it without accidentally duplicating its economic effects.

...but AI changed the economics

Traditional SaaS products usually have a relatively low marginal cost per request.

A customer refreshes a dashboard.

Clicks the same button twice.

An API endpoint receives a duplicate request.

The infrastructure still performs additional work, but in many applications that extra cost is operationally insignificant.

AI products behave differently.

Almost every meaningful execution consumes resources with measurable financial impact.

A single request may involve:

Model inference
Input and output tokens
GPU time
Image generation
Speech synthesis
Vector search
External APIs
Agent orchestration

Retrying that request may repeat some or all of those costs.

From the customer's perspective, only one action occurred.

From the infrastructure's perspective, multiple expensive operations may have been executed.

The system successfully recovered.

The economics did not.

That is what makes retries fundamentally different in AI products.

A retry is no longer just another request.

It is another financial decision.

When retries quietly become revenue leakage

Most retry-related failures don't look like financial incidents.

They look like ordinary production behaviour.

A request times out.

A queue redelivers a message.

A worker restarts.

A webhook arrives twice.

An AI agent repeats the same tool call.

Individually, none of these events appears particularly alarming.

Most engineering teams have seen them hundreds of times.

The application usually continues working.

Customers still receive a response.

Operational dashboards remain green.

Yet every unnecessary execution consumes resources that can never be recovered.

That's what makes retry-related revenue leakage so difficult to detect.

Nothing appears broken.

The business simply spends more money than it intended.

Consider a few common production scenarios.

Duplicate executions

A client times out while waiting for an LLM response.

Believing the request failed, it retries.

The original inference had already completed.

The second request executes the same expensive operation again.

The customer receives one answer.

The infrastructure pays for two.

Concurrent retries

Two workers receive the same retry event.

Neither knows the other has already started processing it.

Both execute the workflow.

Only one result is ultimately returned.

The duplicate compute has already been consumed.

Race conditions

Two requests validate the same credit balance at almost exactly the same time.

Both conclude sufficient credits remain.

Both begin execution.

The commercial state allowed one operation.

The runtime performed two.

Delayed commercial state

A payment succeeds.

A webhook is delayed.

Another system still believes the customer has no active entitlement.

Or the opposite happens.

Access should already have expired, but stale state allows expensive AI execution to continue.

The infrastructure isn't behaving maliciously.

It's simply making decisions using outdated information.

Incorrect usage accounting

Execution succeeds twice.

Usage is recorded once.

Or execution succeeds once.

Usage is recorded twice.

Neither situation necessarily causes an outage.

Both quietly distort the economics of the product.

Revenue leakage rarely comes from one catastrophic engineering failure. It usually emerges from thousands of perfectly ordinary events that were never designed to preserve economic correctness.

Retry safety is no longer only about reliability

For years, retry safety meant one thing.

Recover from failure.

If the customer eventually received the expected result, the system had done its job.

AI products raise the standard.

A successful retry should not only recover the operation.

It should preserve the economics of the original request.

That means protecting several independent concerns at the same time:

Idempotency
Runtime authorization
Atomic consumption
Usage correctness
Reconciliation

These capabilities solve different problems.

Together, they protect the business from duplicate economic effects.

The objective is no longer simply:

Don't lose the request.

It is:

Execute exactly once.

Consume exactly once.

Record usage exactly once.

Charge exactly once.

In practice, distributed systems cannot always guarantee literal exactly-once execution.

Networks remain unreliable.

Providers still experience failures.

Messages can still be duplicated.

The practical objective is different.

The customer should experience one economically correct outcome, even if the infrastructure internally performs multiple attempts.

That distinction is becoming one of the defining architectural principles of modern AI products.

Retry safety requires more than retry logic

For many years, retry safety was largely considered a transport problem.

How many attempts should the client make?

Should retries use exponential backoff?

How long should the system wait before trying again?

Those questions are still important.

But they don't answer a more fundamental one.

What exactly is being retried?

That distinction matters.

A network request is not the same as a business operation.

One customer action may generate several technical requests.

A timeout.

A worker restart.

A queue redelivery.

A provider retry.

Treating every request as a completely new execution is operationally simple.

It is also economically dangerous.

Modern AI infrastructure increasingly needs to understand the difference between retrying a request and retrying an intent.

The customer didn't ask for multiple model executions.

They asked for one outcome.

This is the same architectural shift behind why authorisation should happen before expensive AI execution rather than after it.

If you're interested in that topic, I explored it in The Most Expensive AI Request Is the One You Should Have Blocked.

Protecting that outcome requires more than retry logic.

It requires architectural guarantees.

Idempotency

Every business operation should have a stable identity.

If the same operation reaches the execution layer multiple times, the infrastructure should recognise it as the same intent.

A transport retry should not become a second economic event.

Atomic consumption

Authorizing access, consuming credits and starting execution should not happen as unrelated steps.

If those operations are separated, concurrent requests can observe inconsistent state and spend the same balance more than once.

Economic decisions should happen atomically.

The system should secure the right to spend before expensive compute begins.

Runtime authorization

A successful payment doesn't guarantee that every future execution is valid.

Before retrying an expensive operation, the infrastructure should still verify:

Available credits
Active entitlements
Spending limits
Customer status
Runtime policies

Retries should preserve the original authorization intent rather than bypass it.

Usage correctness

Recording usage sounds straightforward.

In production, it rarely is.

A model may execute successfully while usage recording fails.

Usage may be written before execution completes.

A retry may generate duplicate usage events.

Or no usage event at all.

The objective isn't simply to count requests.

It's to ensure that recorded usage reflects what actually happened.

Reconciliation

Even well-designed distributed systems drift over time.

A provider may complete work after the caller has already timed out.

A webhook may arrive minutes later.

An internal ledger may disagree with an external billing record.

Reconciliation exists to compare expected state with observed reality and repair those differences before they become permanent.

Retries are unavoidable.

Economic inconsistency doesn't have to be.

Billing systems cannot solve this

Billing platforms solve an essential problem.

They establish the commercial relationship between a company and its customers.

They answer questions such as:

Has the customer paid?
Is the subscription active?
Was the invoice settled?
Should the next renewal occur?

Runtime infrastructure answers a completely different set of questions.

Has this operation already executed?
Is this retry part of the same business intent?
Has usage already been consumed?
Should another model inference begin?
Can this workflow safely continue?

Neither layer replaces the other.

Both are necessary.

Billing determines the commercial state.

Runtime infrastructure preserves that state while expensive AI execution is taking place.

I explored this separation between commercial state and runtime behaviour in more detail in Why Payment Is Only the Beginning for AI Products, where I explain why payment alone cannot govern AI execution.

A simplified architecture increasingly looks like this:

Commercial State
        ↓
Runtime Authorization
        ↓
Idempotency
        ↓
AI Execution
        ↓
Usage Accounting

Payment answers whether the customer is allowed to use the product.

Runtime determines whether the next execution remains economically correct.

That distinction becomes increasingly important as AI products scale.

Engineering decisions are becoming financial decisions

For a long time, engineering and finance measured success using different metrics.

Engineering focused on:

Availability
Latency
Throughput
Error rates

Finance focused on:

Revenue
Margins
Customer profitability
Operating costs

AI products are bringing those worlds closer together.

Infrastructure decisions increasingly influence financial outcomes.

A retry policy affects infrastructure costs.

A race condition can consume duplicate credits.

Incorrect usage accounting distorts customer profitability.

A stale commercial state may allow expensive execution that should never have happened.

None of these problems begin in finance.

They begin in software.

That represents a significant shift in how AI products should be designed.

Reliability is no longer measured only by whether the system eventually succeeds.

It is increasingly measured by whether the business outcome remains economically correct after recovery.

The engineering conversation is changing from:

Did the request succeed?

to:

Did the request succeed without compromising the economics of the product?

Those are no longer the same question.

Operational correctness is becoming economic correctness

Reliable systems recover from failure.

Economically correct systems recover without changing the intended business outcome.

That difference may appear subtle.

In production, it changes everything.

A workflow that executes twice may still produce the correct response.

A duplicate inference may remain invisible to the customer.

An agent may successfully finish its task after multiple retries.

Operationally, the system looks healthy.

Financially, it may be creating unnecessary cost, inaccurate usage records or incorrect profitability metrics.

Success can no longer be measured only by completed requests.

It increasingly needs to be measured by economically correct outcomes.

One useful mental model looks like this:

Customer Intent
        ↓
Runtime Authorization
        ↓
Economic Validation
        ↓
AI Execution
        ↓
Usage Accounting
        ↓
Reconciliation
        ↓
Business Economics

Every stage protects a different aspect of the business.

The objective isn't simply to make AI execute reliably.

It's to ensure that every execution remains aligned with the commercial reality of the product.

A new infrastructure layer is emerging

As AI products become more sophisticated, many teams are discovering that neither billing systems nor AI providers own this responsibility.

Billing platforms establish the commercial relationship.

AI providers execute workloads.

Application code orchestrates workflows.

Usage systems record consumption.

Each layer solves a different problem.

None of them is responsible for maintaining economic correctness across the entire execution lifecycle.

That responsibility increasingly sits between commercial state and AI execution.

Commercial State
        ↓
Authorization
        ↓
Execution
        ↓
Usage Accounting
        ↓
Business Economics

This emerging infrastructure layer exists to ensure that expensive AI operations happen under the correct commercial conditions, produce the correct usage records and preserve the intended economic outcome.

Rather than replacing billing or AI providers, it complements them by connecting business rules with runtime behaviour.

As AI products continue to mature, this architectural pattern is becoming increasingly common.

Platforms such as Licenzy are part of this emerging AI Monetization Runtime category, focusing on runtime authorization, usage correctness, idempotent consumption and economically correct AI execution.

The important trend, however, is larger than any individual platform.

The market is gradually recognising that reliability alone is no longer sufficient.

Modern AI infrastructure must also preserve economic correctness while software is running.

Final thoughts

Retries have always been part of building reliable distributed systems.

That hasn't changed.

What has changed is the cost of getting retries wrong.

In AI products, every unnecessary execution has the potential to consume compute, distort usage, reduce workflow profitability and quietly erode margins.

A retry is no longer just another technical attempt.

It is another economic event that must be handled correctly.

The next generation of AI infrastructure will still care about availability, latency and resilience.

But it will also care about something equally important.

Whether every successful recovery preserved the economics of the business.

Because in modern AI products, reliability is no longer the finish line.

Economic correctness is.

Learn More

As AI systems evolve, a new category of infrastructure is emerging between commercial state and AI execution.

Its purpose is not simply to process payments or meter usage.

Its purpose is to maintain economically correct execution throughout the entire AI runtime.

This increasingly includes capabilities such as:

Runtime authorization
Idempotent consumption
Usage correctness
Retry-safe execution
Atomic consumption
Reconciliation
Revenue leakage prevention

Some engineering teams build this layer internally.

Others adopt specialised infrastructure designed specifically for AI monetization.

Platforms such as Licenzy are part of this emerging AI Monetization Runtime category, helping engineering teams connect commercial state with runtime behaviour while protecting both operational reliability and business economics.

Most AI Revenue Leakage Isn't Fraud. It's Engineering.

Ciroandrea — Fri, 17 Jul 2026 12:23:18 +0000

When founders hear the term revenue leakage, they usually picture obvious threats.

Fraud.

Chargebacks.

Stolen accounts.

Unauthorized payments.

Those problems certainly exist.

But for many AI companies, they're not where the largest losses actually come from.

The biggest source of margin erosion is often far less dramatic.

It's engineering.

Not because engineers make mistakes.

But because modern AI products execute millions of decisions every day, and small operational inefficiencies quietly accumulate into significant business costs.

Revenue leakage in AI products rarely arrives all at once.

It happens one unnecessary request at a time.

One duplicate execution.

One retry.

One stale permission.

One workflow that should never have run.

Individually, these events seem insignificant.

Together, they slowly erode profitability.

The challenge isn't simply preventing fraud.

It's preventing infrastructure from spending money when it shouldn't.

The way most founders think about revenue leakage

Most software companies have traditionally viewed revenue leakage as a finance problem.

The usual suspects are familiar:

Payment fraud
Chargebacks
Account sharing
Subscription abuse
Failed collections

These are legitimate concerns.

They're also relatively visible.

Finance teams monitor them.

Payment providers offer protection.

Risk systems are designed to detect them.

AI businesses introduce a different kind of leakage.

One that often happens entirely inside the product itself.

No customer is acting maliciously.

No payment has failed.

No fraud has occurred.

The infrastructure simply consumes more resources than the business intended.

That difference is important.

Traditional revenue leakage usually happens because money isn't collected.

AI revenue leakage often happens because unnecessary costs are incurred.

The invoice may be completely correct.

The margins are not.

Invisible engineering decisions that quietly destroy margins

Few engineering teams intentionally design systems that waste money.

Most revenue leakage comes from perfectly reasonable engineering decisions made in isolation.

Consider a few examples.

A network timeout triggers an automatic retry.

An AI agent accidentally executes the same workflow twice.

A webhook is delivered more than once.

A customer's entitlements haven't refreshed yet.

A background job continues after access has expired.

A request reaches an expensive model before credits are validated.

None of these situations looks particularly alarming.

In many cases, the customer receives exactly the experience they expected.

From an operational perspective, the system appears healthy.

From a financial perspective, however, every unnecessary execution consumes resources that can never be recovered.

That's what makes engineering-driven revenue leakage so difficult to identify.

The application continues working.

Customers remain satisfied.

Revenue continues growing.

Meanwhile, margins quietly decline in the background.

The most dangerous revenue leakage isn't the kind that breaks your product. It's the kind that leaves your product working exactly as expected while quietly increasing operating costs.

Every unnecessary AI request has a real cost

Traditional SaaS products are remarkably forgiving.

A customer refreshes a dashboard.

Clicks the same button twice.

Reopens a page.

In most cases, the additional infrastructure cost is almost negligible.

AI products operate under a different economic model.

Nearly every meaningful interaction consumes resources that have a measurable cost.

A single request may involve:

LLM inference
Input and output tokens
GPU time
Image generation
Speech recognition
Speech synthesis
Vector database queries
External APIs
Agent orchestration

Unlike traditional software, execution itself becomes part of the cost structure.

That changes how engineering decisions should be evaluated.

A duplicate request isn't simply redundant.

It may trigger another model inference.

Another API call.

Another workflow.

Another bill.

Individually, these costs are usually small.

At scale, they become part of the product's unit economics.

Every unnecessary execution directly reduces the margin generated by that customer, that workflow, or that feature.

Revenue leakage isn't always measured by money that never arrives.

Sometimes it's measured by money that never needed to be spent.

Why billing systems cannot solve this

When AI companies begin thinking about monetization, billing is often the first layer they implement.

That's entirely reasonable.

Customers need to subscribe.

Invoices need to be generated.

Payments need to be collected.

Billing systems answer an essential business question:

Did the customer pay?

For AI products, however, another question becomes equally important:

Should this request execute?

They're runtime decisions. I've explored why this question has become fundamental for modern AI products in The Most Expensive AI Request Is the One You Should Have Blocked.

A successful payment doesn't necessarily mean the next AI request should run.

The customer may have exhausted their credits.

Their subscription may still be active while a premium entitlement has expired.

A spending limit may have been reached.

A duplicate request may already be processing.

A retry may already have consumed the necessary resources.

None of those situations are billing problems.

They're runtime decisions.

Billing records financial events.

Runtime infrastructure governs resource consumption.

This distinction between payment and runtime control is becoming increasingly important as AI monetization evolves.

As AI products become more sophisticated, separating those responsibilities becomes increasingly important.

One determines whether money has been collected.

The other determines whether more money should be spent.

Revenue leakage starts before invoices are generated

Many companies try to measure revenue leakage after the fact.

They analyze invoices.

Review cloud bills.

Investigate customer profitability.

Build dashboards to understand where margins are disappearing.

Those activities are valuable.

But they're also reactive.

By the time a dashboard shows an unnecessary AI execution, the infrastructure has already spent the money.

The real financial decision happened much earlier.

It happened the moment the request entered the system.

Healthy AI products increasingly introduce business validation before expensive compute begins.

Typical checks include:

Authorization
Entitlement validation
Credit verification
Spending limits
Duplicate detection
Runtime policies

Only after those checks pass does the application execute expensive AI workloads.

This approach doesn't eliminate operational costs.

It prevents unnecessary ones.

That's an important distinction.

The cheapest AI request isn't the one that uses fewer tokens.

It's the one that never needed to execute in the first place.

Engineering is becoming part of financial operations

For many years, engineering and finance operated in largely separate worlds.

Engineering focused on reliability.

Finance focused on revenue, costs and profitability.

AI products are bringing those worlds closer together.

Today, backend architecture directly influences business metrics such as:

Gross margins
Customer profitability
Workflow profitability
Infrastructure efficiency
Pricing sustainability

A retry strategy can affect operating costs.

A race condition can consume duplicate compute.

An authorization decision can determine whether a customer generates profit or loss.

These are no longer purely technical concerns.

They're business decisions implemented in software.

The more AI becomes part of a company's product, the more engineering becomes part of its financial operations.

Building economically healthy AI businesses increasingly depends on building economically aware infrastructure.

A new infrastructure layer is emerging

As AI products mature, a new architectural pattern is beginning to appear.

Instead of moving directly from payment to execution, many teams are introducing an additional decision layer.

Payment
    ↓
Authorization
    ↓
Execution
    ↓
Usage Tracking
    ↓
Business Economics

Each stage answers a different question.

Layer	Primary Question
Payment	Did the customer pay?
Authorization	Should this request execute?
Execution	Produce the requested AI outcome.
Usage Tracking	What resources were actually consumed?
Business Economics	Was this interaction economically healthy?

This isn't simply another infrastructure component.

It's a shift in how AI businesses think about monetization.

The objective is no longer just collecting revenue.

It's ensuring that every AI request contributes to a sustainable business model.

As this architectural pattern continues to evolve, a new category is beginning to emerge around it.

Rather than focusing exclusively on payments or billing, these platforms help companies make economically informed decisions before expensive AI resources are consumed.

Solutions such as Licenzy are part of this emerging AI Monetization Runtime category, providing the infrastructure that connects payment, authorization, usage and business economics into a single runtime layer.

The category is still taking shape.

But the underlying problem it addresses is becoming increasingly common as AI products scale.

Final thoughts

When founders hear the phrase revenue leakage, they often imagine fraud.

In AI businesses, the bigger risk is frequently much quieter.

It's infrastructure spending money when it didn't need to.

One duplicate execution.

One unnecessary retry.

One stale entitlement.

None of these events seem significant on their own.

Together, they shape the economics of the business.

That's why revenue leakage is increasingly becoming an engineering discipline as much as a financial one.

The companies that build healthy AI businesses won't simply be the ones with the best models or the lowest token prices.

They'll be the ones that make better decisions before compute begins.

Because in modern AI products, every engineering decision has the potential to become a financial decision.

The Most Expensive AI Request Is the One You Should Have Blocked

Ciroandrea — Mon, 13 Jul 2026 09:26:39 +0000

The most expensive AI request isn't the one that costs the most.

It's the one that should never have executed in the first place.

Many AI teams spend months optimizing inference speed.

Reducing latency.

Choosing better models.

Lowering token costs.

Those are all worthwhile optimizations.

But they only happen after the decision to execute has already been made.

A more important question often comes first.

Should this request execute at all?

That question becomes increasingly important as AI products grow.

Every unnecessary request consumes resources.

Every duplicate execution compresses margins.

Every unauthorized inference quietly increases costs.

Building an AI application is no longer just about making models run efficiently.

It's about deciding when they should run in the first place.

Why this matters

Imagine an AI customer who has:

Exhausted their monthly credits
Reached their spending limit
Lost access to a premium feature
Canceled their subscription

Now imagine your infrastructure still executes the request.

The model generates a response.

Tokens are consumed.

External APIs are called.

The workflow completes successfully.

From the customer's perspective, everything worked.

From the business perspective, something went wrong.

The infrastructure spent money before confirming that the request should have been allowed.

The financial impact of a single request might be negligible.

But AI businesses rarely process a single request.

They process thousands.

Sometimes millions.

Small authorization mistakes repeated at scale quietly become revenue leakage.

AI execution has become cheap to start but expensive to scale

Launching an AI product has never been easier.

Today, developers can integrate powerful language models, image generation APIs, voice services and agent frameworks in a matter of hours.

The barrier to experimentation has fallen dramatically.

The barrier to profitability has not.

Unlike traditional SaaS products, AI applications incur operational costs almost every time they create value.

Every interaction may consume:

LLM tokens
Image generation credits
Voice processing time
External API calls
Agent workflows
Vector database queries

The more successful the product becomes, the more infrastructure those requests consume.

Success doesn't only increase revenue.

It also increases operating costs.

That's what makes AI fundamentally different from many traditional software businesses.

Scaling usage doesn't simply increase customer value.

It also increases financial exposure.

The challenge is no longer making AI execute.

The challenge is making sure it only executes when it should.

Every AI request is a financial decision

Traditional software rarely forces you to think this way.

A customer clicks a button.

The application responds.

The cost of serving that request is usually negligible.

AI products work differently.

Almost every meaningful interaction consumes real resources.

A single request may trigger:

Millions of input and output tokens
Image generation
Speech-to-text processing
Text-to-speech synthesis
Multiple tool calls
External APIs
Agent reasoning
Background workflows

From an engineering perspective, that's simply execution.

From a business perspective, every one of those operations has a cost.

That's why every AI request is also a financial decision.

The moment compute begins, the business starts spending money.

Not all requests create value

One of the biggest misconceptions in AI products is assuming that every incoming request deserves to be executed.

It doesn't.

Consider a few common scenarios.

A customer has already consumed all available credits.

A subscription expired yesterday.

A duplicate request is accidentally retried.

An AI agent receives the same task twice because of a network timeout.

A webhook is delivered multiple times.

An administrator revoked access minutes earlier.

If the infrastructure executes those requests anyway, the product still incurs compute costs.

The customer may never even notice.

The finance team eventually will.

Every unnecessary execution quietly reduces margins.

The cost of a single request is rarely the problem.

The problem is allowing thousands of unnecessary requests to execute over time.

Why payment doesn't solve this problem

A common assumption is:

"The customer paid, therefore the request should execute."

That works well for traditional subscription software.

AI products introduce another layer of complexity.

A payment confirms a financial transaction.

It does not automatically answer questions like:

Does this customer still have credits?
Have they reached their usage limit?
Is this feature included in their plan?
Has access expired?
Is this request within their spending policy?
Should this workflow continue?

Payment is an event.

Authorization is a decision.

Those are two very different responsibilities.

As AI products evolve, separating them becomes increasingly important.

Every execution should begin with authorization

A healthy AI product doesn't start with model execution.

It starts with a question.

Should this request execute?

Only after that question has been answered should infrastructure begin consuming compute.

A simplified decision flow might look like this:

Incoming Request
        ↓
Authorize Request
        ↓
Validate Credits
        ↓
Validate Entitlements
        ↓
Validate Usage Limits
        ↓
Execute AI
        ↓
Track Usage
        ↓
Update Remaining Balance

Notice where AI execution appears.

Near the end.

Not at the beginning.

The healthiest AI businesses don't optimize models first.

They optimize decisions first.

Because every prevented execution protects infrastructure costs before they're ever incurred.

Healthy AI businesses authorize before spending

One pattern is becoming increasingly common across mature AI products.

Instead of asking:

"Can we execute this request?"

They first ask:

"Should we execute this request?"

That small change completely shifts how AI systems are designed.

Authorization is no longer just a security concern.

It's an economic decision.

Before expensive compute begins, healthy AI businesses increasingly validate things like:

Available credits
Spending limits
Active entitlements
Feature permissions
Usage policies
Customer status

Only after those checks pass does the application consume AI resources.

The objective isn't to deny legitimate requests.

It's to ensure that every execution creates value for both the customer and the business.

Every request that is blocked before compute starts is infrastructure cost that never had to be incurred.

The hidden cost of "just execute it"

Early in a product's life, executing every request often feels like the safest option.

The infrastructure is simple.

The customer receives a response.

Everything appears to work.

As usage grows, however, that assumption quietly becomes expensive.

Consider what happens when systems automatically execute requests without validating whether they should.

Situation	Technical Outcome	Business Outcome
Duplicate request	AI executes twice	Double infrastructure cost
Network retry	Request processed again	Silent revenue leakage
Race condition	Multiple executions	Incorrect credit balance
Stale entitlements	Access still allowed	Unpaid AI consumption
Failed workflow retry	Same task runs twice	Margin erosion

None of these failures usually break the application.

The customer often receives the expected result.

That's precisely why they're difficult to notice.

They don't create obvious outages.

They quietly create unnecessary costs.

Engineering problems become financial problems

Many of these situations are traditionally viewed as engineering concerns.

Retries.

Idempotency.

Concurrency.

Distributed systems.

Webhook delivery.

Queue processing.

On their own, they're technical challenges.

In AI products, they also become financial ones.

Every duplicate execution means compute was paid for twice.

Every stale entitlement means resources were consumed without authorization.

Every missing usage event reduces visibility into customer profitability.

As AI infrastructure becomes a larger part of operating costs, engineering reliability and financial health become increasingly connected.

Good architecture doesn't just improve reliability.

It protects margins.

Every unnecessary AI execution is a business expense disguised as an engineering event.

That may become one of the defining architectural principles of modern AI products.

Because once compute begins, the cost has already been incurred.

The cheapest AI request isn't the fastest one.

It's the one your infrastructure correctly decided not to execute.

A better mental model

Traditional SaaS products were largely built around a simple question:

Did the customer pay?

For many years, that was enough.

A successful payment activated a subscription.

The customer gained access.

The software continued working until the subscription expired.

AI products introduce a different reality.

Every interaction has the potential to consume real infrastructure.

That changes the question entirely.

Healthy AI businesses increasingly ask:

Should this AI request execute?

The distinction may seem subtle.

It isn't.

The first question is about a transaction.

The second is about protecting the economics of the business.

Every incoming request becomes a decision.

Should this customer consume more credits?

Should this workflow continue?

Should this feature still be available?

Should this expensive model be called?

Those questions are no longer edge cases.

They're becoming part of the runtime architecture of modern AI products.

A useful mental model looks like this:

Customer Request
        ↓
Authorization
        ↓
Business Validation
        ↓
AI Execution
        ↓
Usage Tracking
        ↓
Customer Access Updated

Notice what changed.

AI execution is no longer the first step.

It's the consequence of a successful business decision.

Final thoughts

For years, engineering teams optimized software for execution.

Could the request be processed?

Could the infrastructure scale?

Could the API respond faster?

Those questions still matter.

But AI products introduce a new engineering challenge.

Not every request that can execute should execute.

As compute becomes one of the largest operational costs for AI companies, profitability increasingly depends on making better decisions before infrastructure starts spending money.

That means thinking beyond payments.

Beyond subscriptions.

Beyond pricing.

It means designing systems that understand who is making the request, what they're entitled to use, how much they've already consumed, and whether executing another AI request actually makes business sense.

The companies that build economically healthy AI products won't simply have the fastest models or the most sophisticated prompts.

They'll have the discipline to spend compute only when it creates value.

That may become one of the defining engineering principles of the next generation of AI products.

Learn More

A new category of infrastructure is beginning to emerge between payment and AI execution.

Its role isn't to process transactions or run models.

Its role is to decide whether expensive AI resources should be consumed in the first place.

That infrastructure increasingly includes capabilities such as:

Real-time authorization
Creditsand prepaid balances
Usage validation
Access control
Entitlements
Runtime decision making

Some engineering teams build these systems internally.

Others adopt specialized infrastructure designed specifically for AI monetization.

Platforms such as Licenzy are part of this emerging AI Monetization Runtime category, helping AI companies protect margins, prevent revenue leakage, authorize requests before compute is consumed, and build economically healthy AI businesses without rebuilding this layer from scratch.

What percentage of AI requests in your product actually need to execute?

The answer might reveal more about your business than your pricing page ever could.

Building an AI Product Is Easy. Building a Profitable One Isn't.

Ciroandrea — Mon, 06 Jul 2026 12:15:12 +0000

Over the past two years, building AI products has become dramatically easier.

Founders can integrate state-of-the-art models in hours.

Launching an AI assistant, a content generator, or an AI agent no longer requires a large research team.

The technical barriers have fallen.

Ironically, the business barriers have become much higher.

Most founders spend months thinking about:

Which model to use
Prompt engineering
User experience
Pricing
Growth

Far fewer spend the same amount of time thinking about:

Margins
Customer profitability
Revenue leakage
Usage visibility
Cost attribution
Long-term sustainability

Yet these are often the factors that determine whether an AI company survives.

Building an AI product and building a profitable AI business are no longer the same challenge.

One is primarily an engineering problem.

The other is an economics problem.

And as AI products mature, economics increasingly become part of the product architecture itself.

Why this matters

Imagine two AI startups.

Both charge $49 per month.

Both have the same number of customers.

Both are growing at roughly the same pace.

On paper, they look almost identical.

But internally, they're very different.

The first company understands exactly:

how much each customer costs
which features generate the highest infrastructure costs
where revenue leakage occurs
which customers are profitable
how usage evolves over time

The second company only knows one thing.

Monthly Recurring Revenue.

From the outside, both businesses look healthy.

Only one actually is.

This is becoming one of the biggest differences between successful AI companies and those that struggle to scale.

The companies that survive aren't necessarily the ones with the best models.

They're often the ones that understand their economics the best.

Why pricing isn't the hardest problem anymore

For years, pricing was considered one of the hardest parts of building a SaaS business.

How much should you charge?

Monthly or annual?

Free trial or freemium?

Today, those questions are still important.

But they're no longer the hardest ones.

The market has evolved.

Subscriptions have become familiar.

Payment processing has become remarkably simple.

Modern payment platforms have significantly reduced the complexity of accepting online payments, allowing founders to focus on what happens after the transaction.

Receiving money is no longer the bottleneck.

The difficult part begins after the payment succeeds.

That's when your product has to answer questions like:

How much usage should this customer receive?
Which features should be available?
How should usage be tracked?
How do you prevent duplicate consumption?
How do you protect margins as usage grows?
Which customers are actually profitable?

Pricing determines how customers pay.

The infrastructure behind your product determines whether that pricing model remains economically sustainable.

That's an entirely different challenge.

AI costs are fundamentally different

One reason AI businesses behave differently from traditional SaaS is that their costs don't grow in the same way.

In a typical SaaS product, serving one additional customer often adds only a small incremental cost.

The software is already built.

Infrastructure costs are relatively predictable.

AI changes that equation.

Every interaction may generate a real infrastructure cost.

This is one reason why pricing AI products differs from traditional SaaS, where infrastructure costs are typically more predictable.

A customer might:

Generate thousands of images
Process millions of tokens
Run long AI agent workflows
Make continuous API requests
Hold extended voice conversations

Another customer on exactly the same subscription might use only a fraction of those resources.

Both pay the same monthly fee.

They don't generate the same economics.

This creates a challenge that traditional SaaS businesses rarely had to solve.

Revenue becomes predictable.

Costs do not.

Variable costs create unpredictable businesses

Imagine two customers on a $49/month plan.

Customer	Monthly Revenue	AI Usage	Infrastructure Cost
Customer A	$49	Light	Low
Customer B	$49	Heavy	High

From a billing perspective, they're identical.

From a profitability perspective, they're completely different businesses.

The goal isn't to discourage heavy users.

They're often your most engaged customers.

The challenge is understanding whether your pricing model still makes sense as usage grows.

Without visibility, founders often optimize the wrong metric.

They celebrate new subscriptions while margins quietly shrink in the background.

Profitability is becoming an infrastructure problem

Many founders assume profitability is primarily determined by pricing.

Charge more.

Reduce costs.

Increase conversions.

Those levers still matter.

But AI products introduce another variable.

Operational accuracy.

Profitability increasingly depends on whether your product can reliably answer questions like:

Was this request tracked?
Was usage deducted only once?
Can this customer still access this feature?
Which customer generated these infrastructure costs?
Which workflow consumed the most resources?

These questions don't belong to finance.

They belong to your application.

As AI products become more sophisticated, profitability becomes tightly connected to how reliably the product measures, authorizes and records usage.

Visibility changes decision making

Imagine you're looking at your dashboard.

One customer generated $99 this month.

At first glance, that sounds like a great customer.

Now imagine you can also see:

AI infrastructure cost: $82
Credits consumed: 98%
Long-running agent executions: 147
Duplicate requests prevented: 36

The conversation immediately changes.

You're no longer asking:

"How much revenue did this customer generate?"

You're asking:

"Is this customer profitable?"

That's a much more valuable question.

Because profitable growth doesn't come from maximizing subscriptions.

It comes from understanding the relationship between revenue, usage and cost.

The more visibility founders have into that relationship, the better decisions they can make about pricing, product design and long-term growth.

Healthy AI businesses share common characteristics

As more AI products mature, certain patterns begin to emerge.

Not because companies copy each other.

Because they start solving the same economic problems.

Different products may choose different pricing strategies.

Different founders may target different markets.

Yet many successful AI companies gradually adopt similar building blocks.

Instead of relying on a single subscription, they begin combining:

Subscriptions for predictable recurring revenue
Credits to allocate usage fairly
Top-ups for customers with higher consumption
Usage tracking to understand where costs come from
Access control to manage feature availability
Real-time authorization to evaluate every request

None of these components exists in isolation.

Together, they create a system that balances customer experience with business sustainability.

Balancing revenue and cost

One of the biggest challenges in AI products is that revenue and infrastructure costs rarely move together.

Revenue is often fixed.

Usage is not.

A healthy monetization model tries to keep those two dimensions aligned.

Business Goal	Supporting Infrastructure
Predictable revenue	Subscriptions
Fair consumption	Credits
Flexible growth	Top-ups
Cost visibility	Usage tracking
Reliable permissions	Access control
Healthy margins	Real-time authorization

Notice something interesting.

None of these components replaces pricing.

They support it.

Pricing defines the commercial model.

Infrastructure ensures that model remains economically sustainable as the business grows.

Customer trust is part of profitability

Profitability isn't only about reducing costs.

It's also about building trust.

Imagine a customer who sees:

Credits disappearing unexpectedly
Features becoming unavailable without explanation
Different balances across devices
Inconsistent usage history

Even if the billing is technically correct, the experience feels unreliable.

The opposite is also true.

When customers can clearly understand:

how credits are assigned
how they're consumed
what they can access
why a request was allowed or denied

they're far more likely to trust the product.

In AI businesses, operational transparency is increasingly becoming a competitive advantage.

Common founder mistakes

Most monetization problems don't start with pricing.

They start with assumptions that work well during the MVP stage but become increasingly fragile as products grow.

One of the most common is believing that pricing alone determines profitability.

In reality, pricing is only one variable.

The way usage is measured and controlled often has an even greater impact.

Another common mistake is assuming that a successful payment automatically means the customer should have access.

Payments and authorization solve different problems.

Treating them as the same responsibility usually creates unnecessary complexity over time.

Many teams also postpone usage tracking until after launch.

At first, that feels reasonable.

Growth matters more than analytics.

But once customers begin using the product heavily, recovering accurate usage history becomes extremely difficult.

Finally, many founders measure business performance almost entirely through revenue.

Revenue is important.

But revenue alone doesn't answer questions like:

Which customers are profitable?
Which features are expensive to operate?
Which workflows generate the highest AI costs?
Where is revenue leakage occurring?

Without that visibility, optimization becomes guesswork.

Growing an AI business isn't only about acquiring more customers.

It's about understanding the economics behind every customer you already have.

A better mental model

For years, many SaaS companies optimized for one thing above all else:

More subscriptions.

In the AI era, that mental model is becoming incomplete.

Subscriptions still matter.

Growth still matters.

But sustainable AI businesses increasingly optimize for something broader.

A useful way to think about it is like this:

Revenue
      ↓
Margins
      ↓
Predictability
      ↓
Customer Trust
      ↓
Healthy Growth

Notice what's missing.

The goal isn't simply maximizing revenue.

It's building a business where revenue, costs, customer experience and profitability remain aligned over time.

That requires much more than choosing the right pricing page.

It requires understanding how customers consume your product, how infrastructure costs evolve, and how every request affects the economics of the business.

The strongest AI companies aren't just building better models.

They're building businesses that remain economically healthy as usage grows.

That's a very different challenge.

Final thoughts

Building an AI product has never been more accessible.

Models are improving faster than ever.

Development frameworks continue to evolve.

Launching an AI application is becoming easier every year.

Building a profitable AI company is not.

As products scale, founders eventually discover that the biggest challenges aren't only technical.

They're operational.

They're economic.

They're architectural.

Success increasingly depends on questions like:

Can we understand where our costs come from?
Can we trust our usage data?
Are our customers actually profitable?
Can we scale without compressing our margins?
Are we delivering exactly the access customers purchased?

Those aren't billing questions.

They're business questions.

And they're becoming some of the most important questions an AI company can answer.

The companies that thrive over the next decade won't simply build impressive AI products.

They'll build systems that make those products economically sustainable.

Learn More

As AI companies grow, many eventually discover they need more than payment processing.

They need infrastructure that helps them understand and manage the economics of their products.

That often includes:

Credits
Usage tracking
Cost attribution
Entitlements
Access control
Real-time authorization

Some teams choose to build these capabilities internally.

Others adopt specialized infrastructure platforms designed to solve these operational challenges.

Platforms such as Licenzy focus on helping AI companies protect margins, prevent revenue leakage, manage usage, and turn successful payments into reliable product access—allowing engineering teams to spend more time building products and less time rebuilding monetization infrastructure.

If you could measure only one metric beyond revenue in your AI product, what would it be?

Customer profitability, usage visibility, margin, or something else?

Why Payment Is Only the Beginning of AI Monetization

Ciroandrea — Mon, 29 Jun 2026 10:09:45 +0000

A customer clicks Buy.

The payment succeeds.

Stripe confirms the transaction.

Success.

For many founders, this feels like the end of the monetization flow.

The customer has paid.

The problem is solved.

In reality, that's only the first event.

Now your product has to answer a series of questions that have nothing to do with processing a payment.

Can this customer access GPT-4?

How many AI credits should they receive?

Which features are included in their plan?

How should future usage be tracked?

What happens when their credits run out?

What if they purchase additional credits?

When should access expire?

These questions are no longer about payments.

They're about running a product.

And this is where many AI companies discover that accepting payments is actually the easiest part of monetization.

Why this matters

Accepting online payments has never been easier.

Today, founders can integrate providers like Stripe, Paddle or Lemon Squeezy in just a few hours and start selling subscriptions almost immediately.

That's a huge improvement compared to a decade ago.

Payment processing has become a solved problem for most SaaS companies.

Today, platforms like Stripe, Paddle, and Lemon Squeezy have significantly simplified online payment processing, allowing founders to launch products much faster than in the past.

But AI products introduce a new challenge.

Unlike traditional software, AI applications often have variable costs, dynamic usage, multiple pricing models and different levels of access depending on how customers use the product.

Receiving money is only the beginning.

The real challenge starts after the payment succeeds.

Payment processing is only one piece of the puzzle

Imagine a customer purchases your Pro AI Plan.

From a payment perspective, everything is finished.

The transaction succeeds.

The invoice is generated.

The subscription becomes active.

But your application still has work to do.

For example, it needs to determine:

Which AI models the customer can use
How many credits should be assigned
Which premium features become available
Whether API access should be enabled
What usage limits apply
How future requests should be authorized

None of these decisions are made by the payment itself.

They're part of your application's monetization layer.

This is why payment processing and monetization should be viewed as two different responsibilities.

A payment tells you that money was received.

Your monetization layer decides what the customer can actually do.

Payment is not authorization

One of the biggest misconceptions in AI products is treating payment and access as the same thing.

At first glance, they seem closely related.

A customer pays.

The customer gains access.

Simple.

But these are actually two completely different events.

A payment is a financial transaction.

Authorization is an application decision.

Imagine a customer purchases access to your AI product.

The payment provider knows that money has been received.

It does not know:

Which AI models should be available
How many credits the customer should receive
Whether API access should be enabled
Which usage limits apply
Which premium features are included
Whether access should expire tomorrow or next month

Those decisions belong to your application.

Modern SaaS products typically implement a dedicated authorization layer that separates financial events from application permissions.

That's why it's useful to think about them separately.

Payment Processing	Authorization
Money received	Can the customer use GPT-4?
Subscription renewed	Can they generate images?
Credits purchased	How many credits are available?
Invoice paid	Should API access be enabled?
Refund processed	Should access be revoked?

The payment tells your system what happened financially.

Authorization determines what the customer is allowed to do next.

Confusing these two responsibilities often leads to increasingly complex application logic.

What actually happens after a payment?

Let's follow a simple example.

A customer purchases your Pro AI Plan.

From the user's perspective, the process feels complete.

Behind the scenes, however, several systems still need to work together.

A modern AI product might execute a flow like this:

Payment Succeeded
        ↓
Create or Update Entitlements
        ↓
Assign AI Credits
        ↓
Enable Premium Features
        ↓
Authorize API Access
        ↓
Track Usage
        ↓
Consume Credits
        ↓
Apply Top-Ups
        ↓
Update Remaining Balance
        ↓
Authorize the Next Request

Notice something interesting.

The payment itself only appears once.

Everything that follows is part of the monetization infrastructure.

This is why many founders discover that accepting payments is actually the easy part.

The difficult part is making sure every customer receives exactly the access they purchased, every usage event is tracked correctly, and every future request is evaluated against the current state of their account.

As products grow, this workflow becomes increasingly dynamic.

Customers upgrade plans.

They purchase additional credits.

Subscriptions expire.

Promotional access is granted.

Usage limits change.

The monetization layer has to keep all of this synchronized in real time.

Why AI products make this much harder

Traditional SaaS products often have relatively simple rules.

A customer purchases a plan.

The plan unlocks a few features.

That's usually enough.

AI products introduce a different level of complexity.

Usage is rarely constant.

Infrastructure costs are variable.

Customers consume resources in very different ways.

A single customer might generate:

thousands of API requests
millions of LLM tokens
hundreds of images
dozens of videos
long-running AI agent workflows

Meanwhile, another customer on exactly the same subscription may barely use the product.

This creates a new challenge.

The system must continuously answer questions such as:

Does this customer still have credits?
Are they allowed to access this model?
Has their monthly limit been reached?
Did they purchase additional usage?
Has their subscription expired?
Should this request still be authorized?

None of these questions are answered by the payment processor.

They belong to the application's monetization layer.

Why AI products make monetization more difficult

Not every AI product faces the same monetization challenges.

Some products have relatively predictable usage patterns.

Others execute dozens of billable operations from a single user action.

The more dynamic the product becomes, the more important your monetization infrastructure becomes.

Here's a simplified view.

Product Type	Monetization Complexity
AI Image Generation	Medium
AI Video Generation	Medium
AI Chat Applications	High
AI APIs	Very High
AI Voice Applications	Very High
AI Agents	Extremely High

The reason isn't the payment model.

It's what happens after the payment.

Why AI Agents are especially challenging

Imagine a user asks an AI agent to:

"Analyze this PDF, summarize it, search the web for related information, and send me a report."

From the user's perspective, that's a single request.

From your infrastructure's perspective, it might trigger:

Multiple LLM calls
Web searches
Vector database queries
Background jobs
File processing
External APIs

One user action can easily generate dozens of internal operations.

Now imagine trying to answer questions like:

How many credits should this consume?
Should every step be tracked?
What happens if one tool fails?
What if the workflow retries halfway through?
Should partially completed work still be billed?

These aren't payment questions.

They're monetization questions.

AI Voice products introduce similar challenges

Voice applications follow a similar pattern.

A single conversation may include:

Speech-to-text
One or more LLM requests
External tool execution
Text-to-speech generation

Each step has its own infrastructure cost.

Each step may need to be tracked.

Each step may contribute to the customer's remaining balance.

As voice applications become more sophisticated, usage tracking becomes increasingly important.

API products scale faster than billing systems

API-first products face another challenge.

Usage grows much faster than billing complexity.

One customer may send:

500 requests per month.

Another may send:

5 million requests.

The payment might be exactly the same.

The infrastructure cost certainly isn't.

This is why many API products eventually introduce:

Usage limits
Credits
Metered billing
Rate limits
Real-time authorization

The payment defines the commercial agreement.

The monetization layer determines whether each individual request should be allowed.

Why image and video products are often easier to model

Image and video generation products can still become expensive.

But their billing logic is often more straightforward.

A generation request usually maps directly to a predictable unit of consumption.

For example:

Generate Image
        ↓
Consume 10 Credits
        ↓
Return Result

Or:

Generate Video
        ↓
Consume 100 Credits
        ↓
Return Result

The relationship between user action and infrastructure cost is much easier to understand.

That doesn't eliminate monetization challenges.

It simply reduces the number of moving parts compared to agents or API workflows.

Common implementation mistakes

As AI products evolve, many teams run into the same architectural problems.

Not because they're inexperienced.

Because these problems rarely exist during the MVP stage.

Treating payment as authorization

A successful payment doesn't automatically define what a customer can do.

It only confirms that a financial transaction occurred.

Your application still needs to determine:

Which features are available
Which AI models can be used
Whether API access should be enabled
Whether credits are available
Whether limits have been reached

Payment and authorization should remain separate concerns.

Checking the payment provider on every request

A common pattern looks something like this:

if (subscription.active) {
    allowRequest();
}

It works at first.

But over time, questions become more complicated.

What if the customer has purchased additional credits?

What if they have temporary promotional access?

What if they have consumed their monthly allowance?

What if an administrator manually granted access?

Very quickly, a simple subscription check becomes difficult to maintain.

No usage tracking

If you don't know exactly what customers are consuming, you can't reliably answer questions like:

How many credits remain?
Which requests generated costs?
Why was a balance reduced?
Where did infrastructure costs come from?

Usage tracking becomes the operational foundation of AI monetization.

No audit trail

Eventually every growing product receives support requests like:

"Why can't I access GPT-4 anymore?"

Or:

"Where did my credits go?"

Without an audit trail, those questions become difficult to answer.

With one, every permission change, credit assignment and usage event can be traced back to its source.

As products grow, auditability becomes just as important as billing itself.

The monetization layer

As AI products grow, an interesting pattern starts to emerge.

Teams often realize they're maintaining two completely different systems.

The first handles money.

The second handles everything that happens after money.

You can think about it like this:

Payments Infrastructure
────────────────────────
• Checkout
• Invoices
• Subscriptions
• Payment Processing

                ↓

Monetization Infrastructure
────────────────────────
• Credits
• Entitlements
• Usage Tracking
• Usage Ledger
• Access Control
• Real-Time Authorization

Both layers are equally important.

The first answers questions like:

Did the customer pay?
Was the subscription renewed?
Was the invoice successful?

The second answers questions like:

Can this customer use GPT-4?
Do they still have credits available?
Has their monthly limit been reached?
Should this API request be allowed?
Should access expire today?

These are completely different responsibilities.

And as products become more sophisticated, keeping them separate makes systems easier to evolve, easier to debug, and easier to scale.

Building a reliable monetization layer

There isn't a single architecture that works for every AI product.

An AI image generator has different requirements than an AI agent platform.

An API business has different constraints than a voice application.

But across many successful products, the same building blocks appear repeatedly.

Component	Responsibility
Payments	Collect money
Credits	Allocate usage
Entitlements	Define permissions
Usage Tracking	Record consumption
Usage Ledger	Maintain an auditable history
Access Control	Decide what users can do
Real-Time Authorization	Evaluate every request

Each component solves one specific problem.

Together, they create a monetization system that remains reliable as the product grows.

The goal isn't to make billing more complicated.

It's to ensure that every payment results in the correct customer experience, every usage event is accounted for, and every request is evaluated against the customer's current state.

That's what allows AI companies to scale confidently without gradually accumulating billing inconsistencies or revenue leakage.

Final thoughts

For years, online payments were one of the hardest problems software companies had to solve.

Today, that's no longer true.

Modern payment providers have made accepting payments remarkably simple.

The difficult part now begins after the transaction succeeds.

AI products need to decide:

what customers can access
how much they can consume
how usage is tracked
when access changes
when credits should be deducted
when additional usage should be allowed

Those decisions happen long after the payment has been processed.

That's why modern AI monetization isn't just about charging customers.

It's about building the infrastructure that connects payments, permissions, usage, and authorization into a single reliable system.

Payment processing is no longer the hard part.

Building everything that happens after payment is.

Learn More

As AI products become more sophisticated, many teams eventually need infrastructure for:

Credits
Usage Tracking
Entitlements
Access Control
Real-Time Authorization

Some teams build these systems internally.

Others adopt dedicated infrastructure platforms that provide these capabilities out of the box.

Platforms such as Licenzy focus on these operational layers, helping product teams manage credits, usage tracking, entitlements, and authorization while allowing developers to spend more time building customer-facing features instead of rebuilding monetization infrastructure.

Why Most AI Startups Don't Use Subscriptions Alone

Ciroandrea — Mon, 22 Jun 2026 08:05:55 +0000

When founders launch an AI product, the first pricing model is usually obvious.

A monthly subscription.

$19/month.

$49/month.

$99/month.

Simple.

Predictable.

Easy for customers to understand.

And for many products, it works.

At least initially.

But after looking at dozens of AI startups, a pattern starts to emerge.

Many companies begin with subscriptions.

Very few rely on subscriptions alone forever.

Instead, a different model increasingly appears:

Subscription
      +
Credits
      +
Top-Ups

This isn't a universal rule.

But it's a pattern that shows up repeatedly across AI products.

The reason is simple.

AI costs behave differently than traditional software costs.

Why subscriptions are attractive at the beginning

Subscriptions solve several important problems.

They create predictable recurring revenue.

Customers understand them immediately.

Billing is straightforward.

Forecasting becomes easier.

A founder launching an AI product can usually implement a subscription model quickly and start validating demand.

For early-stage startups, simplicity is often more important than perfect monetization.

That's why many products start here.

The challenge appears when usage grows

The problem is that AI products often have highly uneven usage patterns.

Consider two customers paying the same monthly fee.

Customer	Monthly Fee	Usage
Customer A	$49	Occasional
Customer B	$49	Heavy Daily Usage

Revenue is identical.

Cost is not.

The second customer may consume dramatically more infrastructure resources.

As usage grows, margins become harder to predict.

This is especially true when products rely on external AI providers.

Every request has a cost.

Every token has a cost.

Every generation has a cost.

Subscriptions alone don't always reflect that reality.

Why AI costs are often variable

Traditional SaaS products often have relatively stable operating costs.

AI products don't.

A single customer might:

Generate thousands of images
Run an AI agent continuously
Process large volumes of voice data
Send millions of API requests

Another customer on the same plan might barely use the product.

This creates a mismatch between revenue and consumption.

The larger the gap becomes, the harder pricing becomes.

Why credits solve part of the problem

This is where credits often enter the picture.

Credits allow companies to connect usage with value.

Instead of offering unlimited consumption, a product can allocate a specific amount of usage.

For example:

Plan	Included Credits
Starter	1,000
Pro	10,000
Growth	50,000

Customers still enjoy the simplicity of a subscription.

At the same time, usage becomes measurable.

This creates a healthier relationship between revenue and infrastructure costs.

Why top-ups eventually become necessary

Credits solve part of the monetization challenge.

But another problem quickly appears.

Some customers use more than expected.

Imagine a customer on a Pro plan receiving 10,000 credits per month.

What happens when they consume all 10,000 credits after two weeks?

Several options exist:

Block usage
Force an upgrade
Sell additional credits

Many AI startups choose the third option.

This is where top-ups appear.

Customers purchase additional credits without changing plans.

The result is a model that combines:

Predictable subscription revenue
Usage-based flexibility
Additional monetization opportunities

Why AI Agents are difficult to monetize

AI Agents introduce another layer of complexity.

A single user action may trigger:

Multiple model calls
External APIs
Background jobs
Tool execution

One action can generate dozens of billable events.

The relationship between user actions and costs becomes less obvious.

As a result, unlimited subscriptions often become difficult to sustain.

Credits help create boundaries around consumption.

Why AI Voice products face similar challenges

Voice applications often combine multiple expensive services.

A conversation may include:

Speech-to-text
LLM processing
Tool execution
Text-to-speech

Each component contributes to cost.

Heavy users can quickly consume significantly more resources than average customers.

This makes usage-aware pricing increasingly attractive.

Why AI APIs often adopt usage-based models

API businesses are naturally usage-driven.

Customers may generate:

Thousands of requests
Millions of requests
Billions of tokens

The gap between customers can be enormous.

This is one reason why many API businesses eventually introduce:

Usage limits
Credits
Metered billing
Consumption-based pricing

Subscriptions alone often struggle to capture that variability.

Why AI Image and AI Video products often have simpler economics

Image and video products can still be expensive.

However, their billing models are often easier to understand.

A generation usually maps directly to a cost.

For example:

1 Image
     ↓
10 Credits

Or:

1 Video
     ↓
100 Credits

The relationship between action and consumption is more transparent.

This makes monetization easier to communicate to customers.

The challenge still exists.

It's simply easier to model.

The pattern emerging across AI startups

Looking across AI startups, a recurring pattern appears.

Many products start with subscriptions.

As usage grows, credits are introduced.

As power users emerge, top-ups follow.

The resulting model often looks like this:

Component	Purpose
Subscription	Predictable recurring revenue
Credits	Usage allocation
Top-Ups	Additional consumption

This approach allows companies to balance:

Customer simplicity
Revenue predictability
Variable infrastructure costs

It's not the only model.

But it's one that appears increasingly often across AI products.

Why infrastructure eventually becomes necessary

As monetization becomes more sophisticated, new requirements emerge.

Teams eventually need systems for:

Credits
Usage tracking
Usage limits
Entitlements
Access control

The pricing model becomes only one part of the equation.

The infrastructure required to enforce that pricing becomes equally important.

Final thoughts

Many AI startups begin with subscriptions because subscriptions are simple.

Customers understand them.

Founders can launch quickly.

But AI products introduce a challenge that traditional SaaS products often don't face:

Usage can vary dramatically between customers.

As a result, subscriptions alone frequently become insufficient.

That's why an increasing number of AI companies are adopting a hybrid model:

Subscription
      +
Credits
      +
Top-Ups

Not because subscriptions are broken.

But because balancing predictable revenue and variable costs becomes increasingly important as products grow.

Learn More

As products evolve beyond simple subscriptions, many teams eventually need infrastructure for:

Credits
Usage tracking
Entitlements
Access control
Usage-based billing

Platforms such as Licenzy focus on these operational layers so teams can concentrate on building products rather than rebuilding monetization infrastructure from scratch.

How is your AI product handling the gap between predictable revenue and unpredictable usage? Have you stayed subscription-only, or introduced credits and top-ups?

How AI Products Lose Revenue Without Realizing It

Ciroandrea — Mon, 15 Jun 2026 08:55:09 +0000

Your pricing model can be perfect.

Your subscription plans can be perfectly designed.

Your checkout flow can convert beautifully.

And you can still lose money.

Not because customers aren't paying.

Because your product is tracking usage incorrectly.

This problem is called revenue leakage.

And it's surprisingly common in AI products.

Most founders spend months thinking about pricing.

Far fewer spend the same amount of time thinking about what happens after a customer starts using the product.

Yet that's often where margins quietly disappear.

Why this matters

Imagine a simple AI product.

Metric	Expected
Monthly Revenue	$20,000
AI Costs	$12,000
Expected Profit	$8,000

Everything looks healthy.

Now imagine:

3% of usage is never recorded
2% of requests are processed twice
1% of expired customers continue using premium features

The product still generates revenue.

Customers are still paying.

But profit starts shrinking.

Metric	Actual
Monthly Revenue	$20,000
AI Costs	$12,500
Revenue Leakage	-$500
Real Profit	$7,000

Nothing looks broken.

Yet the business is earning less than it should.

That's what makes revenue leakage dangerous.

It usually doesn't arrive as a catastrophic failure.

It arrives as hundreds of tiny mistakes that slowly compress margins.

What is revenue leakage?

Revenue leakage happens when a product delivers value without correctly tracking, billing, limiting, or authorizing that usage.

In simple terms:

The customer receives something, but the business fails to capture the corresponding revenue.

Common examples include:

Issue	Revenue Impact
Duplicate requests	Usage recorded incorrectly
Retry processing	Credits deducted multiple times
Missing usage events	Unbilled consumption
Billing mismatches	Usage exceeds billing records
Access not revoked	Continued free usage
Webhook duplication	Inconsistent balances

Most companies don't notice these issues immediately.

They become visible only after usage grows.

Why AI products are especially vulnerable

Traditional SaaS products often have relatively predictable economics.

AI products don't.

Every request has a cost.

Every token has a cost.

Every image generation has a cost.

Every video generation has a cost.

Every agent execution has a cost.

This means usage tracking is no longer an analytics problem.

It's a revenue problem.

If usage tracking becomes inaccurate, your business economics become inaccurate.

That's why revenue leakage tends to be far more common in AI products than in traditional SaaS applications.

Which AI products are most exposed?

Not all AI products face the same level of risk.

Some business models are naturally more vulnerable than others.

Product Type	Revenue Leakage Risk
AI Image Generation	Medium
AI Video Generation	Medium
AI Chatbots	High
AI APIs	Very High
AI Agents	Extremely High
AI Voice Agents	Extremely High

Let's look at why.

Why AI Agents are especially vulnerable

An AI agent rarely performs a single operation.

A single user request can trigger:

Multiple LLM calls
External API requests
Database operations
Tool executions
Background jobs

One action from the user may generate dozens of billable events.

If even a small percentage of those events are not tracked correctly, margins begin to drift.

The complexity grows exponentially as workflows become more sophisticated.

Why AI Voice products are difficult to monetize correctly

Voice applications often combine multiple systems.

A single conversation may include:

Speech-to-text
LLM processing
Tool execution
Text-to-speech

Each stage has its own cost.

Each stage may generate separate usage events.

Missing just one event can create a mismatch between delivered value and captured revenue.

Why AI APIs are particularly sensitive

API businesses are often usage-driven by nature.

Customers can generate thousands or millions of requests.

At that scale, small inaccuracies become expensive.

A tracking error affecting 0.1% of requests may seem insignificant.

At millions of requests per month, it becomes a real financial problem.

For API-first products:

Usage tracking is revenue infrastructure.

Why AI Image and AI Video products are usually safer

Image and video products are not immune to revenue leakage.

However, their workflows are often easier to model.

A generation request typically follows a simple flow:

Request
    ↓
Generation
    ↓
Credit Deduction

The relationship between user action and billing is more direct.

That doesn't eliminate the risk.

It simply makes inconsistencies easier to detect.

How revenue leakage silently destroys margins

The dangerous part about revenue leakage is that it rarely creates obvious failures.

The product continues working.

Customers remain happy.

Revenue continues arriving.

Yet profitability slowly declines.

Many teams spend months optimizing pricing while unknowingly losing more money through poor tracking than they would ever recover through pricing experiments.

This is why monetization is not only about pricing.

It's also about operational accuracy.

Common implementation mistakes

Most revenue leakage originates from a small number of architectural decisions.

Treating credits as a balance only

Many systems start with:

user_id
credit_balance

This works initially.

But eventually someone asks:

Why do I have fewer credits than expected?

At that point, the balance alone is not enough.

You need history.

No usage ledger

Without a usage ledger, there is no reliable audit trail.

Questions become difficult to answer:

Which action consumed credits?
When?
Why?
Was it processed twice?

Modern systems typically record every movement.

No idempotency

Retries happen.

Clients reconnect.

Network failures occur.

Without idempotency:

1 request
2 executions
2 deductions

Small errors accumulate quickly.

Using Stripe as access control

Many products repeatedly ask:

Is this subscription active?

Instead of asking:

Does this user have access?

Payments and access are different concerns.

Mixing them often creates fragile systems.

No entitlement model

Many products manage:

Users
Plans
Payments

But never explicitly model permissions. Entitlements are often the missing layer between payments and access.

Eventually feature access becomes difficult to maintain.

How modern AI products prevent revenue leakage

Successful AI products usually separate responsibilities.

A common architecture looks like this:

Payments
    ↓
Entitlements
    ↓
Access Control
    ↓
Product Usage
    ↓
Usage Tracking
    ↓
Usage Ledger

Each layer solves a specific problem.

This separation dramatically reduces revenue leakage.

The role of idempotency

Idempotency ensures that the same event cannot be processed twice.

For example:

{
  "usage_id": "req_12345"
}

If the request is received again, the system recognizes it and ignores duplicates.

This single concept prevents many revenue leakage scenarios.

Why audit trails matter

Eventually every product receives support tickets like:

Why was I charged for this?

Or:

Where did my credits go?

Without an audit trail, answers become guesses.

With a proper usage ledger, every movement can be explained.

Auditability becomes increasingly important as products scale.

Why entitlements and access control matter

Revenue leakage isn't only about usage tracking.

It's also about ensuring customers only receive what they purchased.

A customer should only access:

Features they purchased
Models they purchased
Limits they purchased
Credits they purchased

Entitlements define permissions.

Access control enforces them.

Together they reduce unauthorized usage and billing inconsistencies.

Final thoughts

Most AI companies spend enormous effort optimizing pricing.

Far fewer spend the same effort protecting revenue.

Yet pricing is only one side of the equation.

The other side is ensuring every unit of value delivered is:

Tracked
Accounted for
Authorized
Auditable

Revenue leakage often starts with small mistakes.

Duplicate requests.

Retries.

Missing usage events.

Access control gaps.

Over time those small issues compound.

And that's why many AI products lose revenue without realizing it.

Learn More

As AI products scale, many teams eventually build internal systems for:

Others choose specialized platforms that provide these capabilities out of the box.

The important part is not the implementation itself.

It's ensuring that usage, access, and revenue remain aligned as the product grows.

If you're interested in the technical side of these systems, documentation covering usage tracking, entitlements, access control, and usage-based billing can be a useful next step.

What Are Entitlements and Why Every SaaS Product Needs Them

Ciroandrea — Mon, 08 Jun 2026 12:57:35 +0000

Most SaaS founders think payments and access are the same thing.

They're not.

A customer pays.

A payment succeeds.

And somehow the user gains access to features.

At first, this feels simple.

As products grow, it becomes one of the most important architectural decisions you'll make.

This is where entitlements come in.

And surprisingly, most SaaS products already use entitlements without realizing it.

Why this matters

Imagine a customer subscribes to your Pro plan.

What happens next?

Most founders would answer:

The customer now has access to Pro features.

But that's not actually what happened.

The payment itself didn't grant access.

The payment created a set of permissions.

Those permissions determine:

What features are available
Which APIs can be used
How much usage is allowed
Which limits apply
What the customer can actually do

Those permissions are called entitlements.

What are entitlements?

An entitlement is a permission granted to a customer.

It represents access to something inside your product.

Examples include:

Access to a premium feature
Access to an API
Access to a higher usage limit
Access to AI models
Access to team collaboration features

A simple example:

Plan	Entitlements
Free	Basic Chat
Pro	Chat + Image Generation
Growth	Chat + Images + Video Generation

The payment purchases the plan.

The entitlements define what the user receives.

Payments are not access

One of the most important concepts in SaaS architecture is:

Payment is not access.

Many early-stage products directly connect Stripe subscriptions to feature checks.

For example:

if (customer.subscription === "pro") {
  allowAccess();
}

This works initially.

But eventually creates problems.

What happens if:

The payment webhook is delayed?
A refund occurs?
A dispute happens?
You grant access manually?
A customer receives promotional credits?

Now your payment system is directly controlling your application logic.

That coupling becomes difficult to maintain.

How SaaS entitlements actually work

A healthier architecture separates three concepts:

Payments
Entitlements
Access Checks

The flow usually looks like:

Payment
    ↓
Entitlements
    ↓
Access Control

A successful payment creates or updates entitlements.

The application checks entitlements.

The payment provider becomes one source of information rather than the source of truth.

Subscriptions vs entitlements

Subscriptions and entitlements are often confused.

They solve different problems.

Concept	Purpose
Subscription	Determines what was purchased
Entitlement	Determines what is accessible

A subscription is a billing object.

An entitlement is an access object.

For example:

Subscription:

Pro Plan

Entitlements:

API Access
Image Generation
10 Team Members
Priority Support

One subscription can create many entitlements.

Credits vs entitlements

Another common misunderstanding involves AI credits.

Credits are not entitlements.

They solve different problems.

Concept	Purpose
Credits	Measure consumption
Entitlements	Grant permissions

Example:

A user may have:

Access to GPT-4
Access to Image Generation

Those are entitlements.

The same user may also have:

5,000 credits remaining

That's consumption.

A user can have credits but no entitlement to use a feature.

A user can have entitlements but no remaining credits.

Both concepts are important.

Feature access and usage limits

Most SaaS products eventually need more than simple on/off permissions.

Examples:

Maximum API requests
Maximum users
Maximum projects
Maximum storage
Monthly AI credits

These are also entitlements.

For example:

Plan	Monthly Credits
Starter	1,000
Pro	10,000
Growth	50,000

The entitlement defines the limit.

Usage tracking measures consumption against that limit.

Common mistakes

As products grow, entitlement systems often become difficult to maintain.

Here are some common mistakes.

Checking Stripe directly on every request

Many products repeatedly ask:

Is the customer's Stripe subscription active?

This creates unnecessary coupling.

Your application should check entitlements.

Not payment processors.

Hardcoded feature flags

Another common pattern:

if (plan === "pro") {
  enableFeatureX();
}

Eventually the business asks for:

Custom plans
Promotions
Temporary upgrades
Enterprise exceptions

Hardcoded logic quickly becomes difficult to manage.

No entitlement model

Many products track:

Users
Payments
Plans

But never model entitlements explicitly.

This works until access rules become more complex.

Then every new feature requires more custom logic.

Access control becomes easier

A dedicated entitlement layer simplifies access control.

Instead of asking:

What subscription does this user have?

You ask:

Does this user have this entitlement?

For example:

canUse("image_generation")

This creates a cleaner separation between billing and product logic.

Real-world examples

Most successful SaaS products already use entitlement concepts.

Examples include:

SaaS subscriptions

Subscription creates:

Feature access
Seat limits
Storage limits

AI products

Subscription creates:

Model access
Credit limits
Generation permissions

API products

Subscription creates:

Rate limits
Request quotas
Premium endpoint access

Usage-based billing

Payments create:

Consumption allowances
Usage permissions
Feature access

The implementation varies.

The concept remains the same.

Final thoughts

Entitlements are one of the most important concepts in modern SaaS architecture.

Yet many products don't model them explicitly.

A successful payment does not grant access.

A successful payment creates entitlements.

Those entitlements determine:

Feature access
Usage limits
Access control
Consumption permissions

As products grow, separating billing from access becomes increasingly valuable.

Payments answer "What was purchased?"

Entitlements answer "What can the customer do?"

Learn More

As products become more complex, managing entitlements manually can become difficult.

Platforms such as Licenzy help teams manage:

Entitlements
AI credits
Usage tracking
Access control
Usage-based billing

Instead of linking a homepage, consider linking documentation focused on:

Entitlements
Access Checks
Usage Consumption APIs
Usage-Based Billing

How to Build Prepaid Credits for SaaS Products (Complete Guide)

Ciroandrea — Tue, 02 Jun 2026 09:18:39 +0000

Most SaaS founders start with subscriptions.

It makes sense.

A single monthly fee is easy to explain, easy to sell, and easy to implement.

For many products, that's exactly the right decision.

But as products grow, especially AI products, subscriptions often start showing their limits.

Some customers barely use the product.

Others generate thousands of requests every day.

Yet everyone pays the same amount.

This is why more SaaS companies are moving toward prepaid credits.

Why this matters

Traditional SaaS products usually have predictable operating costs.

Modern AI products don't.

Every request has a cost.

Examples include:

LLM requests
Image generation
Video rendering
Audio transcription
API calls
Compute workloads

The more customers use the product, the higher your costs become.

Now consider two customers.

Customer	Monthly Fee	Infrastructure Cost
Customer A	$29	$5
Customer B	$29	$150

Revenue is identical.

Costs are not.

This is the moment many founders realize subscriptions alone may not be enough.

Prepaid credits help align usage with cost.

The more customers consume, the more credits they use.

What are prepaid credits?

A prepaid credit system allows customers to purchase usage before consuming a service.

Instead of paying for every action individually, users buy a balance that can be spent over time.

A simple example:

Package	Credits
Starter	1,000
Pro	10,000
Growth	50,000

Each action consumes part of that balance.

For example:

Action	Credits
AI Chat Request	1
Image Generation	10
Video Generation	100

The exact numbers don't matter.

The principle does.

Customers purchase credits.

Usage consumes credits.

Balances decrease over time.

When credits are better than subscriptions

Subscriptions are not bad.

In fact, they're often the best choice during the MVP stage.

The goal early on is validation.

Not pricing optimization.

However, credits become attractive when usage varies significantly between customers.

Typical examples include:

AI products
AI image generators
AI video platforms
Developer APIs
Agent systems
Compute-heavy SaaS products

A subscription says:

Everyone pays the same amount.

A credit system says:

Everyone pays according to consumption.

Neither approach is universally better.

The right choice depends on your product economics.

Common mistakes

Many teams underestimate how complicated credit systems become in production.

The first version often looks deceptively simple.

A balance exists.

Actions reduce that balance.

Everything works.

Until real customers arrive.

Some of the most common mistakes include:

Storing only a balance
Not keeping a transaction history
Ignoring duplicate requests
Missing idempotency
Forgetting expiration policies
No visibility into credit consumption

These problems rarely appear on day one.

They appear once your product starts growing.

Never store only a balance

Many implementations start like this:

customer_id | balance

123         | 5000

At first, this seems perfectly reasonable.

Then a customer asks:

Why do I only have 5,000 credits left?

Now you have a problem.

You know the balance.

But you don't know the history.

Where did the credits come from?

What consumed them?

Were there refunds?

Were there manual adjustments?

A balance alone cannot answer those questions.

Keep a transaction ledger

A much better approach is storing every credit movement.

Examples include:

Credit purchases
Top-ups
Usage consumption
Refunds
Expirations
Manual adjustments

A simplified architecture might look like:

customers

credit_balances

credit_transactions

usage_events

The balance becomes a projection.

The ledger becomes the source of truth.

This makes support, debugging, and auditing dramatically easier.

Consumption tracking is the real challenge

Most founders spend weeks discussing pricing.

Very few spend the same amount of time discussing usage tracking.

Ironically, usage tracking is usually the harder problem.

A typical MVP implementation looks like:

credits -= 10;

Simple.

Until production traffic arrives.

Now you must handle:

Duplicate requests
Retries
Race conditions
Background jobs
Partial failures

Suddenly usage tracking becomes infrastructure.

Why idempotency matters

Imagine a customer generates an image.

The operation costs:

50 credits

The request fails halfway through.

The client retries.

Without protection, the system may deduct credits twice.

This is why every usage event should have a unique identifier.

Example:

{
  "usage_id": "img_12345",
  "credits": 50
}

If img_12345 has already been processed, it should never be processed again.

This concept is known as idempotency.

And it is one of the most important parts of a reliable credit system.

Preventing race conditions

Consider a customer with:

100 credits

Two requests arrive simultaneously.

Each consumes:

60 credits

Without proper database locking:

Request A succeeds
Request B succeeds

The customer spends 120 credits while owning only 100.

This happens more often than many teams realize.

Balance updates should always be atomic.

Database transactions are your friend.

Designing top-up systems

Most prepaid credit products eventually need top-ups.

Examples include:

Buy 1,000 credits
Buy 10,000 credits
Buy 50,000 credits

Some companies also offer:

Automatic recharge
Threshold-based recharge
Subscription renewals with included credits

A typical hybrid model looks like:

Feature	Included
Subscription	$29/month
Included Credits	1,000
Additional Usage	Purchased separately

This combines predictable recurring revenue with flexible consumption.

Should credits expire?

Credit expiration is one of the most debated decisions in SaaS monetization.

Some companies never expire credits.

Others use expiration windows such as:

30 days
90 days
1 year

Benefits include:

Encouraging usage
Reducing long-term liabilities

Drawbacks include:

Customer frustration
Additional support requests

If credits expire, transparency is critical.

Customers should always know:

Their current balance
When credits expire
Which credits expire first

Architecture considerations

As products mature, credit systems evolve beyond simple balances.

A robust architecture usually includes:

Component	Responsibility
Credit Ledger	Source of truth
Credit Balance	Fast balance lookup
Usage Events	Consumption tracking
Billing System	Credit purchases
Entitlements	Access control
Webhooks	Event synchronization

The biggest mistake founders make is treating credits as a simple number.

They're not.

Credits eventually become a financial system.

And financial systems require reliability.

Real-world examples

Many modern products use some variation of prepaid credits.

Examples include:

AI image generators
AI video platforms
Coding assistants
API products
Agent platforms
Cloud infrastructure providers

The implementation differs.

The principle remains the same.

Usage consumes a measurable resource.

Credits provide a way to monetize that resource predictably.

Final thoughts

Prepaid credits have become one of the most popular monetization models for AI and SaaS products.

They align usage with costs.

They improve revenue predictability.

They provide flexibility that subscriptions often cannot.

But implementing credits correctly requires more than adding a balance column to a database.

Reliable systems require:

Transaction ledgers
Idempotency
Atomic updates
Usage tracking
Top-up management
Expiration policies

The earlier you design these foundations, the easier your product will scale.

Building the pricing model is easy.

Building a reliable credit system is the hard part.

Additional resources

If you're implementing prepaid credits, useful technical resources include:

Usage-based billing guides
Credit consumption APIs
Entitlement management systems
Usage tracking architectures
Webhook-driven billing workflows

These topics become increasingly important as products move beyond the MVP stage and start handling real customer usage.

How to Track AI Usage Without Losing Revenue (Complete Guide)

Ciroandrea — Mon, 25 May 2026 08:20:44 +0000

Most AI products eventually run into the same problem:

Tracking usage sounds simple.

Until it isn't.

At first, all you need is a counter.

A request comes in.

You decrement a credit.

You process the request.

Done.

Or at least that's what most teams think.

As usage grows, things start breaking:

duplicate requests
retries
race conditions
timeout failures
inconsistent balances
billing mismatches

And suddenly a simple counter becomes a revenue problem.

The Naive Implementation

Most products start with something similar to this:

if (credits > 0) {
  credits--;
  executeRequest();
}

Looks harmless.

The user has credits.

A request arrives.

A credit is consumed.

The request is executed.

Simple.

The problem is that real-world systems are rarely this simple.

What Starts Breaking

The moment real users start using your product at scale, unexpected situations appear.

Retries

Networks fail.

Browsers retry requests.

Mobile apps resend actions.

Background jobs run again.

A single user action can generate multiple identical requests.

Without protection, credits may be consumed multiple times.

Race Conditions

Imagine a user has one credit remaining.

Two requests arrive at exactly the same time.

Both processes check the balance.

Both see one available credit.

Both proceed.

Now the user consumed two requests while paying for one.

Or worse:

Your balance becomes negative.

Partial Failures

One of the most dangerous situations looks like this:

Consume credit
↓
Call AI provider
↓
Timeout

Did the AI provider process the request?

Maybe.

Did the user receive the result?

Maybe not.

Should you refund the credit?

Should you charge again?

These situations become surprisingly difficult to handle consistently.

How Revenue Leaks Happen

Most revenue leaks don't come from pricing mistakes.

They come from tracking mistakes.

A few common examples:

Free Usage

The request succeeds.

The credit is never consumed.

The user receives value for free.

Double Charging

A retry consumes credits twice.

The user gets charged more than expected.

Now support tickets start arriving.

Billing Mismatch

Your billing dashboard shows one number.

Your usage records show another.

Your invoices show a third.

Nobody knows which number is correct.

Missing Audit Trail

A customer asks:

Why was I charged?

You have no record explaining exactly what happened.

Now you're forced to guess.

A Safer Architecture

Reliable usage tracking requires more than a simple counter.

The goal is to create a system that is:

auditable
idempotent
atomic
reliable under concurrency

Use a Usage Ledger

Instead of simply decrementing balances, record every consumption event.

Example:

ID          USER      UNITS
--------------------------------
1           user_1    -10
2           user_1    -20
3           user_1    -15

This creates a complete history.

You always know:

what happened
when it happened
how many units were consumed

A balance becomes the result of ledger events rather than a standalone number.

Make Consumption Idempotent

Every usage operation should have a unique identifier.

Example:

request_id = 9f7d3c2a

If the same request arrives again:

do not consume credits again
return the original result

This prevents duplicate charges caused by retries.

Consume Credits Atomically

Checking balances and consuming usage should happen inside a single transaction.

Bad:

Read balance
↓
Check balance
↓
Update balance

Good:

Transaction
↓
Verify balance
↓
Consume units
↓
Commit

This prevents concurrency issues and race conditions.

Design for Auditability

Sooner or later a customer will ask:

Why was I charged for this?

You should be able to answer immediately.

Store:

request id
timestamp
user id
consumed units
operation type

A complete audit trail saves countless support hours.

Why Counting Requests Isn't Enough

Many teams assume:

1 request = 1 unit

But AI products rarely work this way.

Different operations have different costs.

For example:

Text generation     = 1 credit
Image generation    = 20 credits
Video generation    = 100 credits

What matters isn't request count.

What matters is billable usage.

That's the metric that should drive monetization.

Final Thoughts

Tracking AI usage seems easy when your product has ten users.

It becomes infrastructure when your product has thousands.

The challenge isn't counting requests.

The challenge is building a system that remains correct when:

requests are duplicated
jobs retry
users scale
revenue depends on every consumption event

Because once usage becomes your pricing model, tracking usage becomes part of your business model.

And every mistake eventually turns into lost revenue.

Learn More

If you're building AI credits, usage-based billing, or prepaid consumption systems, one of the most important concepts is maintaining an auditable usage history through a usage ledger.

I wrote more about the architecture behind credits, consumption tracking, entitlements and billing synchronization in the Licenzy documentation:

https://licenzy.app/docs/usage-metering

It includes examples for:

consumption tracking
idempotency
usage packs
credit-based monetization