Unit economics per product: AI costs and shared cost allocation

A single product company can get away with rough numbers for a while. Revenue minus costs is profit, and if the bank balance goes up, things are probably fine. A group of companies sharing infrastructure cannot. Once hosting, monitoring, an AI gateway and a handful of tools serve several products at once, it becomes surprisingly easy to lose sight of what any one of them actually costs to run.

This article explains how we approach unit economics per product at Oryvelon: how we define a unit for very different businesses, where AI costs belong, and how we allocate shared costs so the numbers help decisions instead of distorting them. It is written for founders and operators, but it applies to any team running more than one product on common foundations.

Why per-product unit economics matter in a group

Oryvelon builds and operates independent companies, and each one is expected to stand on its own. We explain the principle in Designing companies to stand alone. A company can only stand alone financially if we know, with reasonable honesty, what it earns and what it costs.

Three problems appear when that is not measured properly:

• Cross-subsidy by accident. A product with heavy AI usage quietly runs on costs that the group pays, and looks healthier than it is.
• Unfair burden. A small product gets charged a share of shared costs that has nothing to do with what it uses, and looks worse than it is.
• Bad capital decisions. Money and time go to the product with the best-looking spreadsheet rather than the best actual economics.

Unit economics are the lowest level at which we can see whether a product works. Everything above that, including monthly company results and portfolio decisions, is built from them.

Step one: define the unit

A unit is the thing a customer pays for, or the thing that most directly drives revenue. It sounds obvious. In practice, teams often skip it and end up with averages that describe nothing in particular.

For the companies in the group, the natural units look like this:

Some products have more than one unit. KeşifAtlası has free eligibility tests that cost money to run and paid reports that bring revenue in. The free test is not a unit with revenue; it is a cost of acquiring the paid unit, and we treat it that way. The economics of that funnel are discussed in From free test to paid report.

The rule we apply: pick the unit that the business will actually be managed on, write it in the company's source of truth, and do not change it lightly.

Step two: separate variable, direct fixed and shared costs

Once there is a unit, costs fall into three buckets.

Variable costs rise with each unit. AI calls per report, shipping per order, payment fees per transaction, verification checks per profile.

Direct fixed costs belong to one company but do not rise with each unit. A domain, a product-specific tool subscription, a contractor working only on that company.

Shared costs support several companies at once. Group hosting, the AI gateway itself, monitoring, security tooling, shared design and engineering time.

Keeping these separate is what makes the numbers readable. Contribution per unit is revenue per unit minus variable costs. It answers the question "does each sale help or hurt?" Company profit subtracts direct fixed costs and an allocated share of shared costs. It answers "does this company pay for itself?" Both questions matter. They are not the same question, and mixing them hides problems.

Where AI costs belong

AI costs are the part of the model that has changed most in recent years. For some of our products they are the largest variable cost per unit. They are also easy to lose, because model calls are small, frequent and often billed to one account.

Our rule is that AI costs belong to the product that caused them, and ideally to the feature and unit as well. The shared AI gateway, described in Building an AI gateway, makes this practical. Every call through it carries a product identifier and a feature tag. That lets us answer questions such as:

• What does one MerchNivo daily briefing cost in model usage, on average and at the expensive end?
• How much of a KeşifAtlası report's cost is the explanation, and how much is the follow-up questions?
• What share of ZodiVela's AI spend goes on readings that are never completed?

A shared gateway could, in theory, become a reason to pool AI costs and split them evenly. We think that would be a mistake. The gateway is shared infrastructure; the usage flowing through it is not. Each product has its own budget, its own limits and its own line in the numbers.

Costing AI per unit in practice

A simple way to cost AI per unit:

1. Tag every model call with product, feature and, where possible, the unit it belongs to (an order, a report, a session).
2. Sum model charges by tag over a period.
3. Divide by the number of units delivered in that period.
4. Track the average and the upper tail, because a small share of very expensive units can distort the average.

