You have been here before
A firm came in with a polished process, a confident proposal, and a timeline that made the whole thing feel manageable. The build happened. Something was delivered. And then, gradually, the thing they delivered became your problem — not theirs.
Maybe the documentation was thin. Maybe the person who built it moved on and took the understanding with them. Maybe it worked at delivery and slowly stopped working, and you were left holding it without knowing why.
That experience does not make you difficult. It makes you informed. And the way a firm responds to the questions it produces tells you almost everything you need to know about whether this time will be different.
Scepticism is diagnostic information
When a client comes to us with their guard up, we do not treat that as an obstacle. We treat it as the most useful thing they have brought to the first conversation.
A client who has been burned before knows exactly what went wrong. They can describe the moment the documentation turned out to be incomplete. They remember the handover meeting where they nodded along and realised afterwards they still had no idea how to run what had just been handed to them. They know the feeling of calling the firm six months later and finding out nobody who worked on their project still works there.
That knowledge is precise. It is a map of what matters — and a firm worth working with will ask to see it.
If you raise those concerns and the firm responds with reassurance — we have a great handover process, our documentation is thorough, our clients love working with us — that is not an answer. That is a deflection. The right response is to ask what specifically went wrong, and then explain how their process addresses it. Not generically. Specifically.
The questions that matter
There are a small number of questions that reveal whether a firm has genuinely thought about what comes after delivery. A firm that has built for ownership will answer them easily, because the answers are just descriptions of how they work.
The first is who will be able to run this when you leave. Not will there be documentation — that is a different question. This one is asking whether the firm has thought about a specific person, with specific knowledge gaps, in a specific operation, who will be responsible for the system after handover. If the answer is vague, the handover plan is vague.
The second is what the documentation looks like, and who it is written for. Good documentation is written for the person who will maintain the system — not the person who built it. Ask to see an example from a previous engagement. The difference between documentation written for the builder and documentation written for the operator is visible immediately. One is a record of decisions made. The other is a guide for someone encountering the system for the first time.
The third is what happens when something goes wrong six months after handover. Listen for whether the answer describes a support structure or a hope. A real answer names the mechanism — a retainer, a named contact, a defined response time, a relationship that continues. A non-answer describes the quality of the build and implies that problems are unlikely.
The fourth is whether they have ever told a client the technology was not the right answer. A firm that evaluates problems before designing solutions will have done this. A firm that sells technology will not have done it, or will not be willing to say so. The honest answer is: yes, and here is what we found instead.
What welcome scepticism looks like in practice
There is a difference between a firm that tolerates your caution and one that actively benefits from it.
A firm that tolerates it will answer your questions politely and move the conversation back toward the proposal. They want you to feel reassured enough to proceed. Your concerns are an obstacle between them and a signed scope.
A firm that benefits from it will use your concerns to sharpen the engagement. They want to know what went wrong before because it shapes what they design now. The fact that your last system had no runbook means this one gets a runbook. The fact that your last handover left your team dependent on one person means this engagement is structured from the start around distributed knowledge.
Your history is not baggage. It is a brief.
The standard to hold
By the end of any engagement, there are a small number of things that should be verifiably true. Your team should be able to operate the system without calling the firm. They should be able to diagnose a common problem. They should be able to make a change without breaking everything. The knowledge about how the system works should live in the documentation — not in one person's head.
These are not aspirational outcomes. They are the minimum. An engagement that does not produce them has not finished — regardless of what the invoice says.
A firm worth working with will state this standard before the engagement starts, structure the work around achieving it, and verify it before they consider the project done.
If they cannot tell you, at the beginning, what done looks like in those terms — that is the answer.
Use the filter
The operations we walk into that are hardest to fix are rarely the ones where something broke catastrophically. They are the ones where the firm did a reasonable job, delivered something that worked, and left before anyone had to own it.
The client accepted the handover. Signed off on the documentation. Trusted that the relationship would continue in some form if something went wrong. None of that was unreasonable. It just was not enough.
The clients who avoid that outcome are not the ones who found a better firm on the first try. They are the ones who asked harder questions before the work started, and paid attention to how those questions were received.
Your scepticism is not a problem to be managed. It is a filter. Use it.