Per Hour vs Per Project: Pricing Models Explained
Per hour pricing for software development charges a fixed rate for each hour of work regardless of output. The client bears the scope and time risk: if requirements change or estimation was wrong, the hours increase and the total cost increases. Per project pricing charges a fixed amount for a defined scope. The developer bears the scope and time risk: if the project takes longer than estimated, the developer absorbs the cost overrun. Each model has appropriate and inappropriate use cases.
What you need to know
- Hourly pricing allocates scope risk to the client. Project pricing allocates scope risk to the developer. Choose based on who is better positioned to carry that risk given the project's characteristics.
- Project pricing requires a precise scope document before work begins. Vague scope in a fixed price contract produces disputes about whether specific work is in scope.
- Hourly pricing does not mean unlimited hours. Estimated hours and a budget ceiling should be specified in any hourly engagement to prevent open ended cost accumulation.
- Change orders are the mechanism that makes project pricing work for evolving requirements. An engagement without a documented change order process will have disputes about scope.
- For exploratory work, or work where requirements are still unclear, hourly pricing is the honest model. For well defined, stable scope work, project pricing benefits the client.
The core argument
The hourly versus project pricing decision is ultimately a question of who knows more: the client about what they want, or the developer about how long it will take. When both are uncertain, hourly pricing is the honest model because it charges for actual work rather than for an estimate. When the scope is clear and stable, project pricing benefits the client because it caps the total cost and aligns the developer's incentive with efficiency.
The most common failure mode for project priced engagements is scope ambiguity. A project scoped as "build a user management system" contains enough ambiguity to span $10,000 and $100,000 of development work depending on what "user management" means. Clients who accept a fixed price proposal for a vaguely scoped project are not getting a budget guarantee; they are getting a contract dispute waiting to happen. Every project priced engagement should have a scope document that describes what is explicitly included and what is explicitly excluded. The exclusions are as important as the inclusions.
In my experience working on both sides of this pricing decision, the clients who get the most value from project pricing are the ones who invest time in writing a detailed scope before soliciting proposals. A client who can describe the exact screens, the exact user flows, the exact integration points, and the exact acceptance criteria for each feature gives developers enough information to estimate accurately. That client gets competitive fixed price bids that can be compared and evaluated. A client who cannot articulate the scope before starting will either pay for hourly exploration or pay for the scope ambiguity in a fixed price dispute.
Common mistakes
Accepting a project priced proposal without a written scope document. A verbal or informal description of the project is not a scope document. If the developer submits a fixed price proposal without a detailed scope attachment, ask for one. The scope document is the legal definition of what is included in the fixed price.
Not specifying an estimated hours ceiling in hourly engagements. An hourly engagement with no ceiling is an open ended cost commitment. Specify the estimated hours for the engagement and a communication requirement when hours exceed 80 percent of the estimate. This preserves flexibility while preventing surprises.
Using project pricing for work that includes research or exploration. An engagement that starts with "we need to figure out the best approach" and then implements it is two phases: exploration (where hours are unknown) and implementation (where hours are estimable). Price exploration hourly and implementation on a project or time and materials basis after the approach is decided.
Not including revision rounds in project priced design or UI work. A fixed price engagement for design or front end work that does not specify how many revision rounds are included will either produce a dispute about revisions or an open ended revision process that extends the project indefinitely. Specify the number of revision rounds in the contract.
Assuming hourly developers are slower because they have no efficiency incentive. Good hourly developers compete on reputation and repeat business; a reputation for running up hours damages both. The incentive to be efficient exists for hourly developers; it comes from client relationships and referrals rather than from contract structure. The better predictor of efficiency is the developer's track record, not the pricing model.
Where to start
For a new engagement: assess the scope clarity. Can you write a detailed description of every feature and acceptance criteria before the work starts? If yes, project pricing protects your budget. If no, hourly pricing with an estimated ceiling is more honest.
For project pricing: write the scope document first. Before soliciting proposals, write the scope. Include: exact features, user flows for each feature, technical integrations, what is explicitly out of scope, and acceptance criteria. Use this document to solicit multiple proposals that can be compared on an equal basis.
For hourly pricing: define the budget ceiling and reporting cadence. Specify the maximum hours authorized without explicit approval, how often time logs are shared, and what happens when the estimate is exceeded. These terms prevent open ended billing while preserving the flexibility of hourly engagement.
- Hiring Developers: What Agencies Will Not Tell You
- MVP Pricing Models: How to Charge for Something That Is Not Done Yet
FAQ
Frequently asked
- What are the advantages of hourly pricing for a client?
- What are the advantages of project pricing for a client?
- Why do developers prefer hourly pricing?
- How does project pricing work when requirements change mid project?
- What is a retainer and how does it differ from hourly or project pricing?
Author
The reason I write these
I write these because the writing is the proof. Yashveer Singh, founder of Yashveer Labs. The systems I build are not theoretical. They are running right now, serving real users, generating real revenue. That is the bar I hold this writing to. If you want to hire someone who can match that bar, I am the call.