A sample build memo.

The thesis, as we understood it

"Claims processing at mid-size European insurers is about to be rebuilt around AI. Adjusters spend most of their time reading documents, not making decisions. I want to own the company that becomes the claims-intelligence layer for insurers too small to build this themselves. I have capital committed and no technical team."

Executive verdict

Buildable, and the timing logic holds — but the company that wins here will not sell "AI claims automation." It will sell shorter settlement cycles with an audit trail a regulator can read. The technical risk is moderate; the two decisive risks are data access before the product exists and the EU regulatory posture of anything that touches a claim decision. Both are addressable, and both shape the architecture below. We would take this build.

1. The system we would build

A claims-intelligence pipeline that sits beside the insurer's core system (Guidewire, Sapiens, or the in-house relic), never inside it in year one:

• Intake & extraction. Documents (FNOL forms, medical reports, invoices, photos) enter through a watched channel; a document-understanding layer extracts structured facts. Extraction runs on a hosted frontier model behind a provider-agnostic gateway, with every field carrying a confidence score and a source span, so a human can see where in the document each fact came from.
• Validation & enrichment. Extracted facts are checked against policy data and claim history. Deterministic rules where rules suffice; the model only where judgment is genuinely required. This split is what keeps the system explainable and the per-claim cost low.
• The human gate. Nothing pays out automatically. The system drafts a settlement recommendation with its evidence attached; an adjuster approves, adjusts, or rejects. Every disagreement between adjuster and system is captured — that disagreement stream is the most valuable training data in the company.
• The eval suite, from day one. A private, adversarial test set of real claim documents (anonymized, partner-provided) that every model change must pass before deploy. This is the moat the demo never shows: after a year, the eval suite and the disagreement data are why a competitor with the same model API cannot catch up.

Deployment: single-tenant per insurer, EU-hosted, VPC or on-prem where required. Boring by design — regulated buyers pay for boring.

2. Team plan and sequencing

The full team joins at signing; no hiring round precedes the build. Sequencing over the first two quarters: weeks 1–8 are domain immersion with the design partner (reading real claims, shadowing adjusters, building the eval set before the product), parallel with the extraction pipeline; weeks 9–20 ship the human-gate workflow into one claim type — motor or property, not both — for one design partner; the second design partner onboards only after the first adjuster team uses the system daily. First non-founder hire is a claims domain expert, not an engineer.

3. Cost to first production deploy

Stated in ranges you can pressure-test, assuming the founding team takes equity and salaries stay at sustenance level until the seed round:

• Team run-rate: the dominant cost, and the one this model compresses — founder-equity economics rather than ten market salaries.
• Model & infrastructure: low five figures (EUR) monthly at pilot scale; document extraction is cheap per claim relative to claim value, and the deterministic/model split keeps it there.
• Data & compliance: the underestimated line — anonymization tooling, DPIA work, audit logging, and the eval-set construction. Budget it like a feature, because it is the product's license to exist.
• Realistic envelope to a paying design partner in production: mid-six figures EUR, with the largest variable being how quickly the first insurer grants data access — which is a partnership problem, not an engineering one.

4. The three risks most likely to kill it

• Data access before product. Insurers do not hand claims data to a stealth vendor. De-risk: anchor design partner secured before incorporation (an LOI with data-sharing terms is worth more than the first hire), synthetic and public corpora for the pipeline skeleton, single-tenant EU deployment as the opening concession.
• Regulatory classification. A system that decides claims is high-risk under the EU AI Act; a system that assists an adjuster with evidence attached sits in a defensible posture. De-risk: the human gate is not a feature, it is the positioning — and the audit trail is designed for a regulator to read, not just the customer.
• Incumbent distribution. Guidewire and the consultancies own the C-suite relationship. De-risk: wedge through claims operations, not IT; one claim type with measurably shorter cycle time beats a platform pitch; integrations stay read-only for the first year so the core-system vendor has nothing to veto.

What we would need from you

Conviction on the vertical, the capital envelope above, and introductions toward one design-partner insurer if your network reaches one. The team is in stealth; names come with the first conversation, under NDA if you prefer.

End of sample. Figures are illustrative ranges for a hypothetical thesis, stated so they can be challenged — a real memo is written against your thesis and your numbers.