Approach
How an engagement typically runs.
Not every piece of work uses every phase at the same length. Advisory may end after shape. A well-defined build may keep discovery brief. The sequence is the default, not a ceremony.
01
Discovery
Short, structured, documented
We learn how the system actually works—the people, the constraints, the existing software, and the decision that needs to be made. Discovery produces writing: a picture of the current state and the question the engagement will answer. It is not a fishing expedition.
02
Shape
A written proposal you approve
We propose a scope: what will be built or decided, what will not, how we will work, and how you will know it is done. Assumptions are listed. Risks are named. You approve it in writing before build starts. If the shape is wrong, this is the inexpensive time to change it.
03
Build
Regular view of the actual work
Design and implementation proceed in small, reviewable pieces. You see the work as it exists. Questions are asked when they appear, not collected for a late surprise. Scope changes are written down; they do not hide inside a status update.
04
Transfer
Owned by your team when we leave
The software, the decisions, and the operational knowledge move to the people who will keep them. We do not make ourselves the only ones who understand the system. Documentation is part of the work, not an afterthought at the door.
Working habits
One primary point of contact
You should not have to reconstruct the engagement from several inboxes.
Written decisions
Architecture, scope, and tradeoffs are recorded. Memory is not the system of record.
Small batches
Reviewable work, often. Large unveils hide mistakes.
No surprise scope
If the work changes, the writing changes first.
If this matches how you want to work, write.
Describe the problem, the system as it stands, and the outcome you want. We read everything that arrives.