Most of our engagements now begin the same way: a four-week proof of technology, run on production systems with real data and a fixed scope.
It is the most useful thing we do, and the part clients most often want to skip.
What the four weeks contain
- Week one — agree the question. We write down what success looks like, in terms specific enough to be wrong. Not "improve forecasting accuracy" but the number, the baseline it is measured against, and who signs off that it moved.
- Weeks two and three — build against real data. Production systems, actual volumes, the awkward records nobody mentions in the workshop. Synthetic data will confirm almost any hypothesis, which is precisely why it is not evidence.
- Week four — go or no-go. A working artefact, an assessment of what it would take to run it properly, and a recommendation.
Both answers have to be available
A proof that can only conclude "yes" is not a proof. It is a procurement formality with a technical costume on.
So the recommendation at week four is genuinely open. If the evidence does not support proceeding, that is what we will say, and it is a far better outcome than a programme committed on optimism and unwound eighteen months later with nothing to show and a team that has stopped believing the next proposal.
This is easier to write than to do. It means telling a client who has already socialised a project internally that the data is not there yet, or that the problem does not require machine learning and a rules engine they can read and audit would serve them better. We will say both.
Why the constraint helps
Four weeks is short enough that nobody has to defend the sunk cost, and long enough to hit the problems that matter — which are almost never the model. They are the gaps in the source system, the field three teams populate differently, the process step that exists only in somebody's head.
A longer discovery phase does not surface those any earlier. It just gives everyone more time to describe the system as it was designed rather than as it runs.
What happens after
Where the answer is go, the proof becomes the first increment rather than a throwaway — the pipeline, the evaluation harness and the deployment path carry into the build. Where the answer is no-go, the client has spent four weeks instead of a year, and generally knows considerably more about their own estate than when they started.
Build first. Pitch second.