How I scope fixed-price work without losing money
Fixed price is only dangerous when the scope is vague. The discovery call is where that gets solved — or doesn't.
Clients like fixed prices because they can plan around them. Developers avoid them because scope creep turns a good month into an unpaid one. Both positions are reasonable; the fix is in how the scope gets written.
The discovery call has one job
Not to impress the client, and not to sketch a solution. Its job is to surface the constraints that would change the estimate — the legacy system nobody mentioned, the compliance review, the stakeholder who has not agreed to any of this yet.
Write the scope as a list of things that are not included
Everyone reads that list. Nobody reads the inclusions carefully, because they assume their idea is in there. An explicit exclusions list turns a future argument into a two-line email today.
Price the risk you are absorbing
A fixed price is insurance the client is buying from you. If the requirements are crisp, that insurance is cheap. If half the answers are "we'll figure that out later", it is expensive — and saying so out loud usually makes the answers appear.
Change requests are normal, not a betrayal
Scope will change; it always does. Having a stated rate and a one-page change process means the conversation is administrative rather than emotional.
Demo agents work because nothing is at stake. Here is what changes when real users, real money and real edge cases show up.
A performance budget your team will actually holdLighthouse scores decay the moment the launch is over. A budget only works when it fails the build, not the vibes check.