How we work
Understand. Design. Build. Evolve.
This is a method for producing systems that fit. It is not a delivery timeline, and it is not a catalogue of phases designed to look busy.
01
Understand
We learn how the business actually works. Not the org chart — the path of a sale, a decision, an exception. Who waits. What is true, and where that truth currently lives.
We sit with the people who do the work, including the unofficial version that actually runs the company. We do not start in a design file. If the path is not clear yet, we do not pretend a sprint will invent it.
- What we look at
- A live deal, a live request, or the spreadsheet that still runs the week. Who is asked when something is stuck. Where the number that people trust actually lives.
- What you leave with
- A written picture of the path: stages, waits, owners, and the places truth currently splits.
02
Design
We translate the process into a system. Roles, stages, rules, and the few integrations that deserve to exist. The design is a working description of the company, not a set of screens.
Exceptions count as part of the process, not leftovers. If a deal waits on finance, that wait is a stage, not a note. The design should be readable by the people who will use the system — because it is their process, written down.
- What we look at
- What the system must remember. What a person must still decide. Which tools have earned a connection, and which are just another tab.
- What you leave with
- A description the business can recognise: roles, stages, rules, and what happens after the work is done.
03
Build
We turn the design into a working system. The aim is something people will use because it matches the work, not because they have been asked to.
The tools are chosen for the system. They stay in the background. We take on work we can hold with attention — not a queue of parallel deliveries dressed as a method.
- What we look at
- The first slice of the path that, if it works, makes the unofficial method unnecessary. Not a demo of everything. The part that currently hurts.
- What you leave with
- Software the organisation can run. The people who do the work should not need a workaround to know what is true.
04
Evolve
The system grows with the business. Processes change. What we build should be able to change with them, without a second unofficial method appearing beside it.
A system that cannot change will be abandoned in the same way a generic tool is abandoned: politely, then completely, while the real process returns to a spreadsheet.
- What we look at
- What changed in the business: a new kind of deal, a new desk, a rule that used to be rare. Whether the system still matches, or a workaround has started again.
- What you leave with
- A process the organisation can alter without starting another file. Attention held, not a handover into a ticket queue.
What this is not
A production line will give you a production-line system.
We do not run parallel queues, staff a factory, or start with a catalogue of modules. The method is slow enough to see the work, and exact enough to put it in software. We take on work we can hold with attention.
There is no performance of looking busy: no phases invented for show, no promise of a date that the process itself has not earned. If the company cannot yet say how a sale or a request moves, we stay in Understand. Putting confusion into software is not progress.
What we need from you
Access to how the work actually happens.
- Someone who knows the workNot a briefing deck. The person people already ask when the process is unclear.
- The unofficial pathThe spreadsheet, the chat, the exception that happens every week. That is the source.
- A problem that is realIf the cost of the mismatch is not yet visible in the work, it is too early to put it in software.
If the unofficial process is the real one,
Bring that. We will treat it as the start of the method, not a request for a quote.