Driver-Based Budget Builder
When to use
Use whenever a budget needs to be built or rebuilt from real drivers rather than "take last year and add X%" — a shortcut that hides whether growth is coming from volume, price, or something else, and applies the same blended assumption to every department regardless of what actually drives its cost.
What it does
Builds a phased, monthly budget from explicit revenue drivers (starting volume, volume growth rate, price, and timed price changes) and department-level cost growth rates via a bundled calculator, producing a full monthly build with revenue, opex by month, and EBITDA, rather than a single annual figure with no visibility into how it's phased.
Method
- Decompose revenue into volume and price separately, never a single blended revenue growth rate. State the starting volume, the monthly volume growth rate, the starting price, and any planned price changes with their timing (many businesses change price once a year, not continuously — model it as a discrete jump on the right month, not smoothed across twelve months).
- Build cost by department, not one company-wide opex line. Each department has a different natural growth rate: R&D might scale with headcount plans, G&A might grow slower than revenue, sales and marketing might scale with the pipeline the growth target requires.
- State each department's monthly growth rate explicitly, tied to a real driver (headcount additions, planned tooling costs, marketing spend as a percent of pipeline target) rather than a copied-forward percentage.
- Run the bundled calculator (
scripts/driver_budget.py) to get the full monthly build: units, price, revenue, total opex, and EBITDA for every month of the year.
- Check the phased shape, not just the annual total. A budget that's flat month to month rarely matches how a real business actually grows — look for whether the monthly progression makes sense (seasonality, a price increase landing on a specific month, ramping costs ahead of a launch).
- Sanity-check the full-year EBITDA margin against what's actually achievable — a budget that implies a margin far outside historical range or peer benchmark needs its drivers revisited, not just accepted because the formula produced it.
- Feed this bottom-up build into annual-operating-plan to reconcile against any top-down target leadership has in mind, rather than treating this build as the final published budget on its own.
Inputs
- Starting volume/units and monthly volume growth rate
- Starting price and any planned price changes with timing
- Department list with starting monthly cost and monthly growth rate per department
- Config saved as JSON matching the format documented at the top of
scripts/driver_budget.py
Output format
Full monthly table: units, price, revenue, total opex, and EBITDA for every month; full-year totals; full-year EBITDA margin.
Example
A budget built as "last year's $3.2M revenue plus 20%" gives one number with no way to check if it's realistic. Rebuilding from drivers, 1,000 starting units growing 4% monthly with a 3% price increase in month 7, produces $3.82M with visibility into exactly when and why revenue accelerates, plus a full monthly opex build showing the business runs at a -68% EBITDA margin for the year, a number worth challenging on the cost side before the budget is finalized, not something a single blended annual figure would have surfaced.
Common pitfalls
- Building revenue as one blended growth rate instead of separating volume and price, which hides which lever is actually doing the work.
- Applying the same growth rate to every department instead of driver-based rates per department.
- Publishing only the annual total without the monthly phasing, missing whether the shape of the year actually makes sense.
1---2name: driver-based-budget-builder3description: Builds a monthly budget from real volume, price, and department cost growth drivers via a bundled calculator, phased across the year, instead of the "last year plus X%" shortcut that hides every real assumption behind one blended growth rate. Use whenever the user is building an annual or departmental budget, needs a phased monthly plan rather than a single annual number, or has a budget built as a flat percentage increase over last year with no driver logic behind it.4---56# Driver-Based Budget Builder78## When to use9Use whenever a budget needs to be built or rebuilt from real drivers rather than "take last year and add X%" — a shortcut that hides whether growth is coming from volume, price, or something else, and applies the same blended assumption to every department regardless of what actually drives its cost.1011## What it does12Builds a phased, monthly budget from explicit revenue drivers (starting volume, volume growth rate, price, and timed price changes) and department-level cost growth rates via a bundled calculator, producing a full monthly build with revenue, opex by month, and EBITDA, rather than a single annual figure with no visibility into how it's phased.1314## Method151. **Decompose revenue into volume and price separately**, never a single blended revenue growth rate. State the starting volume, the monthly volume growth rate, the starting price, and any planned price changes with their timing (many businesses change price once a year, not continuously — model it as a discrete jump on the right month, not smoothed across twelve months).162. **Build cost by department, not one company-wide opex line.** Each department has a different natural growth rate: R&D might scale with headcount plans, G&A might grow slower than revenue, sales and marketing might scale with the pipeline the growth target requires.173. **State each department's monthly growth rate explicitly**, tied to a real driver (headcount additions, planned tooling costs, marketing spend as a percent of pipeline target) rather than a copied-forward percentage.184. **Run the bundled calculator** (`scripts/driver_budget.py`) to get the full monthly build: units, price, revenue, total opex, and EBITDA for every month of the year.195. **Check the phased shape, not just the annual total.** A budget that's flat month to month rarely matches how a real business actually grows — look for whether the monthly progression makes sense (seasonality, a price increase landing on a specific month, ramping costs ahead of a launch).206. **Sanity-check the full-year EBITDA margin against what's actually achievable** — a budget that implies a margin far outside historical range or peer benchmark needs its drivers revisited, not just accepted because the formula produced it.217. **Feed this bottom-up build into annual-operating-plan** to reconcile against any top-down target leadership has in mind, rather than treating this build as the final published budget on its own.2223## Inputs24- Starting volume/units and monthly volume growth rate25- Starting price and any planned price changes with timing26- Department list with starting monthly cost and monthly growth rate per department27- Config saved as JSON matching the format documented at the top of `scripts/driver_budget.py`2829## Output format30Full monthly table: units, price, revenue, total opex, and EBITDA for every month; full-year totals; full-year EBITDA margin.3132## Example33A budget built as "last year's $3.2M revenue plus 20%" gives one number with no way to check if it's realistic. Rebuilding from drivers, 1,000 starting units growing 4% monthly with a 3% price increase in month 7, produces $3.82M with visibility into exactly when and why revenue accelerates, plus a full monthly opex build showing the business runs at a -68% EBITDA margin for the year, a number worth challenging on the cost side before the budget is finalized, not something a single blended annual figure would have surfaced.3435## Common pitfalls36- Building revenue as one blended growth rate instead of separating volume and price, which hides which lever is actually doing the work.37- Applying the same growth rate to every department instead of driver-based rates per department.38- Publishing only the annual total without the monthly phasing, missing whether the shape of the year actually makes sense.
Natan-Mohart