The pricing model decides who carries the risk when a project takes longer than planned. Fixed price puts it on the vendor. Hourly puts it on you. Neither is wrong, but they suit different projects.
Short answer: choose fixed price when you can describe what you want before work starts, and hourly when you cannot. A first version with a known list of screens and flows belongs on a fixed price. Research-heavy work, an existing codebase nobody understands yet, or a product that changes every week belongs on time and materials.
Fixed price is not automatically safer. A vendor who carries the risk will protect the margin, either by padding the quote or by reading the scope narrowly when you ask for something extra. Hourly is not automatically a blank cheque either. With a weekly cap, a visible backlog and the right to stop at any time, it can be the more honest arrangement. What matters is whether the scope is known. If it is, fix the price. If it is not, no contract can make it known, and a fixed price only hides the uncertainty until the first change request.
| Fixed price | Time and materials | Monthly retainer | |
|---|---|---|---|
| Budget certainty | High, agreed upfront | Low unless capped | Known per month, open-ended overall |
| Flexibility to change scope | Low, changes are re-quoted | High, reprioritise any week | High within team capacity |
| Who carries overrun risk | Mostly the vendor | Mostly the client | Shared, reviewed monthly |
| Effort needed before starting | Detailed written scope | A direction and a backlog | A roadmap and priorities |
| Vendor incentive | Finish efficiently within scope | Keep the work going | Keep the relationship going |
| Your management time | Lower, sign off milestones | Higher, review hours weekly | Moderate, steer priorities |
| Common failure | Disputes over what was included | Bill grows without a finish line | Paying for idle capacity |
| Best suited to | MVPs, websites, defined builds | Discovery, rescue, research work | Ongoing product after launch |
If you can list the screens, the user roles and the integrations, a fixed price gives you a number to plan around and a vendor with a reason to finish.
A founder spending savings or a fixed grant needs certainty more than flexibility. Agree the scope, agree the price and hold changes for phase two.
Untangling an inherited codebase or exploring whether something is technically possible cannot be priced honestly in advance. Pay for time, with a cap.
Some founders learn by seeing. If you expect to redirect the work every week, a fixed price will turn every idea into a negotiation. Hourly suits you better.
After launch the work is a steady stream of fixes and improvements. A monthly plan fits that better than a series of small fixed quotes.
Pay hourly for a short discovery phase that produces a written scope. Then fix the price for the build. You get certainty without guessing.
A one-page brief with a fixed price is a dispute waiting to happen. Both sides imagined a different product, and the contract cannot say who was right.
Time and materials needs a weekly or monthly ceiling and a backlog you can see. Without them you cannot tell slow progress from a growing scope.
A large deposit leaves you with no bargaining power. Tie each payment to something you can open and test, so the money follows the work.
New ideas during a fixed-price build have a cost. Log them, price them and decide. Slipping them in is how deadlines and relationships both break.
It can be. The vendor is carrying the risk of overrun and will price that in. In return you get a known total. For a well-defined project the premium is small and worth paying. For an unclear one the premium is large, or the vendor recovers it later through change requests.
Under a fixed price, the change is written up, priced and either added or parked for the next phase. Under hourly, you reorder the backlog and carry on. Neither is free. The fixed-price route makes the cost visible at the moment you decide, which many founders prefer.
Detailed enough that a stranger could tell whether it was delivered. That means user roles, the main flows, the integrations, the platforms and what is excluded. Exclusions matter as much as inclusions. If writing that list feels impossible, the project is not ready for a fixed price yet.
The project is divided into stages, each with something you can see. You get a staging link by day 3 and pay as milestones are delivered and accepted. After final delivery there is a 14-day bug-fix window. Ongoing maintenance beyond that is a separate monthly plan, not part of the build price.
Yes, and it should. Ask for a weekly or monthly cap, a shared backlog and a timesheet you can read. Review it every week. With those controls, time and materials is a fair model for work that cannot be scoped in advance, such as research or rescuing unfamiliar code.
It depends on the stage. Early on, most want to see a fixed cost to reach a launchable version, because it makes the runway easy to reason about. Once the product is live and earning, a predictable monthly spend on a team is normal. Ask yours before you sign.
What drives the price of a web app and where quotes differ.
The cost factors behind a mobile build, feature by feature.
Realistic timelines and what stretches them.