How to price fixed-price milestones
Price a fixed-price milestone by estimating the hours for one clearly defined result, multiplying by your hourly rate, adding a buffer for uncertainty, and writing down exactly what the client gets. Keep the scope small enough that the estimate is honest.
Last updated:
Start with your hourly rate, not with a guess
A fixed price is an hourly rate in disguise. Every developer on ErdiBuilds sets an hourly rate on the profile, and that number is the base of every milestone price. If you do not trust your rate, your fixed prices will not be right either. Pick a rate that covers your time, your taxes, your tools and the weeks without paid work.
Then ask one question per milestone: how many hours will this result take me, if I work calmly and nothing surprising happens? Write that number down before you think about the price.
A simple method in five steps
- Name the result. One milestone should end in something a client can open, click or test, not in a vague phase like "backend work".
- List the tasks behind the result and give each task an estimate in hours. Include design review, tests, deployment and the time to explain the delivery.
- Add the hours together and add a buffer for the unknown. A small, well understood task needs a small buffer. Work with a new API or unclear requirements needs a larger one.
- Multiply the total by your hourly rate. The result is the fixed price.
- Check the price against the milestone rules of the platform, and split the work if it does not fit.
Fit the work into the milestone rules
On ErdiBuilds a proposal is a list of milestones. Each one has a fixed price, estimated hours and a deliverables text of at least 100 characters, plus an optional checklist. Milestones are from 50 to 2,000 each in your project currency. Each milestone is funded before work starts and runs 1, 2, 3, 4, 6 or 8 weeks.
These limits help you. A short milestone with a capped amount forces you to cut the work into pieces you can actually estimate. A big unknown stays a big unknown when it sits in one number, but it shrinks when you split it into a first small milestone that answers the open question.
Use the first milestone to reduce risk. A small, well defined first step lets both sides learn how they work together before the larger pieces start.
Where buffer belongs
Buffer is not padding. It pays for things you cannot see yet: a third-party API that behaves differently from its docs, a design that changes once, a test that finds a bug in week two.
| Topic | What it looks like | What to do |
|---|---|---|
| Known work | You have built this exact thing before | Small buffer, price close to the raw estimate |
| Partly new | A familiar stack with one new integration | Medium buffer, name the integration in the deliverables |
| Unclear | The client cannot yet say what the result should look like | Do not price it. Make a small discovery milestone first |
Known work
- What it looks like
- You have built this exact thing before
- What to do
- Small buffer, price close to the raw estimate
Partly new
- What it looks like
- A familiar stack with one new integration
- What to do
- Medium buffer, name the integration in the deliverables
Unclear
- What it looks like
- The client cannot yet say what the result should look like
- What to do
- Do not price it. Make a small discovery milestone first
Write deliverables that protect the price
The deliverables text is where a fixed price is won or lost. The client approves against it, so it defines what "done" means. Say what works, where it runs and what is not included. A checklist turns the text into items the client can tick off during review.
- Describe results, not effort: "Users can sign up, log in and reset a password" beats "build authentication".
- Name what is out of scope. If something else comes up, it becomes a new milestone, not an unpaid extra.
- Mention the environment: staging link, repository access, store build.
- Keep each milestone to one theme, so the review is quick.
Common mistakes
- Pricing only the coding hours and forgetting review rounds, deployment and communication.
- Matching a price to the client budget instead of the work. A price that loses money makes the whole project worse.
- Putting several unknowns into one milestone.
- Leaving the deliverables vague so a fair review turns into a debate.
Every project is different, so this guide gives you a method and not a price list. Your own history of estimates against real hours is the best data you have. Track it and your next milestone price gets better.
Frequently asked questions
Why are milestones fixed price if I have an hourly rate?
Your hourly rate is the base for your estimate, and the milestone price is the result of that estimate. Clients get a clear amount to fund and approve, and you get paid for a defined result.
Link to this answerHow big should a milestone be?
Small enough that you can estimate it honestly, and short enough to fit the platform rules. Milestones are from 50 to 2,000 each in your project currency. Each milestone is funded before work starts and runs 1, 2, 3, 4, 6 or 8 weeks.
Link to this answerWhat if my estimate turns out too low?
Fixed price means you carry that risk for the milestone. Reduce it with a buffer, a precise deliverables text and a small first milestone. Out of scope changes become new milestones.
Link to this answerWhat if the client wants more than agreed?
Point to the deliverables text. Anything beyond it is added as a new milestone with its own price, so both sides stay clear.
Link to this answerDo I have to show estimated hours?
Yes. Each milestone in a proposal has a fixed price and estimated hours. The hours show how you reached the price.
Link to this answerRelated pages
- How to Write a Proposal That WinsHow developers can write a proposal clients choose: read the brief, answer the real problem, split the work into clear milestones and show relevant proof.
- How to Split a Project Into MilestonesSplit a software project into milestones that each deliver something you can see and approve. Rules, an example plan and a free planner tool.
- Fixed Price vs Hourly for Software ProjectsFixed price suits clear scopes, hourly suits open ones. See how each model handles risk, change and control, and when milestones give you the best of both.
- Free milestone planner for your projectTurn your project into an editable plan of milestones with lengths that fit the rules. Runs in your browser, stores nothing and estimates no prices.
- For developersHow independent developers join and get hired.
- Guides for your projectPlain guides on planning, scoping and paying for apps, SaaS, websites and games, written for people who are not developers.