Technical due diligence. A few days, and the deliverable is yours.
A short, paid assessment on a defined subject: what you actually run, where the risk sits, and what each option costs. You keep the document whether or not you continue with us, and the fee is credited against the engagement if you do.
Two very different situations, one method
The first is a decision you are about to make: modernize a system, migrate a platform, launch a build, or take over a project that went wrong. You need the ground truth before committing a budget.
The second is an acquisition. There the posture is adversarial, the clock is short, and access is limited because the seller rarely opens everything. We prioritize what moves valuation and, just as importantly, we write down what we could not verify. A declared blind spot is worth more than a false certainty.
Same discipline in both cases: compare the system as described with the system as it actually is. The gap between those two pictures is usually the most useful thing in the report.
Boundaries, stated up front
- No code written. A few days is enough to scope or enough to build, never both. This is scoping.
- No proof of concept. That is a separate piece of work, after the assessment, if it makes sense at all.
- No disguised sales call. If the assessment shows you should not do the project, it says so. If the right vendor for the next stage is not us, it says that too.
- No open-ended follow-up. The assessment ends at the readout. Questions a month later are a new piece of work. Not to be confused with the thirty-day warranty on our delivery engagements, which covers handover of something we built: an assessment builds nothing, it produces a document that reads without us.
Four questions answered plainly.
-
What exactly is in the deliverable?
Four things you can act on. A flat map of the systems and how they connect, which is often the first time anyone has seen it laid out. A risk list separating technical, organizational and calendar exposure. Several costed scenarios, including the scenario of doing nothing. And a sequenced action plan naming the skills each stage needs. It ships with editable sources so you can reuse it.
-
Why is the assessment paid when others offer a free audit?
Because a free audit gets rushed, flatters, and steers toward whatever suits the person offering it. A paid one buys the time to understand, and more importantly it buys conclusions that do not serve the vendor, including the conclusion that the project should not go ahead. The fee is credited against the engagement if you continue, which makes it an entry point rather than a toll.
-
Who needs to be available during the assessment?
Three to five people, in sessions of thirty to forty-five minutes. The sponsor, for the business stake and the constraints. One or two operators, to hear what the tools actually do to their day and what workarounds exist. Whoever currently runs the technology, internal or external, for the real architecture. And if the subject calls for it, a business reference for the rules nobody has ever written down.
-
Can the assessment conclude that we should not proceed?
Yes, and it happens. The exercise compares the system as described with the system as it actually is, and the gap between the two is usually more informative than either on its own. Sometimes it shows the problem is organizational rather than technical, or that the intended timeline cannot hold. A negative conclusion written down plainly saves far more than the assessment costs.
Name the decision you are trying to make.
Twenty minutes to agree the subject and the scope of the assessment. If a shorter conversation is enough to answer your question, we will tell you that instead.