Software Project Milestones and Acceptance Criteria: How to Structure a Build

Why milestones go wrong

Most milestone disputes come from the same three gaps: a milestone defined as a stage of work ("backend complete") rather than something the client can try, acceptance criteria that say "works as expected", and no agreement on how long the client has to test or what happens if they never reply. Fix those three before you approve a build and most of the rest takes care of itself. This guide uses a common shape: a customer mobile app plus a web admin dashboard, built by an outside team.

Rule 1: every milestone ends in working software

A milestone should finish with something you can open on a staging server or a TestFlight or Play test build and click through yourself. "Database design", "API development" and "UI design" are activities, not milestones; you cannot check them and you cannot tell whether they are half done. Slice the work vertically instead, so each milestone delivers a thin but complete flow from the screen to the database.

Discovery is worth paying for separately ($3k to $8k with us) because it turns a wish list into the scope the later milestones are measured against. If a vendor will not estimate milestones 1 to 5 until discovery is done, that is a good sign, not a delay.

Rule 2: write acceptance criteria as checks, not adjectives

Acceptance criteria are the list you will tick when the milestone is delivered. Each one should be something you can do yourself, with an outcome you can see. The given-when-then format keeps them honest:

Five to fifteen criteria per milestone is about right. Fewer means the milestone is vague; many more usually means it is too big. Add the non-functional ones that matter to you (devices and browsers, accessibility level, performance, languages) to the milestone where they first apply, not to a separate list nobody checks until launch.

Rule 3: agree the review window and what happens on silence

• Review window: five working days from the delivery note is common. The vendor sends a short note listing each criterion with how to test it and any known issues.
• Outcome: you either accept, or reject with a list of failed criteria. A rejection must point to a criterion; "I don't like it" is a change request, not a failure.
• Fix and re-test: the vendor fixes failed criteria at its own cost and re-submits; you re-test only those items, within three working days.
• Deemed acceptance: if you neither accept nor reject within the window, the milestone counts as accepted. Vendors ask for this so projects cannot stall; clients should make sure the window is long enough for them to test.
• Live use: if you put a milestone into production use, it counts as accepted for the parts in use.

Rule 4: separate defects from changes before work starts

A defect is software that fails an agreed criterion or breaks something that used to work; fixing it is the vendor's cost. A change is anything new or different from the agreed scope; it is estimated and approved before work starts. Write both definitions into the statement of work and agree a simple change process: a one-paragraph request, an estimate in hours and days, your written approval, then the work. Most fixed-price projects that go over budget did not lack a change process; they lacked the discipline to use it for small things.

Rule 5: tie money to accepted milestones

Whichever you choose, make the warranty explicit: how long after launch defects are fixed free (30 to 90 days is common), and what support costs after that. Our fixed price vs time and materials guide covers when each model fits, and ongoing support is priced on our maintenance and support page from $1,500 a month.

What you should get at each milestone

• A staging URL and test builds you can use, with test accounts for each role.
• A delivery note listing each acceptance criterion, how to test it, and known issues.
• The code in your repository, not the vendor's, with the commits for the milestone.
• A short demo call where the team walks you through the flow and you try it live.
• An updated plan: what is next, any risks, and any change requests waiting for your decision.

A worked example: booking app and admin dashboard

Say the scope is a customer app for booking appointments at a chain of studios, plus an admin dashboard for staff. A typical build with us runs four to six months for $50k upwards depending on features; a lean first version can sit inside our MVP range of $15k to $45k. Milestone 2 (the core flow) might carry these criteria: a customer can pick a studio, see available slots for the next 14 days, book and pay with a test card, receive an email and push confirmation, and cancel up to 24 hours before for a full refund; staff see the booking in the admin within 5 seconds; a slot cannot be double-booked when two customers tap at the same time. Each line is something you can check on a phone in under five minutes.

If you are taking over a project that is already in trouble, start with a code and delivery audit before you write new milestones; our codebase takeover checklist covers what to look at first. And for a budget before any of this, the app development cost calculator gives an instant range by feature.

Sources

• Cucumber: Gherkin reference (given, when, then): https://cucumber.io/docs/gherkin/reference/
• The Scrum Guide (2020), Definition of Done and Increment: https://scrumguides.org/scrum-guide.html
• ISO/IEC 25010:2023 product quality model, for non-functional criteria such as performance, security and usability: https://www.iso.org/standard/78176.html
• Statement of work template and PRD template