Should your startup build AI features?

Deciding should we add AI to our product is a question most founders ask under pressure — from investors, from a competitor's launch, or from a general sense that not having AI is becoming a position that needs defending.

That pressure is real. It is also a poor basis for a product decision, and users are noticeably good at spotting features that exist for the pitch deck.

When AI is genuinely the right tool

The honest test is whether the task is fuzzy. Language, judgement, unstructured input, many valid answers.

Good candidates:

• Summarising long or messy documents
• Extracting structured data from unstructured input — emails, PDFs, transcripts
• Answering questions over your own content
• Drafting things a user then edits
• Classifying cases where the rules have too many exceptions to enumerate

Poor candidates, where something cheaper is better:

• Anything expressible as rules — use rules; they are faster, free and auditable
• Exact lookup — use a database
• Finding known items — use a search index
• Calculation — use arithmetic
• Anything where being wrong is unacceptable and unverifiable

What it actually costs to build

The prototype takes days. The shippable feature takes months. That gap is not incompetence — it is the work the prototype did not have to do:

• Evaluation. A set of realistic inputs with acceptable outputs, run on every change. Without it you cannot distinguish an improvement from a regression, and you will make both.
• Retrieval quality. If the feature works over your own data, this dominates output quality. Chunking, ranking and freshness are the actual engineering.
• Failure handling. Validation, fallbacks, and a defined behaviour when the model is unavailable or wrong.
• Cost and latency control. Instrumented per request, against a budget you set upfront.
• Interface design for wrongness. Usually the difference between a feature users trust and one they abandon.

Plan for the model call to be a small fraction of the effort.

The cost model is different

Most software has near-zero marginal cost. AI features do not — you pay per request, roughly in proportion to how much text is involved.

This has real consequences:

• A free tier can become genuinely expensive
• Heavy users cost more than light ones, which your pricing may not reflect
• Costs scale with success, which is an unusual position to be in
• A prompt change can move your bill substantially

Work out the per-request cost before you build, and set a ceiling as a requirement alongside the functional ones. Then instrument it from the first deployment, because the alternative is finding out at the end of the month.

The failure mode that costs customers

Being wrong is a property of these systems, not a bug to be eliminated. The question is what the user experiences when it happens.

Acceptable, in rough order of effort:

1. Structural validation — if the output should parse, reject what does not and retry
2. Visible sources — users forgive a wrong answer they can check
3. Confidence signals — flag the cases the system is unsure about
4. Trivial correction — an edit button is worth more than a few points of accuracy
5. Human approval — for anything consequential

Unacceptable: silent wrongness inside a workflow that assumed correctness. That is how an AI feature costs you customers rather than money.

A worked LLM cost per request calculation

Unit economics stay abstract without real numbers, so here is a worked calculation for a genuinely common feature shape: an AI-powered document summariser inside a B2B SaaS product.

Inputs. Average document length: 3,000 words, roughly 4,000 tokens. Summary output: 200 words, roughly 270 tokens. Using a capable mid-tier hosted model at roughly $3 per million input tokens and $15 per million output tokens — broadly representative of mainstream API pricing at the time of writing, though the specific numbers move quickly and are worth re-checking against current rates.

Per-request cost. Input: 4,000 tokens × $3/million = $0.012. Output: 270 tokens × $15/million = $0.004. Total: roughly $0.016 per summarisation — under two cents.

That sounds trivial, and the trap is stopping there. At 1,000 summaries a day across your customer base, that is $16 a day, or roughly $480 a month — genuinely negligible against most SaaS revenue. At 50,000 summaries a day, which is a realistic number once the feature is popular and embedded in a daily workflow across a larger customer base, the same unit cost becomes $800 a day, or roughly $24,000 a month. The unit economics did not change; the volume did, and volume is exactly what you should expect if the feature succeeds.

The corrective is not to avoid the feature — it is to price for the volume you hope for, not the volume you have today. Concretely: decide at what usage tier this cost needs a corresponding price increase or usage cap, build the per-request cost tracking from day one so the crossover point is visible before it becomes a crisis, and consider a cheaper model for a first-pass summary with an upgrade path to a more capable one only when a user explicitly asks for more depth — a pattern that can cut the effective cost per request substantially without a noticeable quality loss for the majority of requests.

AI product strategy: sequencing across a roadmap, not just one feature

Most of this piece has evaluated a single AI feature in isolation, which is the right unit for a build decision but the wrong unit for a broader AI product strategy. A roadmap with several candidate AI features needs a sequencing logic beyond "build the ones that pass the fuzzy-task test," because passing that test is necessary but not sufficient for deciding what to build first.

The sequencing that tends to work: start with the feature where the evaluation set is easiest to build, because early feedback on quality compounds — a team that gets fast, reliable signal on their first AI feature builds the muscle to evaluate the second and third faster. Prioritise features touching data you already have clean and well-structured, since retrieval quality is usually the dominant factor in output quality, and features over messy or scattered data will underperform regardless of how good the model is. And deprioritise features whose failure mode is severe and hard to make visible to the user — anything touching money, legal commitments or irreversible actions — until the team has shipped and learned from lower-stakes features first.

