The method
You know in advance what happens. That is half the work.
60% of executives have deliberately slowed the adoption of new technology out of fear of getting it wrong. Enthusiasm does not fix that: making every step predictable and every decision reversible does.
Every project moves through five phases in a fixed order: listening, mapping, proposal, building, autonomy. No phase starts before the previous one has closed, and after the first two you can stop and take away a document that has value even without me.
The method
What happens, exactly, and in what order
The path is always the same and no phase starts before the previous one has closed. You know in advance what happens, how long it takes, and when you can stop without having lost anything.
-
Listening
One call. You tell me where your day gets stuck. At the end I tell you honestly whether this is a problem worth tackling now, later, or never. Plenty of calls end with "you don't need this".
-
Mapping
I come and see how you actually work, not how the manual says you do. I talk to the people doing the job, not only to the people running it. You receive a map of the current process with the points where time is lost, quantified in hours. That document is yours even if we stop here.
-
Proposal
I present three levels of intervention: the minimum that solves the biggest problem, the recommended one, and the complete one. With timings, costs and what you get from each. You choose. No pressure, no invented deadlines.
-
Building
I do not disappear for six months and reappear with something. Every two weeks you see a working piece and you try it. Every Friday you get a thirty-second update on what was done. If something is heading the wrong way, we find out in week two, not in month six.
-
Autonomy
Handover, training your people, documentation, and the warranty on the software. The stated goal of this phase is that you no longer need me. If a supplier has an interest in making you dependent, you have the wrong supplier.
The principle underneath all of it
Technology projects almost always fail for the same reason: someone decided what to build before understanding how the work was really done. The software then works perfectly — and nobody uses it.
That is why the most important phase is not development: it is mapping. That is where you discover the problem was not what it looked like, and save months.
Honesty
Who this is for, and who it is not for
I do not work with everyone, and saying so upfront serves us both. A project that starts with the wrong expectations ends badly even when the software is perfect.
It makes sense if
- You have between 10 and 250 staff and your way of working outgrew your tools.
- At least one person in the company can give the project a few hours a week.
- You want to understand what you are buying, not just delegate it.
- You care more about the result in two years than about the cheapest quote today.
It does not make sense if
- You are looking for the lowest quote: it will not be me, and I say so now.
- You want to "do AI" without knowing which problem it should solve.
- Nobody in the company has time for the project: without your knowledge it does not work.
- You expect to hand everything over and not be involved until the end.
The first step
We start with a conversation, not with a quote.
Forty-five minutes in which you tell me where your day gets stuck. At the end you will have at least one useful thing: my honest opinion on what to tackle first — even if you then decide to do it with someone else, or not at all.
No commitment, no email sequence afterwards. If you are not the right client, I will be the one to say so.