The AI product with two bills and one growth plan

The product has moved beyond a prototype. Customers upload more material, searches run more often, and each release adds another AI-assisted step. The team can see demand growing, but it cannot yet explain what that growth means for model calls, embeddings, compute, storage, databases, or network traffic.

A single monthly total hides the useful questions. Some spend follows active users. Some follows the size of a document. Some appears only when a job is retried, a prompt gets longer, an index is rebuilt, or a GPU waits for work.

Before committing to annual capacity, the team needs a workload model that separates those drivers and shows which assumptions matter most.

We start with the product flows that create demand. For model inference, that can mean requests per workflow, input and output tokens, embedding volume, retries, evaluation traffic, and model mix. For cloud infrastructure, it can mean compute hours, concurrency, stored data, database operations, network transfer, and recovery requirements.

The forecast uses ranges rather than false precision. A base case describes expected operation, a growth case tests the product plan, and a peak case shows what a launch, campaign, batch job, or incident could do to the system.

This makes uncertainty visible. The team can see which demand should be committed, which should remain elastic, and which part can be reduced through architecture or product changes before anything is purchased.

Model capacity needs project boundaries, API keys, rate limits, token and request budgets, and alerts that point back to a product workflow. Cloud capacity needs environment separation, identity and access controls, resource tags, budgets, quotas, monitoring, backup, and an owner for idle or unexpected resources.

The two plans still need to meet. A retrieval feature may spend on embeddings and generation while also increasing storage, database, and compute demand. An evaluation run may be a model cost, a cloud workload, or both. The architecture map shows where those costs cross so the team does not optimise one bill by making the other worse.

Provisioning then follows the agreed boundary. Capacity, configuration, dashboards, alerts, and the operating runbook are treated as one deliverable rather than separate commercial and technical conversations.

An annual programme needs checkpoints. Actual usage is reviewed against the forecast, unusual demand is explained, and optimisation work is ranked by the amount of control it gives the team—not by cosmetic percentage reductions.

Some changes are technical: shorter prompts, caching, model routing, storage lifecycle rules, right-sized compute, or scheduling batch work. Others are product decisions about which feature deserves the cost and which service level customers actually need.

Before renewal, the team has a record of committed and consumed capacity, remaining assumptions, provider constraints, and the next workload forecast. It can renew, resize, or change direction with evidence rather than momentum.