Paying by milestone only protects you if you actually check the milestone. Many owners click around for five minutes, see that the screens look nice, and approve. Three milestones later, they find that something basic never worked.
You do not need to read code to review a milestone properly. You need a routine.
Key Takeaways
- Review against the written acceptance criteria, not against how the screens look.
- Test like your least patient customer: wrong inputs, phone screens, going back mid-way.
- Write feedback that someone else can reproduce: what you did, what you expected, what happened.
- Separate bugs (it does not do what was agreed) from changes (you want something new).
Before You Start
Get three things from your builder:
1. The acceptance criteria for this milestone, in writing. For example: "A customer can book an open slot. A booked slot cannot be booked again. The customer gets a confirmation email."
2. A test link and test logins for each kind of user.
3. Your review window. On our software factory projects, you have five business days per milestone, and you only pay once you accept it.
Block time in your calendar. A half day for a typical milestone is better than ten scattered minutes.
The Routine
Step 1: The happy path. Do each thing in the criteria exactly as a normal user would. Book a slot. Pay. Check the email. Tick each criterion as it passes.
Step 2: The unhappy path. Now be difficult:
- Leave required fields empty.
- Type a phone number with letters in it.
- Press the back button halfway through paying.
- Try to book the slot you just booked.
- Log in as the wrong kind of user and try to see things you should not.
Step 3: The phone test. Repeat the main flow on your own phone. Many customers will only ever use the app there.
Step 4: The real-data test. Use a real example from your business: your actual prices, a real customer name with an accent, a long address. Made-up test data hides problems.
Step 5: The second person. Ask someone who has never seen the app to do one task without help. Watch silently. Where they hesitate is where customers will too.
Writing Feedback That Gets Fixed
A good bug report has four parts:
| Part | Example |
|---|---|
| Where | Booking page, on iPhone |
| What I did | Picked Tuesday 10am, pressed back during payment, then booked again |
| What I expected | One booking |
| What happened | Two bookings for the same slot |
Add a screenshot or a short screen recording. "Booking is broken" gets a reply asking for details. The report above gets fixed.
Bugs vs Changes
This distinction decides who pays.
- Bug: the app does not do what the acceptance criteria say. The builder fixes it at no extra cost, and on our projects you do not pay for the milestone until it passes.
- Change: the app does what was agreed, but you now want something different. That is a new request, priced and approved separately. See what is a change order in software development.
Mark each item in your feedback as one or the other. It keeps the conversation friendly, and it keeps the budget honest.
A Concrete Version
A salon booking app, milestone two: "Customers can book and pay a deposit."
The owner blocks Thursday afternoon.
- Happy path: booking and deposit work, confirmation email arrives. Pass.
- Unhappy path: pressing back during payment creates a second booking. Bug.
- Phone test: the time picker is hard to tap on a small screen. Bug, because the criteria say "works on mobile."
- Real data: a stylist name with an accent shows as garbled characters in the email. Bug.
- Second person: the owner's sister cannot find the cancellation policy. Not in the criteria, so this is a change, and a cheap one.
The owner sends one message with three bugs and one change request. The builder fixes the bugs, the owner retests on Monday, accepts the milestone, and pays. The change is priced at a small amount and added to milestone three.
The Honest Counterpoint
A thorough review costs time, and if the acceptance criteria were vague, even a careful review turns into a debate. The routine above works best when the criteria were written well at the start. If yours are thin, fix that before the next milestone rather than arguing about this one. Also, no amount of owner testing catches everything, especially security problems. For apps that handle payments or personal data, a short review by a second developer before launch is worth the money. See how to audit code a contractor wrote.
Frequently Asked Questions
What if I find a problem after I approved the milestone?
Report it. If it breaks the agreed criteria, a good builder fixes it, and a warranty period often covers it after launch. Our software warranty guide explains what is usually covered.
Can I approve part of a milestone?
It depends on your contract. It is usually cleaner to list the failing items, let them be fixed, and approve the whole milestone together.
How many rounds of fixes are normal?
One round is common. Repeated rounds on the same issue suggest the criteria are unclear or the work is rushed.
What if the builder says my bug is a change?
Go back to the written criteria. Whatever the document says decides it. That is why the criteria matter so much. See how to pay for custom software in milestones.
The Bottom Line
Test against the criteria, be a difficult customer, write reproducible feedback, and sort bugs from changes. If you are still planning a build and want the criteria written clearly from the start, the honest read ends with a spec any developer can quote and test against.
Roberto Espinoza is CEO of Ruzora, which builds custom software for business owners at a fixed price and places pre-vetted senior LATAM engineers with US teams. Get a free honest read on your idea.
