How startups should actually use AI

What LLMs are good and bad at

Most bad AI product decisions come from a wrong model of the capability, so it is worth being blunt about the shape of it.

Genuinely good at: transforming text from one form into another — summarising, rewriting, translating, extracting structure from prose. Classifying and routing. Drafting something a human will edit. Answering questions when the answer is in front of it. Writing code against a clear specification. Conversational interfaces over things that previously needed a form.

Genuinely bad at: anything requiring guaranteed correctness. Arithmetic and precise counting. Knowing what it does not know. Consistency across many independent calls. Long chains of dependent reasoning without verification. Anything where being confidently wrong is worse than saying nothing.

The single most useful reframing: an LLM is a very capable junior employee with no memory, infinite patience, no judgement about when to escalate, and the inability to tell you when it is out of its depth. Design the product around that and you will make good decisions. Design it around "it is intelligent" and you will ship something that demos brilliantly and erodes trust in production.

Is your problem actually AI-shaped?

The strongest LLM products share a shape, and recognising it early is worth more than any implementation detail.

The work is currently done by a human reading and writing text. Support triage, document review, data entry from unstructured sources, research summarisation. There is an existing cost you can measure and an existing quality bar you can compare against — which means you can prove value rather than argue for it.

Volume is high and individual stakes are low. Ten thousand documents where a 5% error rate costs little is a far better first product than a hundred documents where one error is catastrophic.

Verification is cheap. The user can tell at a glance whether the output is right. This is why drafting tools work so well: reading a draft and fixing it is much faster than writing from scratch, so even mediocre output creates value.

The input is messy and the output is structured. This is the transformation LLMs are unreasonably good at, and it is exactly where traditional software was weakest. Parsing arbitrary invoices into a schema was a hard problem for thirty years and is now largely a solved one.

The 0 to 1 ladder

Climb in order. Each rung costs roughly ten times the one below it, and most products should stop at rung two or three. The most common and most expensive mistake in AI startups is starting three rungs too high.

Rung 0 — Wizard of Oz. Humans do the work behind the interface. No model at all. You learn what users actually ask, what a good answer looks like, and whether anyone wants this — all of which you need before you can build anything. It costs days. Teams skip it because it feels like cheating, and then spend three months building the wrong thing.

Rung 1 — Prompting. A good model, a well-structured prompt, few-shot examples, a schema on the output. Genuinely more capable than most people expect, and the fastest path to something real. Ship this and find out what breaks.

Rung 2 — Prompting plus retrieval. Add your own knowledge. This is where most successful AI products live permanently. It handles the "the model does not know our stuff" problem, which is the actual problem in most business use cases. See the RAG deep dive for how to do it properly.

Rung 3 — Orchestration. Multiple calls, routing, tools, verification steps, a human in the loop where it matters. More capability, more failure modes, more latency, more cost. Justified when a single call demonstrably cannot do the job — which you can only know because you tried.

Rung 4 — Fine-tuning. When you need consistent behaviour, format or style that prompting cannot reliably produce, and you have the data to teach it. Real ongoing cost: data curation, a training pipeline, evaluation, and the obligation to redo it when the base model is deprecated.

Rung 5 — Training your own model. Almost never correct for a startup. The exceptions are genuinely narrow: a domain where no general model has competence, or a cost structure at enormous scale where the amortised training cost beats per-call pricing. If you are considering this in your first two years, the burden of proof is high and should be met with numbers.

The discipline is to climb only when the rung below has demonstrably failed, measured on your evaluation set rather than on a feeling that the current approach is unsophisticated.

Build, buy or fine-tune

This decision gets made emotionally more often than analytically. The tree below is the analytical version.

Two rules that resolve most real cases.

Buy unless it is your differentiator. If the capability is not what customers choose you for, buying it is almost always correct. Engineering time is your scarcest resource and rebuilding a commodity spends it on something no customer will ever notice.

Build where your data or workflow is the advantage. If you have proprietary data, a proprietary process, or deep integration into how customers work, that is the part to build, because it is the part nobody else can copy.

Unit economics

AI features have a cost structure most software founders have never dealt with: marginal cost per use that does not fall to zero with scale. Traditional software gets cheaper per user as you grow. An LLM feature costs roughly the same on the millionth request as the first. If your pricing assumes software margins and your costs behave like a utility bill, growth makes the problem worse rather than better.

So work out the arithmetic before you launch, not after.

# The model. Fill in your own numbers; the structure is what matters.

tokens_in   = system_prompt + retrieved_context + user_input
tokens_out  = response_length

cost_call   = (tokens_in  / 1e6) * price_in
            + (tokens_out / 1e6) * price_out

# Calls per outcome is the term everyone forgets.
calls       = 1                      # the happy path
            + retries                # failures you pay for twice
            + rerank_calls           # if reranking with an LLM
            + agent_steps            # multiplies everything

