How a project actually runs
Five stages. Every system is shaped around your real processes, tools, people and goals — the stages are the constant, the work inside them is not.
Five stages, and what happens inside each
Pick a stage below, or rotate the model and click a node. Both do the same thing.
The five stages
Discover
We learn how the work is done now — the tools, the people, the exceptions and the reasons behind them.
- Workflow and process walkthrough
- Tool and data inventory
- Where time is actually going
- Constraints, risks and regulatory limits
- Agreed definition of a good outcome
The five stages
Discover
We learn how the work is done now — the tools, the people, the exceptions and the reasons behind them.
- Workflow and process walkthrough
- Tool and data inventory
- Where time is actually going
- Constraints, risks and regulatory limits
- Agreed definition of a good outcome
Design
We propose the smallest system that solves the real problem, and are explicit about what it will not do.
- Prioritised opportunities with rough effort
- System and data-flow design
- Which decisions stay with a human
- Integration and access requirements
- A scope you can say no to
Build
We build in visible increments, so you are never waiting months to see whether the idea works.
- Working increments you can try
- Integrations with least-privilege access
- Testing against real cases and edge cases
- Failure paths designed, not assumed
- Documentation written as we go
Launch
We move it into live use carefully, with your team trained and a way back if something is wrong.
- Staged rollout rather than a switch-flip
- User acceptance testing with your team
- Training and written handover
- Monitoring and alerting in place
- A documented rollback path
Improve
Systems drift as the business changes. We review how it is performing and adjust it.
- Reviews against the outcome we agreed
- Prompt and rule refinement
- Running-cost monitoring
- New cases added as they emerge
- Optional ongoing support
The rules we hold to
These are the positions we default to when a project forces a trade-off.
The smallest system that solves it
Scope grows easily and shrinks with difficulty. We propose the least complicated thing that addresses the actual problem, and say explicitly what it will not do.
A human decides anything consequential
Automation handles the repeatable part. Where a decision carries real cost — money, a commitment, a customer relationship — it routes to a person.
Least-privilege access, always
Every integration gets the narrowest permissions the task needs. No system receives broad access because it was easier to configure.
Documented as we go
You should be able to hand the system to another developer, or leave us, without the knowledge going with us.
Failure paths designed, not assumed
What happens when the API is down, the model is wrong or the data is malformed is part of the design, not something discovered in production.
We will tell you when AI is the wrong answer
Sometimes the fix is a better form, a cleaned-up spreadsheet or a process change. Saying so costs us a project and saves you a bad one.
Start with the Discover stage.
The first conversation is the beginning of discovery, and it is free. Bring a process that frustrates you and we will work out together whether it is worth systematising.