Unit economics for SaaS and digital products | Anexia

For the product cost model, we choose a unit that fits the product and the decision. This can be a successful order, an active customer or a fully processed transaction. A request that is technically easy to count does not automatically correspond to a sold or usable result. The definition must therefore be agreed with product owners and finance.

For the cost-per-transaction analysis, costs and usage are brought together over matching periods. Shared platform spending and reserve capacity are given traceable rules. In the unit economics analysis, we distinguish average values from segments that have different technical requirements. A single large customer or a complex type of transaction can significantly influence the overall picture. Faulty and repeated processing also belongs in the cost basis if it actually consumes resources. Acceptance checks sample allocations and known volume assumptions. In this way, the unit cost analysis delivers metrics that can support pricing, product development and architecture decisions. The statement remains tied to its defined cost basis and business unit.

The reference unit follows the business model. A request that is technically easy to measure cannot always be equated with an economically relevant result. For the unit cost analysis, we document the relevant assumptions and explain the reasons for the chosen option. Significant alternatives are considered against the same business requirements. This makes later adjustments easier when load, data volume or organisational responsibility change.

A sound decision also takes maintainability and handover into account. For the product cost model, we examine which skills are available internally and what additional support is needed. This connects technical possibilities with a realistic operating model. The client can see which tasks will arise regularly after the project and which decisions remain with them.

Average values can conceal particularly expensive customer segments or usage patterns and thus encourage wrong pricing decisions. In the cost-per-transaction analysis, we treat this point as a concrete review question. A risk is linked to the affected process, its possible impact and a suitable measure. Where prerequisites are still missing, the statement remains explicitly open until the necessary investigation has taken place.

We check volume completeness, double counting, seasonal effects and sensitivity to different allocation keys. For the unit economics analysis, we record the initial situation, the tested configuration and the result. Acceptance refers to the agreed scope. Open limitations are documented visibly and assigned to an owned next step. This allows your team to distinguish between a proven function, a conscious decision and an assumption that has not yet been confirmed.

Project example as an illustrative scenario

The following scenario is an application example and not a customer reference. A SaaS provider wants to understand why different customer segments with similar revenue cause significantly different technical costs. In the unit economics analysis, the first step would be to determine a suitable reference unit from a business perspective. Depending on the product, a technical request could trigger very different amounts of work and would therefore not automatically be the right unit.

For the unit cost analysis, usage and costs would be connected according to traceable segments. Retries, failed attempts and shared infrastructure would have to be taken into account. The team would check whether complex background processes can be assigned to individual customers or product features. Differences would have to remain explainable by actual requirements. An average across all customers could conceal particularly expensive usage patterns. The pilot would therefore compare selected segments and examine which technical changes influence their costs without reducing the agreed product benefit.

The result of the product cost model would be an understandable unit cost model with recognisable limits. Well-founded allocations and metrics for product and technology decisions would be provided. This could lead to a technical optimisation, a change in product design or a further pricing assessment. The latter would be carried out with those responsible on the commercial side. The model would have to be adapted for new features or forms of usage. It would not be a complete company valuation, but a concrete basis for assessing technical performance and economic benefit together.

Our experience and our engineering approach

We combine custom software development with the technical tasks of introduction and further development. For the unit cost analysis, we bring the perspectives of application, integration and operations together in a shared workflow. Business requirements remain connected to the technical decisions. You work with a defined scope of services and traceable results.

Our experience should become concretely verifiable for your project. That is why, in the technical exchange, we explain how we examine the relevant risks, which work results are planned and how your team can assess them. For the product cost model, we align the roles involved with the actual need. Available references are presented with their respective project and company context; confidential customer details are not used as general promotional claims.

Effort for the product cost model

Linking data, segmentation and the delimitation of indirect costs determine the effort. We therefore calculate the unit economics analysis on the basis of a defined scope and explicitly stated prerequisites. An initial analysis step can make sense if essential technical information is still missing. Work packages and acceptance criteria can then be agreed on a more reliable basis.

The unit cost analysis can be organised as a limited project, as a joint implementation with your team or with subsequent support. Rights of use, access, documentation and responsibilities are clarified in the contract. Ongoing operating hours, response times and external consumption costs are subject to separate agreements. This keeps it clear which services are provided once and which tasks arise regularly after the rollout.

Boundaries of the unit economics analysis

The technical cost model supports economic decisions but does not replace a complete company valuation. For the cost-per-transaction analysis, we already set out this boundary in the proposal. Required additional services are included together with their business rationale and are not silently assumed. Your team can therefore plan suitable internal skills and divide the overall work sensibly between those involved.