How can a client reduce the risk of an unfinished software project?
The strongest control is to test the largest uncertainty with a small initial discovery, pay against runnable and transferable increments, keep continuous access to code, data, and accounts, and define conditions to continue, correct, reduce, or stop at every stage. A large advance, document-based progress, or a retained final payment cannot control the risk alone.
Projects rarely fail on one day. Objectives lack a baseline, scope accumulates, a critical interface is postponed, client decisions stall while cost continues, demonstrations show pages without the real business path, and payments move ahead of usable results. A good mechanism exposes these deviations while the time and money at risk remain limited.
When agreeing deliverables, handover, and ownership boundaries, also compare Can our system still be maintained if the supplier closes or its core team disbands?; the linked guidance adds context that should be considered in the same decision.
| Investment model | Payment buys | Failure becomes visible | Assessment |
|---|---|---|---|
| Large advance, final acceptance | Promise, schedule, and eventual whole | Near the end | Avoid for high uncertainty |
| Payments by design/development/test phase | Documents and discipline-specific effort | At each functional phase boundary | Usable only with end-to-end increments |
| Discovery, then runnable increments | Retired risk plus demonstrable, transferable versions | Every agreed cycle or milestone | Preferred |
Start with a one-page baseline: target users, current process, business outcome, first-release exclusions, budget ceiling, immovable date, and owners for data and interfaces. If success depends on a third-party API, device protocol, algorithm, historical data, platform review, or capacity, Wavesteam should test that dependency with real samples before building peripheral screens.
A milestone should describe an observable result, not “frontend 80% complete.” For example, an authorized user completes order, payment callback, refund, and reconciliation in the test environment, while the client receives the matching repository commit, deployable artifact, schema change, test report, and known-issue list. Payment follows acceptance.
Track end-to-end cases planned and passed, unresolved severe defects, and paid value against accepted budget. Watch scope growth, blocker age, rework, and repeated delivery variance. Code lines and online hours do not measure business value. When a severe-error threshold is exceeded, a core dependency fails, client data remains unavailable, or forecast cost exceeds the ceiling, trigger a written review with only four outcomes: continue, time-boxed correction, scope reduction, or stop.
Stopping terms should explain settlement for accepted and unstarted work, repository and data export, account transfer, confidentiality, and transition support rates. The client also names empowered business and asset owners and supplies agreed samples, access, and decisions on time; supplier delay and client blockage must both remain visible.
Wavesteam turns this mechanism into risk-test recommendations, runnable milestone versions, synchronized assets, budget variance, and a documented proceed/correct/stop decision. Our transparent delivery standard is a public working principle, not a guarantee that no project can fail. The evidence is the project baseline, live repository, demonstrations, acceptance records, and tested exit path.