# Capacity Cost Model > Build a capacity and cost model for a service or feature — sized from a demand driver and its growth curve, not from instance types; unit economics (cost per request/tenant/GB); peak-vs-average and headroom as explicit decisions; cost at 1×/3×/10× with scaling cliffs named; and the forgotten line items (egress, logging, NAT, non-prod) checklisted. Use when the user needs to estimate cloud/infra cost, size capacity for launch or growth, project the bill at scale, or find what's driving a cost. - Skill: `sananthanarayan/capacity-cost-model` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add sananthanarayan/capacity-cost-model` - Raw SKILL.md: https://api.skillmd.com/api/skills/sananthanarayan/capacity-cost-model/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - Author: sananthanarayan (https://skillmd.com/u/sananthanarayan) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/sananthanarayan/capacity-cost-model --- # capacity-cost-model 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. ## How to respond 1. **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. 2. **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×). 3. **Model the components against the cost catalog** ([`reference.md`](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. 4. **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. 5. **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. 6. **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. 7. **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.) 8. **Emit with [`templates/cost-model.md`](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. ## Useful references in this skill - [`reference.md`](reference.md) — the cost-component catalog, the forgotten-costs checklist, headroom guidance, and common scaling cliffs - [`templates/cost-model.md`](templates/cost-model.md) — the model skeleton with demand, component, and growth-scenario tables ## Quality bar - **Sized from a demand driver with a growth curve**, not a chosen instance count. The driver and its source are stated. - **Every cost is a unit cost × a quantity**, with the unit price's source and date tagged. A bare monthly total fails. - **Egress, observability, and non-prod lines are present** (or explicitly n/a). Their absence is the signature of a model that's 40% low. - **Headroom and peak-vs-average are explicit decisions** with reasoning, not absorbed into a rounded number. - **Scaling cliffs are named in the 1×/3×/10× projection.** A linear extrapolation that hides a tier jump is a budget trap. - **Outputs are ranges with a lean; the unit-cost-at-scale trend is checked.** Rising per-unit cost with growth is flagged as an architecture issue. ## When to use this skill - ✅ Estimating run cost for a new service/feature before launch - ✅ Sizing capacity for a launch or a known growth event - ✅ "What will this cost at 10× / when we hit N tenants?" - ✅ Finding what's driving an existing cloud bill and where the next cliff is ## When NOT to use this skill - ❌ Deciding whether to build/buy/invest at all — that's `business-case` (this can feed its run-cost line) - ❌ Setting the performance/availability targets — that's `nfr-spec` (this sizes to meet them) - ❌ The migration/rollout sequence — that's `migration-plan` - ❌ A fixed-price SaaS seat with no scaling math — just read the price sheet ## Anti-patterns to avoid - ❌ **Sizing from instance types.** "Let's run 3 large nodes" before knowing the load — that's a guess wearing a SKU, idle or overwhelmed by luck. - ❌ **The denominator-free total.** "$4k/month" with no per-unit cost can't be projected, compared, or optimized. - ❌ **Forgetting egress and observability.** The two line items that turn a tidy estimate into a 40%-low one; the checklist exists because they're forgotten every time. - ❌ **Ignoring non-prod.** Three idle staging environments and a never-scaled-down dev cluster are real money the model pretends doesn't exist. - ❌ **Linear extrapolation past a cliff.** "10× the load, 10× the cost" right up until the sharded-cluster step doubles it. Name the cliff. - ❌ **False precision.** "$4,271.40/mo" from estimated inputs reads as certainty the model doesn't have. Ranges with a lean. - ❌ **Missing the rising-unit-cost flag.** A model where cost-per-tenant climbs with scale is describing an architecture that gets worse the more it succeeds — that's the headline, not a row.