How can you tell whether a software build is making real progress?

A software build can look busy for months without giving the buyer much to judge. Tickets close, hours accumulate, and a weekly report stays green, but that still does not tell you whether the business is any closer to software it can use.

You can judge that without reading code, by asking for progress to arrive as working behavior that your team can see, question, and accept.

A milestone should change what you can do

Many project plans call a phase complete when an internal activity ends, and a status report might say design is done, the database is set up, or an integration is in progress. Those facts may matter to the developers, but they are weak evidence for the buyer.

A useful milestone ends with a behavior you can observe. For example, a lead can be entered once and assigned to the right person, a contract carries the correct language for a real job, or a payment request reaches accounting with the right amount and customer. The team can try the behavior with representative examples and decide whether it works.

This makes acceptance concrete, because what you approve is a result that the business understands.

For the Oasis Pavers & Pools build, the fixed-price work was split into six milestones after kickoff. Each milestone had written deliverables, and Oasis was invoiced only after owner Brian Godden saw and accepted them. That structure gave both sides a shared way to tell the difference between activity and progress, though it did not make the build easy.

What to test before you accept a milestone

The person accepting a milestone should know what to test and what happens if it fails. This works best when the acceptance examples are written before development begins.

Use ordinary cases from the business, plus a few cases that usually go wrong. If a contract changes by municipality and flood zone, test the less common combinations too. If a cancellation should stay in the record but leave a performance report, test that rule directly. If an invoice begins in one system and ends in another, follow it all the way through.

When you test a milestone, you are checking whether the named behavior works well enough to build the next part on top of it, even if some details are still unfinished.

Write down open limits when you accept. A milestone can be accepted with a known follow-up if everyone understands the boundary, because a visible limit can be planned for.

Good milestones make change less expensive

Ten days after the Oasis kickoff, the team decided the first version should run the office and leave jobsite scheduling out. Because the work was divided into visible pieces, the unused hours could move into parts the office needed more.

That is one sign of a healthy build. New understanding changes the plan while the cost of changing it is still reasonable.

The opposite pattern is familiar. The buyer sees the whole system near the end, discovers that a central assumption was wrong, and hears that changing it requires a new contract. Small demonstrations are useful because they bring those decisions forward.

Milestones should also expose bad news

A trustworthy progress system brings problems into the open and makes each miss specific.

Byte Bot built a permit-tracking feature for Oasis that the team did not want. Two weeks of work were discarded at our cost because the scoping mistake was ours. The QuickBooks connection also took longer than planned. Since every invoice and payment ran through that connection, the office could not safely launch without it.

The contract named June 29 as the launch date. Oasis went live on August 10, six weeks late. No milestone format can undo that delay, but this one let everyone see what remained, why it mattered, and who carried the cost.

Before launch, the Oasis team spent three half-days in training and two days trying to break the system. When Brian did not have confidence on the Friday before launch, we worked through the remaining concerns with him and agreed together to delay. Cameron, the lead engineer on the build, sent a line-by-line account of every open item. The team closed about sixty items over the next three days and reran the migration until it matched the old system one to one.

That was uncomfortable progress, and the decision to delay was tied to working evidence.

Ask for four things every time

At each milestone, record the working behavior, examples tried, known limits, and the decision needed. A short acceptance note gives everyone the same thing to review:

These four parts keep the conversation at the level where you can contribute. They also make it harder for either side to confuse hours spent with value delivered.

The finished system still matters, of course. Oasis began using its new office system on August 10, and its leads, estimates, contracts, change orders, and payment requests now move through it. Reporting was still being refined after launch, so the story was not finished on go-live day.