Key takeaways: Billing models are incentive machines. Hourly puts estimation risk on you; a whole-project fixed bid rewards corner-cutting at the end; milestones settle the risk per deliverable. A milestone here means a usable deliverable, written acceptance criteria, and a fixed price, invoiced only after approval. The model costs us real money in two specific places. We think it's worth it anyway.
Every Billing Model Is an Incentive Machine
Before comparing rates, look at what each model rewards.
Hourly (time and materials): the meter runs whether the work goes well or badly, so estimation risk sits entirely with you. An overrun is billable. Nobody at an hourly shop has to be acting in bad faith for this to go wrong; the incentive just points away from finishing.
Whole-project fixed bid: one number for the entire build, so the risk moves to the vendor. That sounds better until the estimate runs out at week nine. After that, the remaining work gets done as cheaply as possible and every change request turns into a contract argument.
Milestone-based: the project is cut into deliverables, each with its own fixed price, and payment follows approval of each one. The risk doesn't disappear. It just gets settled every couple of weeks instead of piling up for one fight at the end.
What a Milestone Actually Is Here
The word gets abused, so here's our operating definition. At Notchip a milestone is:
- A deliverable you can use — a build on your device or a preview URL you can click through, never a status report or a percentage.
- Acceptance criteria written before the build starts — what "done" means, agreed in writing while it's still cheap to disagree.
- A fixed price — set when the criteria are set, unchanged by how long the work actually takes us.
- Invoiced after approval — you test it against the criteria, approve it, then pay. If it isn't delivered and approved, we don't get paid.
Two standing rules sit around that: the repository is yours from day one, and any milestone can be the last one. There's no lock-in clause to negotiate your way out of.
When a Milestone Comes Back Half-Wrong
The interesting case is the milestone that comes back not quite right. There are two versions of it, and they have different owners:
- The criteria were met but ambiguous — the spec said "export the invoice" and didn't say the export needed to work offline. That ambiguity is our fault: we wrote the criteria, so the rework is ours, absorbed before the invoice goes out.
- You changed your mind — the export works as specified, but seeing it made you want something different. That's not a defect; it's a new milestone, priced and approved before it's built.
What decides between the two is the written criteria, which is why they get written first. The same logic covers overruns generally: our estimation mistakes land on us.
The Two Places This Model Hurts Us
Nobody who bills this way talks about the downside, so here it is.
1. The scoping is unpaid, and it's real work. You can't write honest acceptance criteria without actually scoping the product: decomposing features, finding the risky parts, pricing each milestone. All of that happens before the first invoice exists, and a prospect can take the plan and walk. Some do. We've accepted that as the cost of never billing for vague work.
2. Ambiguity always lands on us. Every under-specified criterion turns into rework we absorb, which makes us slower to promise things and pickier about fuzzy projects than an hourly shop needs to be. In scoping calls this shows up as a lot of questions. Founders who want a quick "yes, we can do everything" tend to find it frustrating, and honestly that filtering is part of why the model works.
Why It's Still Worth It
Your side of the case is straightforward: predictable spend, usable software every couple of weeks, and an exit at every milestone instead of a sunk-cost situation.
Our side is less obvious. The model forces scoping discipline we would probably skip under deadline pressure, and it selects for clients who care about deliverables, which are the projects that actually ship. The MVP budget bands and the FieldDojo cost teardown both come out of that same discipline. A milestone quote is just the teardown's line items with acceptance criteria attached.
What We Ask in Return
The model has obligations on both sides. From you it needs timely milestone reviews (an unreviewed build stalls the whole train), one person with the authority to approve, and straight answers when we ask which of two things matters more. Without those three things the whole model starts to wobble.
If You're Comparing Engagement Models
Ask any agency you're evaluating three things: what exactly triggers an invoice, who pays for an overrun, and what happens if you leave after milestone two. The answers tell you where the risk actually sits, whatever the model is called. Ours are all above. If that allocation suits your project, start the conversation.