cost_outcome = cost_call * calls / success_rate

# success_rate is the whole game. At 60% success you pay for
# 1.67 attempts per useful result. Quality IS cost.

I am deliberately not printing provider prices. They change, and stale prices are worse than none. Put today's rates into that structure and you have a number you can defend.

The three numbers to track

Cost per successful outcome. Not per request, not per token. A cheaper model with a lower success rate that triggers retries and escalations can be more expensive overall, and only this denominator shows it.

Cost as a percentage of revenue for that feature. If a feature priced at $20 a month costs $14 to serve for a heavy user, you do not have a product, you have a subsidy. Find that out in month one.

The heavy-user tail. Usage is always long-tailed. Model your 99th-percentile user, not your median. Flat-rate pricing plus unbounded AI usage plus one enthusiastic customer is a recognised way to lose money at scale.

Levers, in order of return

Route by difficulty. Most requests do not need the largest model. Classify and send the easy majority somewhere cheaper, with your eval suite confirming quality holds. This is usually the single biggest win available and it is often a week of work.

Cache the static prefix. A long system prompt re-sent on every request is billed every time unless cached. On a chat product this alone can be a substantial fraction of spend.

Cut context. Retrieving ten chunks when five perform identically doubles input cost for nothing. Measure the recall curve rather than assuming more is safer.

Cap output. Directly proportional savings, and shorter answers are often better product anyway.

Cache answers. On support-style products a meaningful share of questions repeat verbatim.

Batch what is not interactive. Asynchronous tiers are substantially cheaper and most background work has no latency requirement.

Eval-first development

This is the single highest-leverage practice in AI product work and the most commonly deferred, because it feels like infrastructure when you want to be shipping features.

The argument is simple. Without evaluation you cannot tell whether a change made things better. You will change a prompt, read three outputs, decide it seems better, ship it, and discover two weeks later that something else regressed. Multiply that across a team and you get a product that changes constantly and improves randomly.

What to build, minimally: fifty real examples with a defined notion of a good response. Real ones, from users or from the humans currently doing this work — not examples you invented, which will be shaped like your assumptions. A script that runs them and produces a number. That number in CI.

Fifty examples and a script is a day of work. It changes the character of everything afterwards: you can refactor prompts without fear, compare models honestly, and answer "did that help?" with evidence.

Order of checks. Start with what code can verify — schema validity, required fields, length, forbidden content, citation ids that actually exist. These are free and deterministic. Only use a model to judge the genuinely subjective remainder, and when you do, calibrate it against human labels and report the agreement. An uncalibrated judge produces confident numbers that mean nothing.

Include the cases that should fail. Questions your system cannot answer, inputs that should be refused, adversarial content. A system that never abstains is not correct, it is untested.

For the full treatment, see evaluation engineering.

Moats, and what is not one

What actually defends a business is mostly what defended businesses before, with one addition.

Proprietary data that compounds. Not just data you have — data that accumulates from usage and makes the product better in a way competitors cannot replicate without the same usage. The test: does your product get measurably better for every user as more people use it? If yes, you have a flywheel. If your data is a static corpus you licensed, it is an asset, not a moat.

Workflow depth. When you are the system of record, when you hold the integrations, when switching means retraining a team and migrating history — that is expensive to leave. Deep, unglamorous integration into how customers actually work is the most reliable moat available to an application company, and it is mostly not an AI problem at all.

Distribution. Owning the channel, the relationship, or the regulatory approval. Frequently decisive and frequently dismissed by technical founders as not real engineering.

Evaluation and domain knowledge. An underrated one. Knowing precisely what good looks like in a specialised domain — having built the golden set, learned the edge cases, encoded the expert judgement — is genuinely hard to copy, because it came from work rather than from a model.

Trust and brand in a high-stakes domain. In medicine, law or finance, being the one people trust is a moat that takes years to build and cannot be bought with a better model.

Who to hire, and when

The most common early hiring mistake is hiring a research profile for a product problem.

Pre-product-market-fit. You need product engineers who can call an API and iterate fast, not ML specialists. At this stage the hard problems are what to build and whether anyone wants it, and those are not model problems. A strong generalist who is comfortable with ambiguity will outperform a researcher here.

Early product, real users. Now hire your first dedicated AI engineer — someone who has shipped LLM features to production, not someone who has trained models. The skills you need are evaluation, retrieval, prompt discipline, cost control and observability. Ask them about a system that failed in production and listen for whether they can name the diagnostic they used.

Scaling. Add infrastructure and data engineering, usually before you add more modelling. The constraint at this stage is almost always pipeline reliability and iteration speed, not model quality.

A research hire makes sense when you have a genuinely novel problem, data nobody else has, and the runway for a project measured in quarters with uncertain output. Before that, a researcher will be frustrated and you will be paying a premium for skills the job does not use.

