Almost any product can be built. That is rarely the question that decides a project. What decides it is the budget, the calendar and the people, and those are what this review puts numbers against.

Over five working days I work through the idea, what already exists, the technical approach, the integrations and the operational side of running it. The aim is to surface the difficult parts early, while they are still cheap to deal with.

What founders typically get out of it: a tighter first release, fewer surprises during the build, better conversations with developers and suppliers, and enough detail to put a real number in a funding application. Occasionally the outcome is a decision not to build the thing as described, which is usually the most valuable result of all.

What it doesn’t cover: whether anyone wants the product, what to charge for it, how it stacks up against competitors, or whether a security implementation is sound. There is nothing built yet to test, so security appears here as design decisions rather than as an audit.

Read a redacted sample report →  A real review, edited for sharing.

You have a product, you’re preparing to raise, and an investor’s technical reviewer is coming. What they find is often nothing to do with how good the engineering is.

It is usually the ordinary things. Intellectual property never assigned by a contractor who left two years ago. An agency contract nobody can find. Security that is handled properly in practice but written down nowhere. Documentation that stopped being updated at some point and nobody noticed.

Over eight to ten working days I go through the areas diligence actually examines: the system as it has been built, how it holds up under growth, the security and data protection position, who owns the code, and what happens if a key person leaves. Then I work out which questions you can already answer and give you the gaps in the order they need closing.

The point is to walk into diligence knowing what is coming and having the answers ready.

This assumes there is something built to assess. If you are still at the idea stage, the Feasibility Review above is the one you want; technical diligence does not usually arrive until there is a product to examine.

What it doesn’t cover: legal advice on contracts or IP assignment, and security testing or certification. The work establishes what is in place and what is missing. Acting on a legal gap needs a lawyer, and proving a control works needs a tester.

Because you commission this rather than an investor, it does not stand as independent diligence. Its purpose is to find the problems early enough that they can be dealt with before an investor’s reviewer arrives.