Findings
Users, economics, workflows, existing systems, constraints, and the evidence behind the problem.
- Who does the work, and where it stalls
- The systems and constraints in play
- The evidence behind the problem
Five stages, and each one leaves a document you can read, challenge, and use. If a stage cannot produce its document, the stage is not done — that is the whole method.
These five documents are the engagement. Scroll them: each one has to exist before the next stage starts, and the violet line is the sign-off that lets it.
Users, economics, workflows, existing systems, constraints, and the evidence behind the problem.
What to build, buy, integrate, automate, simplify — or deliberately leave alone.
Design and engineering move together in working releases, not separated by handoff documents.
Real users, real data, quality gates, and measurable operational or commercial outcomes.
Code, access, documentation, runbooks, and operating knowledge move to your team.
You see the work while it is becoming real — not for the first time at the end.
A training programme should not run like a software build, and a commerce system should not be scoped like a media pipeline. One standard of accountability, seven delivery rhythms.
Five clauses that do not change between engagements — and the ones worth arguing about before signing.
You have direct access to the people doing the work.
Scope and acceptance criteria are written down.
Small releases come before large commitments.
Human judgment stays where consequences matter.
No artificial vendor dependency, ever.
You do not need to choose a service or arrive with a technical specification. The first document — the findings — is how we earn the second.