A feature that cost nothing during its pilot now shows a bill line though its traffic only doubled — why?

## What a free allowance is A **free allowance** is a quantity of a specific pricing dimension that a provider does not charge for in a given period — so many requests a month, so many gigabyte-months held, so many hours of a small unit running. It is not a discount and not a credit: it is a **threshold on one meter**, below which that meter contributes nothing to the bill. The important consequence is epistemic rather than financial. While usage sits under the allowance, the bill line for that dimension is zero, and zero carries no information about the rate, the quantity, or how either will behave. A pilot that costs nothing has not demonstrated that the feature is cheap; it has demonstrated that the feature is small. ## Why the step looks disproportionate Only the excess above the allowance is normally charged, which sounds gentle, but the **visible** change is not gentle at all, because the starting point was zero. Take an invented monthly allowance of 1,000,000 requests on a dimension charged at an illustrative rate: | Monthly requests | Charged requests | Visible bill change | |---|---|---| | 600,000 | 0 | none | | 1,200,000 | 200,000 | zero to a real number | | 2,400,000 | 1,400,000 | seven times the previous line | Traffic doubled twice; the charged quantity went from nothing to 200,000 and then multiplied sevenfold. Nothing non-linear happened to the rate — the allowance simply stopped absorbing the usage, and the charged quantity grows much faster than total usage does near the threshold. This is why growth forecasts anchored on a pilot bill are usually badly wrong in the same direction. ## The shapes allowances come in - **A recurring per-period grant**, refreshed every month on a specific dimension. - **An introductory grant**, available only for an initial period after sign-up, after which the same usage is billed in full. - **A grant scoped to an account, or to a whole organisation** — providers differ here, and it matters: if the grant is per account, a fleet of many accounts multiplies it, and if it is organisation-wide, splitting into more accounts buys nothing. - **Per-dimension, not per-service.** A service can have an allowance on requests, none on stored volume, and none on held capacity. Crossing one changes nothing about the others. ## Estimating past the allowance The method is straightforward once the trap is named. 1. Identify, per dimension, whether an allowance applies and what its quantity is. 2. Project each quantity forward at the growth you actually expect, independently — they do not grow together. 3. Subtract the allowance from each projected quantity, floor at zero, and multiply the remainder by the rate. 4. Sanity-check by modelling the bill as if the allowance did not exist. That is your steady-state cost, and it is the number the business should plan against. Step four is the one worth insisting on. An allowance is a fixed quantity and your usage is a growing one, so the allowance's share of your usage tends to zero. Treating it as a permanent subsidy builds a plan on a shrinking foundation. ## What this looks like when it goes wrong The classic version is a feature validated in a pilot, approved on the strength of a bill that read zero, and then reported as a cost regression the first month it becomes real. Nothing regressed. The second version is a team that splits workloads across accounts specifically to harvest a per-account allowance, then finds either that the grant was organisation-wide all along, or that the operational cost of running many accounts exceeds what was saved. The third is confusing an allowance with a **minimum billable amount**: an allowance is a quantity you are not charged for, while a minimum is a quantity you are charged for even if you did not use it. They point in opposite directions and are easy to mix up in a spreadsheet.