Anyone senior enough can form a view on a technical claim in an afternoon. The question is what that view is worth. This is how a ten-day verdict is actually reached, what it can and cannot tell you, and how the same discipline is applied to the build once you've committed.
The failure mode in technical diligence is not incompetence. It is a plausible claim, asserted with authority, that nobody checked — and which then quietly determines whether a build is six weeks or six months. Both tools exist to make that specific failure hard.
Declared truth is kept structurally separate from assumption. Nothing merges silently into "what we know".
Declaration → gate → integrate. Nothing enters the verdict because it sounded right.
State it as a claim
Evidence, or it doesn't pass
Lands, with its provenance
A claim that fails the gate does not disappear — it appears in the verdict as an open question with a price on it. That is usually the most valuable page in the report.
A diligence product that claims to answer everything is selling something. Ten working days and €4,000 buys a deep answer to a narrow question. Here is the boundary, stated before you buy rather than discovered afterwards.
Four sections, always, in this order. The third is the one most reports leave out, and the one that most often changes a decision.
Proceed, decline, or proceed subject to named conditions — stated in the first paragraph, not buried on page nine.
Each load-bearing claim, what we did to check it, and what we found. Auditable a year later by someone who wasn't there.
The assumptions we could not resolve inside the window, why, what it would cost to resolve them, and what it costs you if they're wrong.
On a proceed: cost, sequence, team shape, and the order in which the remaining risk should be retired.
Every claim the investment rests on, written down as a claim
Ordered by what breaks if it turns out to be false
The load-bearing ones checked against source, not memory
Findings, open questions, and a price on each
The instinct in diligence is to start testing immediately — dive into the code, form impressions, write them up. That produces a report about whatever happened to be interesting, rather than about whatever happens to be dangerous.
Enumerating first forces the claims into the open while they are still unexamined, including the ones so obvious nobody thought to state them. Ranking by blast radius then decides where the ten days actually go. A claim that is wrong but harmless can stay unchecked and be reported as unchecked; a claim that is load-bearing gets the time, whether or not it looks interesting.
The result is a report whose gaps are chosen deliberately and disclosed, rather than left wherever attention happened to run out.
The verdict names the risks. This is the sequence that retires them — and the reason the milestone bonuses in the term sheet are tied to these, and never to revenue.
What problem is being solved, who has it most acutely, and what success actually looks like. Most money lost in early-stage engineering is not lost to bad code — it is spent building the wrong thing competently. This is the cheapest hour in the engagement.
Each goal carries its blockers and an if-then response written in advance — the WOOP discipline. In practice this is a live risk register that predates the risk, which is what makes a monthly report to you short and specific rather than a narrative.
The build sequence is ordered by the open questions from the verdict, hardest first. The point is to reach the moment where the remaining unknowns are ordinary, as early in the runway as possible — not to demo something impressive in week three.
Read → plan → build → validate, per task, with output tested against acceptance criteria before it lands. The same declaration-and-gate discipline used to reach the verdict, applied to the code.
The engagement succeeds when the company has a permanent engineering team and no longer needs us. We hire it, hand over to it, and stand down. A partner who becomes load-bearing has failed.
AI debugging effectiveness drops dramatically after 2-4 attempts in a single session.
Early-stage engineering budgets are rarely destroyed by a single bad decision. They are destroyed by a small problem that took four days instead of four hours, thirty times over. AI-assisted development has a specific and measurable version of this: the first attempt at a fix has the highest success rate, and each subsequent attempt in the same context does worse, because the model accumulates its own conflicting assumptions and then defends them.
Decay comes from repetition, not from difficulty. The discipline that bounds it is deliberately unglamorous:
1. Three genuinely different approaches — not three variations of the same idea wearing different names
2. Write down what was attempted — so the same dead end is not re-entered next week by someone else
3. Only then reset — fresh context, carrying the explicit learnings forward
Why this belongs in a document written for an investor: it is the difference between a team that burns a week on a problem and a team that burns a quarter on it, and nothing in a monthly update will reveal which kind you have funded until the runway is already gone. The record of failed approaches is the institutional memory that survives both the reset and, eventually, the departure of whoever was holding it in their head.
The tooling runs on one stack, Anthropic's Claude. Not because nothing else works, but because shallow familiarity with six tools is worth less than knowing the failure modes of one. When Claude can't do something, we build the tooling ourselves; only if that fails do we look elsewhere.
Stated plainly, because it is the kind of thing that should appear in a diligence document rather than be discovered in one: this is a single-vendor dependency, and we carry it knowingly. It is mitigated by the fact that the deliverables are not vendor-shaped — the verdict is a document, and the code is ordinary code in your repository, on your infrastructure, owned by the company.
What you get from the concentration is predictable behaviour and accumulated judgement about where these tools quietly go wrong — which is most of what the method above is made of.
The standard objection to a fractional technical partner is the correct one: what happens to the company when they leave, or get hit by a bus, or simply turn out to be wrong for the job? Answering it with reassurance is worthless. It is answered with artefacts, produced continuously as a by-product of building — not written up at the end, when the incentive to write them has gone.
schemas/*.yml
The data model — entities, relationships, constraints. Regenerates into ORM models in any language.
contracts/*.yml
The API surface — endpoints, request and response formats. Maps to routes in any framework.
flows/*.yml
The user journeys — step-by-step behaviour, not wireframes. Rebuilds in any UI framework.
logic/*.yml
The business rules — validation, calculations, edge cases. The reasoning that survives a rewrite.
The kit belongs to the company, not to us, and it is current at every point in the engagement rather than at the end of it. Concretely, that means an incoming permanent CTO can rebuild in Next.js, React Native, Go or Phoenix without an interview with the person who left — and it means the 30-day no-fault termination in the term sheet is a real option rather than a theoretical one. A partner you cannot afford to lose has too much power over the company you funded.