A delivery date is easy to write down and hard to believe, and the disbelief is well earned. Most buyers of software have been told a date, watched it move, and then been given a reason for the move that was true and also, from where they sat, not their problem.
So this article describes the steps instead of a date: what exists at the end of each one, what has to be true for the next one to start, where the work goes wrong, and what happens when it does. The scope is one workflow: one process, with a defined beginning and a defined end, running against systems that already exist. Most of the speed comes from that boundary and from releasing each verified change at once, not held for a milestone.
1. A Written Specification
The first step produces no software, and it decides whether every step after it works. It is short because it is narrow: one workflow, inside one written boundary.
Two or three sessions walk the process with the people who perform it, not with those who describe it in a management report. Then the exception census. For one recent period, every item that did not follow the main path is listed with what happened to it. The exception rate is either much lower than believed, in which case the build is simpler, or much higher, in which case the exceptions are the product and the main path is the trivial part.
The step ends with a written specification: the records the workflow must produce, the order of the steps, the identities involved, the systems it reads from and writes to, the acceptance targets, and a list of what is out of scope. That last list keeps the release small enough to arrive early, and it is agreed before any work begins. The reasoning behind it is in what it takes to get from clear requirements to something running in production.
2. A Release You Can Open
As soon as the main path works end to end, there is a running version in a real environment that you can open and use. It handles the main path on data shaped like yours, and it arrives early in the work rather than at the end of it, when a change still costs little.
It is built to be used by the person who performs the step, so the specification meets reality while it can still change. What almost always changes is not the logic but the shape of the work: a screen that asks for things in the wrong order, a field that should default from the previous item. From this point every change is verified before release and reaches you within minutes, so each correction reaches the person using it before go-live, not after it.
3. Integrations And The Record
Integrations are the step with the risk in it, for two reasons.
The first is that integrations are where other people's systems set the pace: credentials, a sandbox that differs from production, a rate limit nobody documented. None of it is difficult. All of it depends on access, and access depends on somebody outside the project.
The second is the record: who performed each step, when, on which input version, who reviewed it, what was rejected and why. It is easy to defer and expensive to add later. When the workflow exists because of a disclosed control finding, the record is the deliverable.
By the end of this step it runs on the real systems, with real credentials and a real trail.
4. A Release In Use
The release runs alongside the existing process for a defined period, and both results are compared. Each difference is investigated rather than assumed to be a defect in the new system; many turn out to be undocumented behaviour in the old one.
Then the acceptance targets from the first step are run in front of you, the production rollout is agreed from what that use showed, and what you have paid for transfers: the repository, its history, the documentation, a run guide. It is kept running by the person who built it, which matters because the failures that appear after go-live are not ones anyone predicted.
Where It Goes Wrong, And What It Does
The response to schedule risk here is not a padded estimate. It is a bounded scope and a written boundary, so the release is protecting something small enough to be defended.
| What goes wrong | How often | Effect | On the release |
|---|---|---|---|
| Credentials arrive late | Most often | Days of waiting | Waits on the delay |
| An unmentioned exception class | Common | Unplanned logic | This release or next |
| Source data worse than described | Common | Cleaning, matching | Finding it is the job |
| The approver is unavailable | Occasional | Acceptance slips | Waits; work done |
| Requirements change after use | Occasional | Rework | This release or next |
A written scope does not mean nothing can change. It means the release is agreed before work starts, and a change to it is agreed before it is built. Out-of-scope changes go into the next release, in writing, and since changes ship continuously, that is never far away.
How The Work Stays Visible
Every engagement runs in TopDo.ai, a system for work that people and AI do together. The specification and the tasks are the same items, so the plan and the work cannot drift apart, and every change is on the record with a time and an author. You have access to it from the first day, and the workspace and its full history stay yours after the work ends.
First Steps
- Write the scope boundary yourself before anyone quotes you. One paragraph: where the workflow starts and where it ends, and three things that it explicitly does not do.
- Find out today how long credentials take at your company. That wait is the most common reason that a first release arrives later than it could have.
- List the exceptions for one recent period. Not the volume — the list. It determines whether the build is simple or complex, and it takes an afternoon.
Buy The Shape, Not The Promise
A first release is credible when the scope is one workflow, the specification is written before the work starts, and something usable exists early rather than at the end. After that, each verified change reaches you within minutes, so you see value as the work proceeds.
A fifteen-minute call tells you whether your workflow fits this shape. Where it does, one workflow becomes working software inside the three-month initial engagement, with targets written before each release. The repository is yours as it is paid for. Afterwards, Advisory at $10,000 a month keeps one accountable person on it as the systems around it change.
