I have run this method inside organisations where getting it wrong cost millions. British Airways, Virgin Atlantic, Elekta. The order of the phases is the part that transfers. The scale is the part that changes.
Five phases. Each one ends with something you can read, disagree with, and sign. Nothing moves to the next phase until the last one is closed, because the alternative is finding out in week six that we were building different things.
The £300m portfolio I worked on was an airline's, not a client's. What came with me was the method, not the balance sheet. AI is what makes that method affordable at your scale: I use it to do work that used to take a delivery team, and that is the only reason the price works.
Phase 1. Diagnose
Find the actual constraint, not the one that is loudest.
Most businesses know something is slow. Fewer know which thing. The first job is to separate the symptom from the cause, because automating a broken process just makes you wrong faster.
I look at where work actually moves: who touches what, how many times the same information gets typed, where things sit waiting. I talk to the people doing the work rather than only the person paying for the fix. Then I tell you what I found, including the parts you will not enjoy hearing.
Sometimes the answer is that you do not need a build. I would rather tell you that in week one than sell you one.
What you do
Give me two or three hours of your time and access to the people who do the work. That is close to the whole ask.
What you have at the end
A written read on what is costing you time, ranked, with a recommendation on what to fix first and what to leave alone.
Phase 2. Design
Agree what we are building before anyone builds it.
This is the phase most small projects skip, and skipping it is why they run over. Design is where scope stops being a conversation and becomes a document: what the thing does, what it deliberately does not do, what data it holds, who can see it, and what finished means.
It is also where the price gets fixed. You approve a scope and a number together. If you want something added later, that is a new phase with its own number, not a quiet overrun.
What you do
Read the scope and tell me what is wrong with it. This is the cheapest moment to change your mind by a wide margin.
What you have at the end
A signed scope with a fixed price and a clear list of what is out.
Phase 3. Build
Build it against a standard, not against a mood.
I build to a written standard that covers security, privacy, accessibility, performance and testing, and I check the build against it before I hand anything over. Ten of those checks are absolute: if the build fails one, it does not go live, whatever the date says.
You see progress as it happens rather than at the end. That is deliberate. Feedback in week two is free, and feedback after launch is not.
What you do
Look at it when I send it and say what feels wrong. You do not need to know how it works to know when it does not fit how you work.
What you have at the end
A working system, tested, with the evidence of those tests written down rather than asserted.
Phase 4. Launch
Go live on purpose, with a way back.
Launch is a decision, not an event that happens to you. Before anything goes live there is a checklist: the data is where it should be, a restore has actually been tested rather than assumed, the accessibility check is clean on every path a real person uses, and there is a documented way to undo it.
Then your team gets shown how to use it, and you get written down how it works, so the knowledge sits with you rather than only with me.
What you do
Pick the date, and get your team in a room for the handover.
What you have at the end
It is live, your team can run it, and you hold the documentation and the access, not me.
Phase 5. Mature and iterate
Check whether it actually worked.
Ninety days after launch I come back and measure the thing we said we would improve. Not a satisfaction survey. The number from phase 1, taken again.
If it moved, you know the money worked and you know where to spend the next lot. If it did not, I would rather be the one who tells you. Either way you get the honest version, which is worth more than a case study.
From here it is your call whether anything ongoing makes sense. Plenty of clients stop here, and that is a finished engagement rather than a failed sale.
What you do
Half an hour, ninety days later.
What you have at the end
A measured before-and-after on the thing you paid to fix.
Why I can promise the order
The method is not improvised per client. It sits on a written standard covering how a build is scoped, secured, tested, launched and supported, with named gates between phases and ten checks that can stop a launch outright.
I wrote it because I spent twelve years watching large programmes succeed and fail for the same small set of reasons, and none of those reasons were technical.
You are welcome to ask to see it. Most consultancies cannot show you theirs, because it does not exist outside the way they happen to work.
Where price comes from
Price is set at the end of phase 2, not before it, because a fixed price on an unscoped problem is a guess dressed up as a commitment. What moves it: how many systems have to talk to each other, how much of your data needs cleaning before it can move, how many people need to be trained, and whether anything is regulated.
Most first phases land under £5,000.