Turns "how much will this cost to run?" into a model a reviewer can re-run and finance can trust — sized from demand, expressed in cost per unit, and honest about the line items everyone forgets until the invoice. Distinct from business-case (which decides whether to invest, across options) and nfr-spec (which sets the throughput/availability targets); this models the resources and dollars to meet a target you've already chosen.
-
Start from the demand model, never from instance types. The first question is "how much of what?" — the driver (requests/sec, tenants, GB stored, events/day, concurrent users), its current value, its growth curve, and the peak-to-average ratio. Ask at most 2 questions, spent on the driver's current volume + source and the peak ratio (the spikiness that decides static-vs-autoscale). Sizing to a round instance count instead of to demand is how clusters end up 80% idle or 200% over.
-
Express everything as unit economics. Cost per request / per tenant / per 1k events / per GB-month — because that's what scales predictably, what finance budgets in, and what reveals whether the architecture gets cheaper or more expensive per unit as it grows. ✅ "$0.012 per active tenant per day, dominated by the per-tenant search index" — ❌ "about $4k/month" (a number with no denominator can't be reasoned about at 10×).
-
Model the components against the cost catalog (reference.md) — compute, storage, network egress (the forgotten heavyweight), managed-service tiers, logging/observability (routinely a top-3 surprise), backups/DR, data transfer cross-AZ/region, and non-production environments (dev/staging/idle often 30–50% of the bill). Each line: the quantity from the demand model × the unit price, with the price's source/date tagged. Missing the egress and observability lines is the single most common way a model lands 40% low.
-
Make peak-vs-average and headroom explicit decisions, not defaults. State both the average load (what you bill for) and the peak (what you must serve), and the chosen target utilization + buffer with its reasoning: ✅ "size to peak × 1.3 for failover + spike; accept ~55% average utilization because the spike is revenue-critical". Over-provisioning burns money; under-provisioning is an incident — the headroom number is where that tradeoff is decided, so it's named, not buried in a rounded-up instance count.
-
Project at 1× / 3× / 10× and find the scaling cliffs. Cost rarely scales linearly — name where it jumps: the next instance/managed-service tier, cross-AZ egress kicking in, a license seat band, single-node → sharded, a free-tier ceiling. ✅ "linear to ~5×, then the search tier forces a sharded cluster (+$3k/mo step) at ~6×". A model that's a single multiplication hides the cliff that wrecks the budget.
-
Rank the cost drivers and use ranges. The 2–3 line items that dominate get named (optimization targets them, not the rounding error). Outputs are ranges with a stated lean (low/expected/high), never false precision — three estimated inputs don't produce "$4,271/mo". Tag input confidence like business-case does.
-
Set the cost guardrails. Budget alert thresholds, and the unit-cost regression check: cost-per-unit should hold flat or fall as volume grows; if the model shows it rising with scale, that's a flagged architectural problem, not a footnote. (Mirrors success-metrics' guardrail discipline; the alerting itself is an nfr-spec cost target.)
-
Emit with templates/cost-model.md in one message: demand model, component table with unit prices, unit economics, total at average + peak, growth scenarios with cliffs, cost-driver ranking, the forgotten-costs checklist (each ticked present or n/a), and guardrails. State the assumptions that most move the total at the top.
