Side Quest

Revenue Planning Simulator

Is this ending ARR a retention plan, an expansion plan, or a new-logo capacity plan?

Who uses it
A CRO or RevOps lead editing one planning year for the fictional company Northline Security.
Decision it enables
Whether the residual is already covered, or the plan still needs capacity and pipeline.
Working today
A Next.js and Postgres app in gtm-revenue-os. Not embedded here. No public demo URL.
Workflow and next steps
Inputs → review → output
Assumptions → validation → ARR bridge → ramped capacity → pipeline shifted by the sales cycle. Formulas only. No model.
Planned next
The operating plan can copy AE count, quota, attainment, ramp, and ending target. That copy changes planned capacity only.
Technologies in this repo or a linked project
Next.js, TypeScript, and Postgres in gtm-revenue-os. Deterministic formulas with unit tests.

Where it stands

Prototype. The software runs and the formula tests pass. It is not embedded on this site.

My role

I built the planner in gtm-revenue-os. It is not a plan I ran at Truffle, Rapid7, Forcepoint, or Darktrace.

Metric to test

On the default fixture, GRR retains $9.5M and the residual new-business requirement is $9.5M. That is a planning assumption, not a result.

Links

No public demo or repository beyond this page.

How it works

The problem I kept seeing

An ending ARR target does not say whether the company gets there by keeping the book, expanding it, or hiring.

Hiring dates and pipeline targets never meet the bridge when retention, expansion, and new business stay in separate plans.

Without a repeatable answer: The team debates a single ending number and cannot see which lever is supposed to produce it.

What I was working from

Synthetic default book: $10M opening ARR, 95% GRR, $1M expansion, $20M ending target. Required new ARR is what remains after retention and expansion. On that fixture, GRR retains $9.5M and the residual new-business requirement is $9.5M. These are planning assumptions, not a result.

Workflow

Enter assumptions → Read the bridge → See ramped capacity and the hiring calendar → Shift pipeline creation back by the sales cycle → Save or compare a scenario

In plain language

Assumptions → Validation → ARR bridge → Capacity and ramp → Pipeline → Monthly plan

Described stack — not what this repository runs

Names below are a sketch. They are not completed integrations unless the technology section says Built with.

Next.js · TypeScript · Deterministic formulas with unit tests · Scenario rows in Postgres

Planning assumptions · Hiring plan · Monthly projection · Saved scenario

Separate app in gtm-revenue-os. Not embedded on this site. In-year new logos do not churn inside the planning year, so December matches the annual bridge. Gross retention above 100% is rejected.

Goals

  • Show required new ARR after retention and expansion.
  • Convert quota and attainment into productive ARR per ramped AE.
  • Turn the new-ARR residual into pipeline dollars from win rate, shifted back by the sales cycle.

Out of scope

  • A forecast of a real company.
  • Letting capacity or hiring rewrite GRR or expansion.
  • Using a language model to calculate the outputs.

Smallest version

One editable planning year. Assumptions, ARR bridge, capacity, ramp, pipeline, monthly and quarterly views, saved scenarios, and export to Markdown, CSV, or JSON.

Question that version tests: If required new ARR is already zero, does the plan stop recommending more AEs?

Metrics I would watch

These are not results unless the section above says they are on record.

  • Every major output recomputes from a named formula
  • Scenarios saved and compared
  • Hypothesis: the hiring date and the pipeline number come from the same bridge

A plan a person can recompute changes the hiring date and the pipeline number together. No claim that a team performed.

Tradeoffs

  • Straight-line monthly churn, so the year reconciles and seasonality is ignored.
  • Linear ramp. Real ramps are lumpy.
  • Expansion is a dollar input, so the model does not loop.
  • Win rate is the rate on opportunities created, not coverage on a live open-pipeline snapshot.

What I would build next

  • The operating plan can already copy AE count, quota, attainment, ramp, and ending target into this model. That copy changes planned capacity only.

Explore related work

Back to all projects