Understand
Clarify the real problem before proposing a solution: the current process, the constraints, what's already been tried. This step avoids quickly solving the wrong problem.
Approach
A way of working, not a fixed formula
The same framework applies to every project — its depth varies with what the project actually needs.
Discuss your context
Approach
Six stages that turn a need into a durable system
The depth of each stage adapts to the initiative, while important decisions remain explicit and verifiable.
Design
Define an honest scope — what's in the project, what isn't, and why. Technical choices are justified, not just listed.
Build
Deliver in verifiable iterations rather than a single final delivery. Each stage is tested before moving to the next.
Evolve
Plan for maintenance and growth from the design stage, with documentation that lets someone else pick up the system.
Delivery principles
What doesn't change from project to project
Quality is not a final inspection. It is built into decisions, testing, and documentation throughout the work.
Scope is discussed before it's promised
Technical decisions are documented, not just executed
Accessibility and security are considered from the design stage, not added at the end
A real disagreement or constraint gets flagged rather than hidden
Product scoping
Is this approach a fit for your project?
This way of working fits best when scope can be clarified from the start. For a project that's still vague, product design and prototyping exists precisely to clarify the question before committing further.
Product design and prototyping