It is also worth measuring cost per useful outcome rather than per call. A report that needed three retries because output failed schema validation cost three times as much as it should have. See Structured outputs and schema validation for why validation affects cost as well as quality.

Levers that change AI cost per unit

AI unit cost is not fixed. The main levers:

• Model routing. Simple tasks go to smaller, cheaper models; hard tasks go to stronger ones. See Model routing.
• Caching. Repeated explanations of the same rule or the same product data can often be reused safely. See Latency and caching for AI.
• Prompt size. Sending only the data a task needs reduces cost and often improves quality.
• Fewer retries. Better prompts and validation reduce the number of calls that fail and repeat.
• Budgets and limits. Per-product soft and hard limits catch runaway usage before it becomes a large invoice. The wider approach is in Cost discipline for AI products.

Allocating shared costs without distorting decisions

Shared costs are real, and every company should carry a fair share of them. The difficulty is that any allocation rule is partly arbitrary, and a bad one can make a good product look bad or a weak product look strong.

We follow four principles.

One written rule, applied consistently. The allocation method is written down and applied the same way each month. It is not adjusted to help a product through a review.

Use a driver where one exists. Where there is a clear usage measure, such as storage, requests or compute time, costs are allocated by that measure. Hosting that serves four products can be split by each product's share of requests or resources.

Use a simple split where no driver exists. Some shared costs, such as security tooling or group-level design time, have no meaningful usage measure. For these we use a simple, agreed split, which might be equal shares among active companies or a split weighted by stage. Simplicity beats false precision.

Show allocated costs separately. In every company report, shared costs appear on their own lines, below contribution and direct costs. Anyone reading the numbers can see what the company controls and what it has been assigned.

A worked example

Imagine a month in which group hosting costs a certain amount, the AI gateway's own running cost (excluding model usage, which is already attributed) is smaller, and shared tools make up the rest. Four companies are active.

• Hosting is allocated by each company's share of requests. A product with heavy traffic carries more.
• Gateway running cost is allocated by each company's share of calls through it.
• Shared tools are split equally among the four, because they are used roughly evenly and there is no better measure.

A new company in its first weeks might carry a small share of hosting (little traffic), a small share of gateway cost (few calls) and a full equal share of tools. That last line can look heavy for a company with little revenue. We accept that, but we read it for what it is: the cost of existing inside the group, not a sign that the product is failing.

When to exclude shared costs from a decision

For some decisions, allocated shared costs are irrelevant. If we are deciding whether to run a marketing test for Noveniq, the question is whether the extra orders will produce positive contribution. The hosting bill does not change either way.

For others they are central. If we are deciding whether to keep a company at all, the question is whether the group would be better off without it, and that includes which shared costs would actually disappear if it closed. Often the honest answer is "not many", which is useful to know. Shared costs that would remain regardless should not be the reason a company is stopped.

Unit economics by stage

Expectations change as companies move through their life. We would not judge a company in its first month on the same standard as one in its second year.

Negative unit economics early on are acceptable only if there is a credible path to positive ones: a plan to cut AI cost through routing or caching, a price increase supported by evidence, or volume discounts that will actually arrive. "It will get better at scale" is not a plan by itself.

These expectations feed directly into the group's continue, stop or scale checkpoints at 30, 60 and 90 days.

Acquisition cost and time to pay back

Contribution per unit tells us whether each sale helps. It does not tell us whether the business can afford to find customers. For that we compare contribution with acquisition cost.

For subscription products such as MerchNivo, the useful question is how many months of contribution it takes to pay back the cost of acquiring a customer, and how many customers stay that long. For order-based businesses such as Noveniq, it is whether the first order plus likely repeat orders covers acquisition. The shape of these calculations differs by model; see SaaS subscription plus usage and Running a DTC brand as a real operating business.

Two warnings from experience across the industry. First, acquisition costs rarely stay low as spend increases; the cheapest customers usually come first. Second, repeat and retention assumptions are the easiest numbers to be optimistic about. We prefer to use observed cohort behaviour, even if the sample is small, over hopeful projections.

