ourly billing sounds fair until you're the one paying it. The incentive runs backwards: the studio gets paid more the longer the project takes, and you find out what something actually cost only after it's already been built. We quote a fixed number for a fixed scope before we start, because the alternative asks you to trust a stranger's time sheet instead of trusting a specific, written description of what you're getting.
Thepriceonlymovesifthescopemoves—andthescopeisadocument,notafeeling.
A fixed price is only honest if the scoping was thorough. We spend real time before quoting anything — what screens exist, what the data model looks like, which parts are genuinely uncertain versus just undecided. If we can't scope something with confidence (a novel technical risk, an integration we've never touched), we say so and price that piece separately as a short, capped discovery phase, rather than quietly padding the main number to cover our own uncertainty.
Scope changes on almost every real project — that's normal, not a failure of planning. When it happens, we price the addition on its own, you approve it before we start, and the original number never quietly grows to absorb it. You always know, at any point, exactly what the current total is and why.
The tradeoff is on us, not you. If we underestimate something inside the agreed scope, that's our error to absorb, not a renegotiation. Fixed price only means something if it's actually fixed on the side that got it wrong.
A fixed number is useful only when the work behind it is inspectable. The proposal should describe the pages, screens, integrations, content responsibilities, supported devices, migration work, testing, deployment, and acceptance criteria included in the price. It should also list exclusions. A short quote with a confident total can be less certain than an hourly estimate if nobody can tell what completion means.
- Deliverables: the pages, features, platforms, and environments that will exist at handover.
- Assumptions: what the client supplies, including content, access, approvals, and third-party accounts.
- Dependencies: features that require authentication, payments, data storage, integrations, or another system to be available first.
- Acceptance: how each part will be reviewed and what evidence shows that it is complete.
- Change control: how new requests affect price and schedule before the extra work begins.
The estimate should connect those items to milestones. A deposit reserves capacity; later payments should correspond to visible progress or accepted stages. If the whole balance becomes due merely because a date arrived, the payment schedule is not measuring delivery.
Discovery, legacy-system rescue, and experimental product work may contain too many unknowns for an honest fixed build price. The responsible answer is not to invent certainty. It is to fix the price of a smaller discovery phase, identify the unknowns, and quote the implementation once the evidence exists. Hourly work can also be appropriate when priorities are expected to change continuously, provided the buyer receives frequent reporting, a spending limit, and the ability to stop.
Ask every supplier what would make the quoted number change. A credible answer names specific assumptions and a written approval process. A vague answer such as anything outside scope leaves the most important term undefined.