It means the distance between the product you have and the product the business needs, expressed as a number both of us agree on before any code is written.
Four phases close that distance. Every engagement runs through all four, whether it lasts six weeks or six months.
Typical length: one to two weeks.
I read the code, the release process, and the incident history before forming an opinion. Then I ask the question most vendors skip: what does this cost you every month it stays the way it is? You get the bottleneck in writing, ranked, with the one metric that proves it is fixed.
Typical length: two to three weeks.
The stack, the team shape, the cost model, and the sequence, decided on paper where changing your mind is free. If a decision would be expensive to reverse later, it gets argued now. You keep the architecture document whatever happens next. It is yours, not a sales asset.
Typical length: six to sixteen weeks.
Weekly releases to a live staging environment you can open yourself. Test coverage starts in week one, so the suite grows with the product instead of being bolted on at the end. Progress is visible without a status meeting. If a week goes badly, you hear it that week.
Typical length: three to six weeks.
Automation, monitoring, alerting, and documentation, then a handover session with your team. The measure of a good engagement is how boring the month after it feels. If you want me to stay on retainer after that, it should be a choice, not a dependency.
Where the product is today, in your words, with no slides from me.
What has already been tried, and what it changed. This is usually the most useful part.
The cost of leaving it alone for another two quarters, in your numbers.
Whether I am the right person. Sometimes the honest answer is no, and I will say so.
Next step
One call, forty five minutes, no deck. You leave with the actual diagnosis whether or not we work together.