Approach
How we work, from diagnosis to production.
We work in four stages: Diagnose, Design, Build, Scale. We define and measure the problem before we design, we design before we build, and we build systems that run in production before we help your team scale them. The people who diagnose are the people who ship.
The four stages
Diagnose, Design, Build, Scale.
Each stage ends with something you can hold: a document, a blueprint, a system, a number. Durations are typical, not promised. The diagnosis sets the real plan.
- 01
Diagnose
We sit with the people who do the work. We follow an order, a request or a report through the company and see where it stalls, where data is re-entered by hand, and what that costs. No code is written yet. We measure.
- Typical duration
- Varies with complexity, case by case
- Output
- A written diagnosis: the bottlenecks, what they cost, what to change first, and a scoped plan with a quote.
- 02
Design
We design the change before we build it: the new flow, the systems that carry it, the integrations with what you already run, and the numbers we will judge it by. Your team reviews the blueprint and signs it off.
- Typical duration
- From one week
- Output
- A blueprint your team has approved: process map, system architecture and acceptance criteria.
- 03
Build
The same senior people build what they designed. We ship in small increments, to production, with your people in the loop from the first week. Documentation and handover are in scope, not optional.
- Typical duration
- Varies case by case
- Output
- Working software in production, with documentation and your team trained to use it.
- 04
Scale
We measure what changed, fix what does not hold, and extend what works to the next process or the next team. We stay until your team runs the system without us.
- Typical duration
- Evolutive or on-demand maintenance, depending on the option you choose
- Output
- A measured system: monthly numbers, a backlog of next changes and a team that runs it on its own.
Working together
You stay in the loop, start to finish.
We work in short iterations. You see progress against the timeline, validate as we go and shape the result long before launch.
Every iteration
A demo, not a status report.
At a regular cadence we show working software, not slides. You try it, comment and approve, including in the intermediate stages.
Feedback carried forward
Nothing you say gets lost.
Your feedback goes into the next iteration, and every demo opens with what changed since the last session.
Before launch
You test it end to end.
A dedicated acceptance window: you get every account you need to walk through every flow. Meanwhile we verify code quality, performance, security and SEO.
After launch
The code is yours.
You own the source code, the accounts and the documentation. There is no contractual dependency on us. If you continue with another team, they start from a clean handover.
Quality and handover
Checked before launch.
Covered after it.
- Code quality review
- Performance
- Security
- SEO
- Acceptance testing on every flow
- 12-month bug warranty
- Documentation
- Platform administration handover
- CMS training
- Code and accounts in your name
Before go-live we check code quality, performance, security and SEO, and you test every flow yourself. At handover you get documentation and training to use and administer the platform and its CMS. Any bug that shows up after launch is covered by a 12-month warranty.
Principles
Five rules we do not bend.
Diagnose before we build.
We write no code until the problem is defined and measured. The wrong thing built well is still waste.
Senior people do the work.
The people you meet in the first conversation are the people who design and build. There is no handover to a junior team.
We deliver a working system, not a report.
A recommendation, a prototype or a pilot is not done. Done means the system runs in your company and the numbers moved.
Systems your team can run without us.
Documentation, training and a clean handover are part of the scope, not an extra. Dependence on us is a defect.
We say no when it is not worth it.
If the diagnosis shows the change will not pay for itself, we say so and stop. Sometimes the right answer is a smaller fix, or nothing.
Engagement model
Three ways to work with us.
Every engagement starts with a diagnosis. What follows depends on what it finds.
A scoped diagnosis
The Diagnose stage on its own, with a fixed scope. You get the written diagnosis and a plan you can act on with us or without us.
A build engagement
Design and Build for one defined change, from blueprint to production, with a fixed team and a clear end.
An ongoing partnership
Scale as a standing arrangement: a senior team that keeps measuring, improving and extending your systems, quarter by quarter.
Why there are no prices on this page
Every engagement is priced on scope, and scope comes out of the diagnosis. A quote before we understand the problem would be a guess, and you would pay for the guess. We scope before we quote. After the first conversation you know whether a diagnosis makes sense and what it costs.
How we priceLimits
What we will not do.
Saying no early is part of the work. These are the lines we keep.
- We will not sell hours. We deliver working systems, built by senior people with 20+ products shipped.
- We will not put “AI” on your website before there is a process worth automating.
- We will not write a deck for the board instead of changing how work runs.
- We will not rush a build where the launch date matters more than whether it holds.
- We will not take on companies under ten people without a clear growth constraint. A good freelancer serves them better, and we say so.
- We will not quote from a price list. We scope before we quote.
- We will not run grant-driven projects where the grant, not the outcome, defines the scope. We can be the supplier in the file, never the grant consultant.
Questions before a first conversation
How does a first conversation go?
One call, with the senior people who would do the work, and no deck. We ask how work runs today, where it breaks and what growth is pushing on. You tell us what you have already tried. By the end we say whether a diagnosis makes sense and what it would cover. If we are not the right fit, we say that too.
What do you need from us?
Access and candour. During Diagnose: a few hours from the people who do the work, access to the tools and data the process touches, and one decision-maker who can say yes or no. During Build: a named person on your side who reviews and tests. We do not need a brief. The diagnosis produces it.
How do you estimate?
From the diagnosis, not from a call. The Diagnose stage ends with a scoped plan: what we change, in what order and what it costs. Build engagements are quoted as a fixed scope with a fixed team. If the scope changes, the quote changes in writing, before the work.
How we priceHow do you hand off?
Handover is in scope from the start. Every system ships with documentation, admin access in your name and training for the people who will run it. We work alongside your in-house team, not around it. In Scale we keep measuring with your team until they no longer need us. If you want to keep us, that is a choice, not a lock-in.
Who owns the source code?
You do. The source code, the accounts and the documentation are handed over in your name. There is no contractual dependency on us: if you want to continue with another team, they start from the same handover your own team gets.
What happens if the diagnosis says do nothing?
Then we say so, in writing, and stop. You keep the diagnosis: a clear picture of how work runs and where it would break. Sometimes it recommends a smaller fix your team can make alone, and we say that too. You pay for the diagnosis, not for a project you did not need.
What the diagnosis coversBy industry
See how we apply the method in your industry.
Start with a conversation, not a brief.
Tell us how work runs today and where growth is pushing. We reply within two working days.