A performance budget your team will actually hold
Lighthouse scores decay the moment the launch is over. A budget only works when it fails the build, not the vibes check.
Every site I hand over launches fast. The interesting question is whether it is still fast a year later, after four people who never met me have added things to it.
Scores are outcomes, budgets are constraints
"Keep Lighthouse above 90" is a wish. "The route bundle may not exceed 180KB and LCP may not exceed 2.0s on a throttled connection" is a constraint a CI job can enforce. Only one of those survives a busy sprint.
Put the budget where the work happens
The check belongs in the pull request, not in a monthly report. When a change pushes the bundle past the limit, the author sees it while they still remember what they did and why.
Choose the metrics your users feel
- LCP for whether the page looks ready
- INP for whether it responds when tapped
- CLS for whether it stops moving
Everything else is diagnostic detail. Three numbers people can remember beat twelve nobody checks.
Budget the images first
On almost every site I audit, the single biggest win is not code splitting or a lighter framework. It is that someone uploaded a 4000-pixel hero image straight from a camera. Fix the pipeline once and the problem stops recurring.
Demo agents work because nothing is at stake. Here is what changes when real users, real money and real edge cases show up.
How I scope fixed-price work without losing moneyFixed price is only dangerous when the scope is vague. The discovery call is where that gets solved — or doesn't.