Week by Week Through a Build
Last updated:
A typical sixteen-week shape
| Weeks | What happens |
|---|---|
| 1–2 | Discovery: process, data, systems, access |
| 3 | Data model agreed and built |
| 4–5 | Core workflow, reviewed with real users |
| 6 | First release to a small group |
| 7–12 | Extension, integrations, permissions |
| 13–14 | Reporting and edge cases |
| 15–16 | Rollout and handover |
What we need from you
- Week 1: access to every system, requested immediately
- Weeks 1–2: two to three days from whoever knows the process
- Week 5: half a day reviewing with the people who will use it
- Weeks 7–12: feedback within a day or two, consolidated
- Week 15: a rollout decision, and someone available
Access is the most common cause of delay and it is entirely preventable. Request everything on day one, including what is needed in week ten.
Feedback from one voice
Four people giving contradictory feedback separately is the second most common cause of delay. One person collecting and resolving it internally keeps a project moving.
That person also needs authority to decide, or the consolidation just relocates the disagreement.
Scope additions go into phase two
Things will occur to people during the build. That is healthy and it should not silently expand the current phase.
We record them, price them, and they go into a phase two list. Nothing is lost and the current date holds.
After launch
- A month of small fixes as real use reveals things, included
- Monitoring watched closely for the first fortnight
- Then a maintenance arrangement or handover to your team
- A ninety-day review against the original measure
Frequently asked questions
Can a project go faster?
What if requirements change during the build?
How much of our time will it take?
What happens if you are running late?
Need something live by a specific date?
Tell us the date and the scope, and we will tell you honestly whether it fits.
Related services
What we build for problems like this one