AI for Startups
Most startups calling themselves AI companies have a wrapper over an API, which is fine as a product and weak as a moat. Knowing which you have determines what you should build next.
The two questions that matter early are whether the product works reliably enough to sell and whether anything about it is hard to copy. Both have answers, and both are more comfortable to establish now than during a diligence process.
AI for startups covers product architecture and defensibility assessment, evaluation practice before scale, unit economics modelling, technical due diligence preparation, and pragmatic build-versus-buy guidance for teams with limited engineering capacity.
What actually makes an AI product defensible
A prompt is not a moat, and neither is being early. The defensibility questions are specific and worth answering honestly before an investor asks them in a room.
| Claimed moat | Is it real? | What would make it real |
|---|---|---|
| "Our prompts are proprietary" | No | Prompts are trivially replicable and often extractable |
| "We fine-tuned a model" | Weakly | Depends entirely on whether the training data is unique to you |
| "We have proprietary data" | Sometimes | Only if it accumulates from usage and competitors cannot buy it |
| "We are integrated into the workflow" | Often yes | Switching cost is a genuine moat and undersold by technical founders |
| "We have an evaluation harness" | More than people think | Knowing whether a change helps is a compounding advantage |
| "We are cheaper per request" | Temporarily | Inference costs fall for everyone; this is a lead, not a moat |
The data moat test
A proprietary data advantage is real when the data accumulates from your product's own usage, improves the product measurably, and cannot be bought or scraped by a competitor. Most claimed data moats fail the third test. If a well-funded competitor could licence equivalent data next quarter, the advantage is a head start rather than a moat — which is worth knowing before you build a strategy on it, and worth saying plainly to investors who will check.
Evaluation before scale, not after
Early is when it is cheap
Building an evaluation suite with fifty customers is a week of work. Building one with five thousand, across features that have drifted apart, is a quarter. Startups routinely defer it because it does not ship, and then cannot change anything safely at exactly the moment they need to move fastest.
Your early users are your test set
Real queries, real failures, real corrections. Capturing them systematically from the first month costs almost nothing and produces the asset that makes every later decision faster.
Provider dependency is an existential risk at this stage
A model provider changing pricing, deprecating a version or altering behaviour can break a small company. Abstraction at the boundary and an evaluation suite that lets you test an alternative in days rather than months is cheap insurance.
Measure what customers actually value
Not response quality in the abstract, but whether the task completed and whether the user came back. Startups over-index on output quality and under-measure task completion, which is the number investors and customers both care about.
What technical due diligence will ask
We are frequently hired by investors to assess AI claims in targets, so this list is what we ask. Preparing for it is straightforward and the absence of answers is itself a finding.
- What is proprietary beyond the prompt? The first question, and weak answers cluster together.
- Who owns the training data and under what basis? Customer data used without a clear contractual right is a material liability.
- How is performance measured? Held-out evaluation against a baseline, or demo quality. There is rarely a middle answer.
- What is the exception rate in production? Accuracy is quoted; exception rate determines whether customers save time.
- What does inference cost per unit? Gross margin at scale is a valuation input and frequently untracked.
- What happens if the provider changes? No abstraction and no evaluation harness is an existential dependency.
- Who built it and are they still here? Key-person risk hiding inside a technology claim.
We price diligence so the answer is not for sale
When we assess a target for an investor, we charge a fixed fee and take nothing contingent on the transaction, precisely so that "this does not stand up" stays available as a conclusion. A meaningful share of assessments reach it. The same principle applies when a startup hires us to prepare: we will tell you which claims will not survive scrutiny rather than help you phrase them better.
How an engagement runs
Short, direct, and frequently ending with advice not to build something.
Architecture and defensibility review
What is actually proprietary, what a competitor could replicate in a quarter, and where the real advantage sits.
Evaluation and economics
Test set from real usage, quality criteria agreed, cost per request instrumented and modelled at scale.
Targeted build
Only where it is genuinely needed — provider abstraction, evaluation infrastructure, or the specific capability that is defensible.
Diligence preparation
The questions an investor's technical assessment will ask, answered with evidence rather than narrative.
Advisory
Fractional support where a full engagement is not warranted, which for early-stage companies is often.
What you receive
A clear read on what you have, and the practices that make the next year cheaper.
Defensibility assessment
What is proprietary, what is replicable, and what would need to be true for a moat to exist.
Evaluation harness
Built from your real usage, cheap now and expensive later.
Unit economics model
Cost per request against revenue, modelled on the usage distribution rather than the average.
Provider abstraction
So a pricing change or deprecation is a week rather than a quarter.
Diligence readiness
Evidence for the questions a technical assessment will ask.
Honest written assessment
Including which claims will not survive scrutiny.
Is this the right starting point?
Worth being direct. There are situations in startups where custom AI work is the wrong spend, and those are listed rather than buried.
Worth doing if
- You are approaching a raise and your AI claims have not been tested by anyone technical.
- You are scaling and cannot safely change a prompt or upgrade a model.
- Unit economics are unknown and the product is about to be priced.
- You depend entirely on one model provider with no abstraction or fallback.
- You want an honest read on whether anything you have built is defensible.
Do something else if
- You want help phrasing claims that will not survive diligence.
- You have no users yet. Get some; their queries are the evaluation set.
- You want a custom model where an API and good engineering would serve better.
- The product problem is a distribution problem that no technology addresses.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
Is our AI product actually defensible?
Prompts are not a moat and being early is a head start rather than a position. A data advantage is real when it accumulates from your own product usage, measurably improves the product, and cannot be bought or scraped — most claimed data moats fail that last test. Workflow integration and switching cost are genuine and consistently undersold by technical founders. So, increasingly, is a good evaluation harness, because knowing whether a change helps compounds.
When should we build an evaluation suite?
Now, whatever stage you are at. With fifty customers it is a week; with five thousand, across features that have drifted, it is a quarter. Startups defer it because it does not ship, and then find they cannot change anything safely at exactly the moment they need to move fastest. Your early users' real queries and corrections are the test set, and capturing them systematically costs almost nothing.
What will investors' technical diligence ask?
What is proprietary beyond the prompt; who owns the training data and under what basis; how performance is measured on held-out data against a baseline; the exception rate in production; inference cost per unit; what happens if the model provider changes; and who built it and whether they are still there. Weak answers cluster, and the absence of documentation is itself a finding — a company with real capability can usually show an evaluation harness within a day of being asked.
Should we train our own model?
Almost certainly not, and we will say so early. Unless you have data nobody else can obtain and a specific reason general models fail on your task, the engineering effort returns more when spent on evaluation, product and the data that accumulates from usage. Training your own model is a strategy that has to be earned by a specific constraint, not chosen as a default expression of seriousness.
Can you just tell us if we are being sold something we do not need?
Yes, and it is a legitimate short engagement. We will look at what is proposed, what it would take to build, and what it should cost. We charge for the assessment and take nothing contingent on what happens next, which is the same principle we apply doing diligence for investors — the conclusion has to be able to be no.
Related verticals
Organisations in startups usually share data, buyers or regulators with these. All fourteen are listed on the Technology & Telecom page.
AI for SaaS and Software Companies
In-product AI features with evaluation and unit economics — plus the provider question settled per product.
Read more →AI for Developer Tools Companies
Evaluation for code-facing features, benchmark honesty and unit economics — for buyers who will check.
Read more →AI for Data Centres and Cloud Providers
Cooling and energy optimisation, GPU scheduling and capacity — plus EU energy reporting from 500 kW.
Read more →Tell us what the problem looks like.
Thirty minutes, no charge, no deck. We will tell you whether this is an AI problem, a data problem, or a process problem — and we will say when the honest answer is to buy something rather than build it.