For a long time capacity planning at my company meant watching a dashboard until something turned orange, then buying more of whatever resource had run out. Database storage crept toward its limit and someone bumped the tier. A queue backed up during a busy week and someone added a worker. Every decision was correct in isolation and the whole approach was still just reacting one step behind whatever had already started to hurt.
The uncomfortable part is that none of this was actually planning. Planning means knowing what you will need before you need it. What I was doing was noticing scarcity after it arrived and calling the fix a plan, when it was really just triage with a longer delay between the problem and the pain.
Claude Code changed this by making it cheap to model growth before it happens instead of measuring it after it already forced a decision. The underlying math of capacity planning was never the hard part. Sitting down regularly to actually run it, across every resource that matters, before the number turns orange, was the part nobody had time for. Here is the workflow.
Why Reactive Scaling Feels Fine Until It Does Not
Reactive scaling works, in the narrow sense that the orange dashboard eventually gets fixed and the system keeps running. What it does not do is give anyone time to make a good decision. A database tier gets upgraded under pressure, at whatever price and whatever migration risk exists in that moment, instead of at a calm moment chosen in advance.
The deeper problem is that reactive scaling treats every resource as independent. Storage gets watched. Compute gets watched. Nobody is watching the relationship between them, so the actual constraint, the one resource that will run out first as growth continues, stays invisible until it is the one causing the incident.
Growth also is not linear, and a plan built on last quarter's growth rate quietly stops matching reality without anyone noticing. A traffic curve that looked like steady 10 percent monthly growth for a year can shift shape overnight after a feature launch or a new customer segment, and the old capacity model keeps reporting comfortable headroom right up until it is wrong.
A system that has never had its capacity projected forward does not have a safety margin. It has an unmeasured margin, and an unmeasured margin looks identical to a healthy one until the exact week it is not.
The workflow below turns capacity planning from a reactive scramble triggered by orange dashboards into a routine projection that stays ahead of growth instead of behind it.
For a related look at what happens when a system meets load it was never modeled against, see Claude Code for Load Testing, which answers where the breaking point is right now. This workflow answers when growth will reach it.
The Growth Modeling Skill
The first skill builds an honest picture of how usage is actually trending, across every resource that matters: storage, compute, database connections, queue throughput, request volume. It pulls historical usage data over a long enough window to separate real trend from noise, and fits a growth curve to each resource independently rather than assuming everything grows at the same rate.
This matters because resources do not grow together. Request volume might be flat while storage grows steadily from accumulated data. Compute might spike with a specific feature while database connections stay stable. Treating growth as one number hides exactly the divergence that eventually causes a surprise.
The skill also flags when a resource's growth curve has recently changed shape, since a shift in slope is the signal that something changed upstream, a new feature, a new customer segment, a changed usage pattern, and the old projection no longer applies.
The Threshold Skill
Knowing the growth curve is only useful next to knowing where the limit actually is. The second skill maps every resource against its real ceiling: the point where a database tier maxes out, where a queue's throughput can no longer keep pace, where a compute cluster needs another node before response times degrade.
The skill also accounts for the practical ceiling rather than the theoretical one. A database technically supports more connections than the point where query latency starts climbing, and the number that actually matters is the second one. Same for storage, where performance often degrades well before a disk is literally full.
Combining the growth curve with the real threshold produces the number that actually matters: a projected date. Not "storage is at 70 percent" but "storage crosses the point where performance degrades in approximately seven weeks at the current growth rate." A percentage tells you where you are. A projected date tells you what to do about it and by when.
The Cost Projection Skill
Capacity planning that ignores cost is only half the job, since most scaling decisions are really cost decisions wearing a technical disguise. The third skill takes the same growth curves and projects forward what each resource will cost at each future scaling tier, not just whether it will be needed.
This turns a vague sense that infrastructure spend is growing into a specific, dated number: what the bill looks like in three months if nothing changes, and what it looks like under each realistic scaling option. It also surfaces the option that a raw capacity view misses entirely, that sometimes the answer to approaching a ceiling is not a bigger tier but an architectural change that avoids needing one, and that tradeoff only becomes visible when cost and capacity sit in the same report.
This is the same discipline behind Claude Code for Performance Optimization Patterns, applied to the question of what growth will cost rather than what current usage costs.
The Planning Report Skill
The fourth skill turns growth curves, thresholds, and cost projections into something a team can actually decide on, rather than a pile of numbers someone has to interpret under pressure. It produces a report ranked by urgency: which resource hits its ceiling soonest, what the options are at that point, what each option costs, and what lead time each option needs to execute safely.
The report tracks these projections over time, run after run, so a shifting growth curve becomes visible as a trend rather than a surprise discovered the week it matters. A projected date that keeps moving closer release after release is a very different situation from a stable one, and only a tracked history shows which one is happening.
It also connects capacity projections to known upcoming events, the same way a traffic model connects to a marketing push. If a growth curve already shows a database approaching its ceiling in two months and a new customer onboarding is expected to accelerate that curve, the report surfaces the collision before it happens instead of during the incident that reveals it.
How the Workflow Runs in Practice
The growth modeling skill runs first, refreshing the trend for every tracked resource from current usage data. The threshold skill maps those curves against real operating ceilings, producing a projected date for each resource rather than a static percentage. The cost projection skill prices out what each scaling path costs at each point along that timeline.
The planning report skill folds all of it into a single ranked view, refreshed on a schedule rather than triggered by an orange dashboard. Anything with a projected date approaching soon gets flagged with enough lead time to make a calm decision instead of an emergency one.
Over time the answer to "when will we need to scale this" stopped being a shrug followed by a scramble. It became a specific date, recalculated regularly, with a cost attached and enough runway to choose the right option instead of whichever one could be executed fastest under pressure.
What This Workflow Did to My Practice
The first change was catching a resource that was going to become a real problem two months before it would have shown up as an incident. The growth curve on a queue's throughput had quietly steepened after a feature shipped, and the old mental model of "that queue is fine" was already wrong by the time the report caught it.
The second change was how scaling decisions get made. Before the workflow, a scaling decision happened the week a resource actually ran out, under whatever pressure that created. After the workflow, it happens weeks ahead, with enough time to compare options on cost and effort instead of picking whichever one could be turned on fastest.
The third change was that infrastructure cost stopped being a monthly surprise on an invoice. Seeing the projected cost curve next to the capacity curve made scaling decisions and budget conversations the same conversation instead of two conversations that never lined up.
The fourth change was the biggest one. I stopped finding out a resource was tight from the resource itself, and started finding out from a report that had already done the math weeks in advance. That shift moves capacity planning from something that happens to a team into something a team actually does on purpose.
For the full picture of how I run production systems with Claude Code, the complete series on DEV.to covers every workflow I depend on, from capacity planning to load testing to chaos engineering.
FAQ
How far ahead should a capacity projection look?
Far enough to give real lead time on whatever the slowest scaling option requires, whether that is a budget approval, a migration, or a hardware order. For most teams that means a projection window of two to three months, refreshed regularly rather than calculated once and trusted indefinitely.
What happens when actual growth does not match the projected curve?
That is exactly why the workflow reruns on a schedule instead of producing a single forecast. A growth curve that shifts shape shows up as a change in the projected date at the next run, which is the signal to look at what changed upstream rather than a sign the workflow failed.
Does this replace judgment about architectural changes versus scaling up?
No. It supplies the numbers that make that judgment possible. Whether the right move at a given ceiling is a bigger tier or a redesign is still a decision a team makes, but it is a much better decision with a dated projection and a cost comparison in front of it than with a gut feeling and an orange dashboard.
Is this only useful for large infrastructure teams?
No. A small team benefits more from this in some ways, since a small team has less slack to absorb a reactive scramble. Knowing two months ahead that a database tier needs upgrading is valuable at any scale, and the cost projection matters most exactly when budget is tight.
The move from reacting to scarcity to projecting it in advance is one of the quieter but highest leverage changes I have made in how I run infrastructure. The cost was building four skills that now run on a schedule without me. The payoff was a calm decision made two months before a deadline, instead of an expensive one made the week a resource actually ran out.
Top comments (0)