A four-week date for a first release 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 not their problem.
So this article describes the shape of the weeks: 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 to the date 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 credibility of a four-week date comes from that boundary rather than from working faster.
Week One: The Process Becomes A Written Specification
The first week produces no software, and it decides whether the other three work.
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 trivial.
The week 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 an explicit list of what is out of scope. That last list is the one that makes the date possible, and it is agreed before any work begins. The reasoning is in what it takes to get from clear requirements to something running in production.
Week Two: A Release You Can Open
By the end of week two there is a running version, in a real environment, that you can open and use. It handles the main path end to end on data shaped like yours.
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. These are cheap corrections in week two and expensive ones in week four.
Week Three: Integrations And The Record
Week three is the week 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 week's end the workflow runs on the real systems, with real credentials and a real trail.
Week Four: A Release In Use
The release runs alongside the existing process for a defined period, and the results of both are compared. Each difference is investigated rather than assumed to be a defect in the new system; a meaningful share turn out to be undocumented behaviour in the old one.
Then week one's acceptance targets 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 in week five are not ones anyone predicted in week one.
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 date 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 | Date moves by 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 | Date moves; work done |
| Requirements change after week two | 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, not quietly added to a schedule that slips unexplained.
How The Work Stays Visible
Every engagement runs in TopDo, our own 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 stays 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 four-week release turns into a release of six weeks.
- 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 four-week date is credible when the scope is one workflow, the specification is written before the work starts, and something usable exists in week two rather than week four.
A fifteen-minute call — nothing paid, nothing signed — tells you whether the 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.