The role people forget: someone who owns the domain and the evaluation set. Often not an engineer — a domain expert who can say definitively what a good output looks like and maintain the golden set. On specialised products this person is frequently the difference between a system that works and one that does not, and they are almost never in the original plan.

How AI startups fail

The demo-to-production gap. The demo worked because you tried it on examples you chose. Production traffic contains the malformed, the ambiguous, the adversarial and the very long. A system at 90% on curated examples is often at 60% on reality, and the last stretch costs more than everything before it. Get real traffic in front of it early, even at small volume, precisely so this arrives as a surprise in week three rather than month six.

Eval debt. Skipping evaluation to move fast, then reaching a point where nobody can change anything confidently. It compounds exactly like technical debt and is harder to pay down, because building an evaluation set retroactively means labelling history you no longer remember.

Prompt spaghetti. Prompts scattered through the codebase, edited by anyone, versioned by nobody, with no tests. A production dependency nobody controls. Treat prompts as code from day one: version them, review them, test them.

The 80% wall. Getting to 80% is fast and feels like progress. Every point after that is exponentially harder, and many use cases need 95% to be useful at all. Ask early what accuracy makes this valuable, and be honest about whether the gap between there and 80% is a sprint or a company.

Building for the model instead of the user. Shipping a chat box because the technology is conversational, when the user wanted a button. The model is an implementation detail; a great many AI features would be better products with no visible AI in them at all.

Ignoring latency. A correct answer in fourteen seconds loses to a decent answer in one. Streaming helps because it changes perceived latency, but an architecture with five sequential model calls has a floor you cannot stream past.

Unbounded scope. "It handles anything" means it is mediocre at everything and you cannot evaluate it. Narrow, excellent and evaluable beats broad and unreliable, especially early, when what you need most is one group of users who genuinely depend on you.

Not planning for model deprecation. The model you launched on will be deprecated. If you have no evaluation suite, migrating is a leap of faith; with one it is an afternoon. This alone justifies the eval work.

Privacy, vendors and risk

Know where the data goes. Before sending customer data to any provider, know the retention policy, whether inputs may be used for training, where processing happens geographically, and what the enterprise terms change. These differ by provider and by tier, and enterprise agreements typically offer no-training and zero-retention options that consumer tiers do not.

Your customers will ask. In B2B, a security questionnaire asking which subprocessors see customer data is routine, and "we send it to a model API" needs to be an answer you have prepared with a data processing agreement behind it, not a conversation you have for the first time during a deal.

Minimise before sending. Redact what the model does not need. Pseudonymise identifiers. The cheapest way to protect data is not to transmit it.

Data residency is a real constraint in the EU and increasingly elsewhere. Check regional processing options before promising anything.

Injection is a product risk, not just a security one. If you process user-supplied or retrieved content, that content can attempt to instruct your model. The dangerous combination is untrusted content plus tools plus actions with side effects. Keep those separated and never let retrieved text reach a tool-calling path unexamined.

Vendor concentration. Single-provider dependency is a real risk — pricing changes, deprecations, rate limits, outages, policy changes that make your use case non-compliant. You do not need multi-provider on day one, but you should keep the model behind an interface so switching is an afternoon rather than a rewrite. And your evaluation suite is what makes a switch decidable.

Be careful what you claim. Marketing copy asserting accuracy or capability can become a contractual and regulatory commitment. Claims about automated decision-making in particular carry obligations in several jurisdictions. Say what it does; avoid saying it is always right.

A 90-day plan

For a team adding AI to an existing product, or building an AI product from zero. Adjust the dates; keep the order, because each phase depends on the last.

Days 1–14 — Decide what you are building

Pick one narrow use case with a measurable current cost. Interview five people who do that work now, and collect fifty real examples of inputs and good outputs while you do. Run a Wizard of Oz version if you can. Write down what accuracy would make this genuinely useful — that number governs everything downstream. Decide explicitly against the alternatives you considered.

Days 15–30 — Build the ruler before the thing

Turn the fifty examples into an evaluation set with a defined notion of a good response. Write the programmatic checks. Build the simplest possible version — prompt only — and measure it. You now have a baseline, and often a surprise: the simple version is frequently closer than expected.

Days 31–60 — Get it to useful

Work the errors rather than the architecture. Read fifty failures and categorise them; the distribution tells you what to fix, and it is rarely what you assumed. Add retrieval only if the errors are knowledge errors. Add orchestration only if a single call demonstrably cannot do it. Measure after each change. Put it in front of ten real users under supervision.

Days 61–90 — Make it a product

Instrument cost per successful outcome. Add tracing so any request can be reconstructed. Put the eval suite in CI. Define the failure path — what the user sees when the system cannot answer, and how they escalate. Write the runbook. Ship to a wider group and watch the implicit quality signals, especially rephrase-after-answer.