Using unit economics to set prices and limits

Unit economics are most useful when they change what we do. Two of the most direct uses are pricing and usage limits.

On pricing, the unit view tells us the floor. If a KeşifAtlası report costs a certain amount to produce, including AI explanation, rules lookups and an average share of human review, the price has to sit comfortably above that, with room for payment fees and refunds. It does not tell us the ceiling; that comes from what customers value and what alternatives cost. But knowing the floor prevents a very common mistake: launching at a price that loses money on every sale and hoping volume fixes it.

On limits, the unit view tells us where generosity becomes a risk. Imagine a ZodiVela subscription that includes unlimited follow-up questions. If a small group of subscribers asks hundreds each month, their AI cost can exceed what they pay. The answer is not to hide the limit in fine print. It is to design the plan honestly: a clear allowance, a fair-use policy written in plain language, or credits for heavier use. We would rather customers understand what they are buying than discover a surprise restriction.

Both uses depend on the same thing: a cost per unit that is recent, measured and trusted by the people making the decision.

What unit economics will not tell you

Numbers per unit are powerful and incomplete. They say little about brand strength, the quality of customer relationships, regulatory risk or the strategic value of learning in a new market. A product can have modest unit economics today and be worth continuing because it is building something the numbers do not yet capture.

We try to be explicit when we make that argument, and to put a date on it. "We accept thin contribution for another quarter because we are testing whether schools renew" is a reasonable position. "The numbers do not matter here" is not.

Common mistakes

• Averaging across products. A group-level "AI cost per user" hides the product that is expensive and the one that is cheap.
• Ignoring the tail. A few very heavy users or very long sessions can make a subscription unprofitable while the average looks fine.
• Leaving out human time. KeşifAtlası's escalations to people, CastLyra's manual verification, EduRelia's school support: these are variable costs and belong in the unit.
• Counting free usage as marketing only. Free tiers and free tests have unit costs. They should be measured and budgeted.
• Changing allocation rules to suit the story. Once a rule bends for one review, nobody trusts the numbers.
• Precision theatre. Allocating a small tool subscription by a complex formula wastes time that should go into decisions.

The monthly unit economics review

Each company produces a short monthly view, prepared from its own data and the gateway's usage records, as part of the group's regular operating rhythm. It covers:

1. Units delivered and revenue per unit.
2. Variable cost per unit, broken into its main parts, with AI shown separately.
3. Contribution per unit and in total.
4. Direct fixed costs.
5. Allocated shared costs, on separate lines.
6. Changes since last month, with a sentence explaining each notable one.
7. One or two actions: a routing change, a price test, a cost to remove.

The review is short. Its value is in the trend. A cost per unit that creeps up a little every month is easy to miss in a single snapshot and obvious in a sequence.

Summary

Unit economics per product start with a clear unit for each company, whether an order, a report, a reading or a school seat. Variable costs, including AI, are attributed to the product and feature that caused them, which a tagged AI gateway makes practical. Direct fixed costs sit with their company. Shared costs are allocated by a simple, written rule, shown separately, and never adjusted to suit a narrative. The result is a set of numbers that tells us honestly whether each sale helps, whether each company pays for itself and where to act next, which is exactly what a group of independent companies needs to make good decisions.

Questions and answers

What are unit economics for a digital product?

Unit economics describe the revenue and variable cost attached to one unit of what a product sells, such as a subscription month, a report or an order. They show whether each unit makes or loses money before fixed costs.

How should AI model costs be included in unit economics?

AI costs should be attributed to the specific product and, where possible, the specific feature and unit that triggered them. A per-product budget and tagging at the gateway make that possible.

How does Oryvelon allocate shared infrastructure costs?

Shared costs are allocated to companies by a simple written rule, such as usage share or an agreed fixed split, and reported separately from direct costs. The rule is reviewed periodically rather than adjusted to make one product look better.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Commerce & SaaS

NextVerification in talent marketplaces: identity, portfolio and consent →