Best for
- Products that get slower every sprint, nobody deciding it
- Making speed a reviewable number instead of a feeling
- Stopping the next regression at the pull request, not the complaint
What you give it
- Your product, its current numbers (or access to measure them), and where speed matters most
What you get back
- Budgets per surface: the key pages and operations, each with its limit and the reasoning
- The measurement setup: where numbers come from, lab and field, so the budget is checkable
- Enforcement wiring: the pipeline check that fails when a change blows the budget
How it works
- Measures current reality first — budgets set from fantasy get ignored by Friday.
- Budgets by consequence: the surfaces where slowness costs (conversion, task completion, rage) get the tight numbers.
- Sets each limit with its reasoning: user expectation, business evidence, device reality — so the number survives debate.
- Wires enforcement where change happens: the pipeline compares against budget and fails loudly, with the regression named.
Example
You: Our app keeps getting slower. Set up budgets so it stops.
Result: Budgets for the eight surfaces that matter: search under 300ms at p95, the dashboard interactive under 2.5s on the mid-range device profile, the export job under 30s at the 95th-percentile data size. Current reality measured first (two surfaces already over — fix list attached), the pipeline check added (a PR that pushes search past budget now fails with the number in the message), and the monthly field-data review scheduled.
Limits — please read
- Budgets manage the product's own weight; third-party scripts need their own line item and policy — it will insist.
- Lab numbers and field numbers differ; both are tracked, each for its job (regression-catching vs truth).
- A budget is a decision; when a feature genuinely needs more, the budget changes consciously — the process includes that path.