How to Price Freelance IT Work: Hourly vs Fixed Price
Practice4 minInnovialabs editorial team
In short
Hourly pricing suits vague or long-running work, a fixed price suits a clearly described scope; either way, break the work into small pieces, add a risk buffer and put in writing what the price includes.
Hourly or fixed price: the short answer
- Hourly — when the task is fuzzy, requirements will change or the work is ongoing (support, improvements, consulting).
- Fixed price — when the scope is clear and written down: a landing page from a finished design, a bot with a specific feature list.
The key rule: a price without a defined scope is a lottery. Whatever model you choose, you and the client must understand exactly what will be delivered in the same way.
Comparing the models
| Hourly | Fixed | |
|---|---|---|
| Risk of underestimating | On the client | On you |
| Budget clarity for the client | Lower | Higher |
| Flexibility with changes | High | Needs re-estimation |
| What you maintain | Time tracking and reports | A clear spec and milestones |
| Best for | Support, R&D, vague tasks | Typical projects with clear scope |
There are middle-ground options too: fixed price per phase (a paid discovery and prototype first, then an estimate for development) or a retainer — a fixed monthly block of hours for a regular client.
How to estimate scope
- Break the project into tasks of a few hours each: "authentication" is too big; "login form", "password reset" and "validation" are better.
- Count the invisible work: calls, messages, environment setup, deployment, testing, revisions, documentation. This is what usually eats the time.
- Estimate as a range: an optimistic and a pessimistic figure per task. A wide gap signals that the task needs clarifying.
- Compare with your history: track actual time on your projects — it is the best source for future estimates.
- Ask questions before quoting: integrations, number of user roles, content, who prepares texts and images.
A buffer for risk
An estimate without a buffer almost always turns out too low. The buffer is not padding; it is the price of uncertainty. Its size depends on:
- how detailed the requirements are;
- whether you have worked with this stack or API before;
- third-party dependencies (someone else's backend, access, approvals);
- how quickly the client responds and makes decisions.
The more unknowns, the bigger the buffer — or the stronger the case for hourly billing or a separate paid discovery phase.
Handling scope creep
Scope creep is when "small requests" gradually turn the project into a different one. How to protect yourself:
- Write down what is out of scope, not only what is in.
- Limit revision rounds in the contract.
- Answer each new request calmly and specifically: "Good idea; it was not part of the original scope, so I will estimate it separately."
- Keep extra tasks in a backlog and offer them as the next phase instead of doing them silently.
- Split payment by milestones so changes naturally go into the next one.
How to raise your rates
- Review your rate regularly, for example when starting a new project or at a set interval.
- Quote new clients the new rate straight away; give existing clients advance notice.
- Raise the price along with your value: specialisation, case studies with results, speed, reliable communication.
- Move from selling hours to selling outcomes: packages and fixed-scope products let you earn from your own efficiency.
Common mistakes
- Quoting a price in the first message without asking a single question.
- Undercutting to "get in" with a client — raising the price later is hard.
- Ignoring platform fees, bank fees and taxes.
- Agreeing to a fixed price on a vague spec.