This produces a different order than ranking purely by expected user value, which is the instinct most roadmaps default to. A feature with modest expected value but excellent data and an easy evaluation set is often the right first move, precisely because it teaches the team how to do this well before the stakes are higher.

A reasonable sequence

1. Name the task. One specific job a user currently does manually and dislikes.
2. Check the cheaper option. Would rules, search or better interface design solve it? If so, do that.
3. Prototype in a week. Establish that the capability exists at all.
4. Build the evaluation set before building the feature. Thirty realistic examples is enough to start.
5. Set cost and latency ceilings. Alongside the functional requirements.
6. Ship to a small cohort. Real usage finds failure modes your evaluation set will not.
7. Measure quality, cost and the support queue together.

The honest answer

Build an AI feature when there is a fuzzy task your users currently do by hand and dislike, when you can measure whether the output is good, and when the unit economics work.

Do not build one because a competitor has one. That reasoning produces features that exist to be mentioned rather than used, and users can tell the difference immediately.

Common AI features for startups, evaluated honestly

Running a handful of the most commonly requested AI features for startups through the framework above:

AI chatbot for customer support. Passes the fuzzy-task test if support queries are genuinely varied and judgement-based; fails it if most queries are the same five questions, which a well-designed FAQ or decision tree answers more reliably and far more cheaply. Worth checking your actual support ticket distribution before assuming this is the right feature. Where it does pass, the guide on why AI projects run over covers the gap between a support-bot demo and one that survives real ticket volume.

Smart search over product content. A strong candidate when the content is genuinely large and unstructured — documentation, long-form articles, varied user-generated content. A weak candidate when the underlying catalogue is small and well-tagged, where conventional faceted search performs as well for a fraction of the cost and complexity.

AI-generated first drafts. Consistently one of the strongest categories, because the failure mode is naturally forgiving — a mediocre draft a user edits is still useful, unlike a wrong answer presented as fact. This is why drafting features tend to ship successfully more often than fully automated decision-making features covering similar ground.

Automated data extraction from documents. Strong when documents are semi-structured and the extraction feeds a workflow with a human review step; weak when extracted data flows directly into an automated decision with no review, because extraction errors in that configuration compound silently downstream.

Predictive scoring or prioritisation. Frequently requested, frequently oversold. Strong when the score is presented as one input among several a human weighs, weak when the score silently determines an outcome — the difference between a lead score that sorts a list a salesperson still reviews, and a lead score that automatically excludes leads from ever being seen.

Whichever of these you build, the build-versus-buy question is worth asking explicitly first — build vs buy covers when the underlying AI capability itself should come from a vendor rather than be built, which for most of the categories above is more often than founders initially assume.

A final sanity check before committing

One last test worth applying to any AI feature before it goes on a roadmap: describe it to someone unfamiliar with the product without using the word "AI" at all. "It reads the document and pulls out the key dates" survives that test. "It uses AI to enhance the workflow" does not, because it describes nothing about what actually happens for the user. A feature that only makes sense with the word "AI" attached is usually a feature that exists to be mentioned rather than to solve a specific, nameable problem — and that distinction is worth applying honestly before committing engineering time to it.

The pattern across every feature that succeeds

Across the categories evaluated above, the successful examples share one property regardless of which category they fall into: the team could name, precisely, what a good outcome looked like before they built anything. Not "customers will like it" — a specific, checkable definition of success that the evaluation set and cost ceiling both derive from. Teams that can articulate this before writing any code consistently ship features that survive contact with real users; teams that cannot tend to discover, expensively, that they were building toward a target nobody had actually defined.

In one sentence

Build an AI feature when a real user has a real, fuzzy problem you can measure yourself solving well and affordably — and treat every other reason, including competitive pressure, as a prompt to investigate rather than a mandate to ship.

A practical next step

Before greenlighting any AI feature, get one page written that answers four questions in plain language: what specific task does this replace or improve, how will we know if the output is good, what does it cost per use at ten times our current expected volume, and what happens when it is wrong. If nobody can produce that page in an afternoon, the feature is not ready to be built yet, regardless of how compelling the initial prototype looked or how much pressure exists to ship something with "AI" in the release notes.

The pattern that repeats

Across every category of AI feature this piece has evaluated, one pattern holds without exception: features designed around a specific, nameable user frustration outperform features designed around a capability the team wanted to showcase. This is not a claim unique to AI — it is the oldest advice in product development, applied to a technology exciting enough that teams sometimes forget to apply it. The AI part of the decision is usually the easy part; the product judgement underneath it is where the real work, and the real risk, actually lives.

One more thing worth saying

The bar here is not perfection — it is honesty about what a feature is actually for, checked against real evidence rather than enthusiasm. That bar is achievable for almost any team willing to apply it before committing engineering time.

The founders who get this right

Founders who consistently make good AI feature decisions share a habit: they treat every enthusiastic pitch for a new AI capability, including their own, with the same scrutiny described throughout this piece — not as a special exception because the idea feels exciting, but as an ordinary product decision that happens to involve a newer technology.

Last word

Build for the user, not for the pitch deck.