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. None of that answers the question you actually have: is the business getting closer to software it can use?

You do not need to read code to answer that question. You need 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. Design is done. The database is set up. 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. A lead can be entered once and assigned to the right person. A contract carries the correct language for a real job. 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. You are not approving effort or a slide deck. You are accepting a result that the business understands.

For the Oasis Pavers and 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 did not make the build easy. It gave both sides a shared way to tell the difference between activity and progress.

Acceptance is a decision, not a ceremony

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 more than the common combination. 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.

The question is not whether every possible detail has been finished. The question is whether the named behavior works well enough to build the next part on top of it.

Write down open limits when you accept. A milestone can be accepted with a known follow-up if everyone understands the boundary. Hidden uncertainty is the danger. A visible limit can be planned.

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 does not stay green by hiding problems. It makes misses 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 make that delay disappear. The value of the format was that everyone could 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, but it was real. The decision to delay was tied to working evidence rather than optimism.

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.

That is the larger point. Real progress is not a perfect status report. It is a sequence of working, accepted changes, with the misses and limits visible enough for you to make the next decision.