# 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. Canonical: https://erdibuilds.app/guides/how-to-price-fixed-price-milestones Last updated: 2026-11-06 (November 6, 2026) ## 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 1. Name the result. One milestone should end in something a client can open, click or test, not in a vague phase like "backend work". 2. 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. 3. 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. 4. Multiply the total by your hourly rate. The result is the fixed price. 5. 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 (A service from another company that your software talks to, like a payment or maps service) that behaves differently from its docs, a design that changes once, a test that finds a bug in week two. **How much uncertainty belongs in the price** | | 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 | ## 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 (The place where the code of a project is stored and versioned, for example on GitHub) 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. ### How 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. ### What 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. ### What 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. ### Do 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. ## Related - [How to Write a Proposal That Wins](https://erdibuilds.app/guides/how-to-write-a-proposal-that-wins): How 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 Milestones](https://erdibuilds.app/guides/how-to-split-a-project-into-milestones): Split 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 Projects](https://erdibuilds.app/guides/fixed-price-vs-hourly): Fixed 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 project](https://erdibuilds.app/tools/milestone-planner): Turn 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 developers](https://erdibuilds.app/developers): How independent developers join and get hired. - [Guides for your project](https://erdibuilds.app/guides): Plain guides on planning, scoping and paying for apps, SaaS, websites and games, written for people who are not developers.