Our method
We start where the work happens.
A process on paper rarely tells the whole story. We learn from the people doing the job, then build with them involved and a human lead responsible for the result.
- 01
Shadow the work
Shadowing the work. Notebooks out, hands off. We begin by spending time alongside your staff. We watch the routine tasks, the exceptions, the handovers and the workarounds that keep the operation moving.
We want to understand which information people trust, where they have to make a judgment and what happens when something goes wrong.
That gives us a practical basis for deciding what to change.
- 02
Agree on the first problem
One card circled. That is where we start. We turn what we learn into a prioritized list of concrete improvements. Each item identifies the people it helps, the result it should produce and the conditions it depends on.
Before development, we agree on what a useful result looks like. We also identify the limits: cases the system should flag, decisions it should leave to a person and information it should not act on alone.
- 03
Build in short cycles
A short cycle, taken literally. We call our compressed development cycles hypersprints. A human lead directs agents with defined roles in product planning, business analysis, development, quality assurance and documentation.
The lead decides what gets built, resolves trade-offs and judges whether the result solves the agreed problem.
Short cycles give us more opportunities to inspect the work and change direction. The scope and readiness of each release determine when it reaches your staff.
- 04
Review before release
Pierre reviews on the screen itself. Kai has opinions. Every build is reviewed by a different model from the one that wrote it. A human then reviews the result before it reaches your staff.
Model review is one layer of checking. It does not replace human judgment or testing against the task the system is meant to perform.
We look at whether the system works, where it fails and whether the people using it can recognize its limits.
- 05
Learn from your staff
Staff try the tool. Every “hmm” goes in Thư's notebook. The people doing the job try the system and help shape the next changes. Their feedback returns to the team building it.
Tan leads the work with your staff, including sessions and documents in Vietnamese and English. Language needs for other stakeholders are agreed at the start.
- 06
Stay responsible after launch
One rack on fire. Tan has tea. Once a system is in use, we continue operating and maintaining it within the agreed scope.
We review what changes in the data, the underlying technology and your process. Further improvements are prioritized with you, based on how the system is actually being used.
Working principles
A person is accountable.
Agents carry out tasks. People decide the scope, judge the work and take responsibility for release.
Your staff shape the result.
Their knowledge matters before the build and after it enters daily use.
Limits are made explicit.
We describe what the system can do, what needs review and what remains outside its scope.
The handover is part of the work.
Your team needs to understand how to use the system and where to go when something needs attention.
Start with one process.
Describe how it works today, who is involved and where it gets difficult. That is enough to begin the conversation.