We have a list of AI features we want. Where do we start?

By cutting the list. Most product teams arrive with six to eight ideas, and the first piece of work is choosing the one or two worth building — ranked on value to the user, effort to build, and what a wrong answer costs in that particular place. Shipping two features people use beats shipping eight that sit behind a menu, and it protects the running cost as well.

Will this make our product feel slow?

It should not, and that is a design decision rather than luck. Responses stream so text appears as it is produced instead of after a pause, the parts of the prompt that never change are cached, and work that does not need the largest model does not get it. Where a feature genuinely takes time, it runs in the background and tells the user when it is ready.

What happens when the model is unavailable or returns something odd?

Three cases get defined behaviour before launch — the model errors, the model is slow, and the model returns something that does not match the expected shape. In every one of them the feature degrades and the rest of your product keeps working. A model failure should never be able to break a page.

What will this add to our monthly bill?

We give you a per-user, per-month figure before the feature is built, based on how often you expect it to be used and how much text each use sends. That number frequently changes which feature gets built, and occasionally kills one. It is a far better conversation to have in week one than after the first invoice.

Do you work inside our codebase?

Yes. This is the service in this category where the work happens in your repository, in your stack and to your conventions, behind a feature flag so it reaches a small share of users first. We work to whatever review process you already run rather than around it.

Can our own developers maintain it afterwards?

That is the intended outcome, and it is worth paying for explicitly. Handover covers how the prompts are structured and why, how to change one safely, what the logging shows, and where the cost controls are. Teams that skip this end up unable to change a prompt without calling somebody, which is a bad position to be in.

AI & Machine Learning

AI features inside a product people already use

Summarising, drafting, classifying and better search added to your existing application — built in your stack, behind a flag, with the per-user running cost worked out before anything is written.

From: $1,500–$20,000
Typical time: 3–10 weeks
Usually bought by: SaaS products

What this is actually bought to fix

Two things bring a software company here and they pull in different directions. The first is competitive — every rival has added the words to their homepage, customers have started asking, and there is a product decision that cannot be postponed much longer. The second is better founded: a feature that removes real time from a user's day reduces churn, and in a subscription business a small movement in churn is worth more than almost any new feature.

Either way the team usually has a working product and capable engineers. What they do not have is anyone who has run a language model in production, and they do not want to spend a quarter finding out where the sharp edges are. The sharp edges are rarely in getting a response back — that part takes an afternoon. They are in what happens when the response is malformed, when the model is slow at the wrong moment, and when a feature that cost a few cents to demonstrate meets four hundred users pressing it five times a day.

How the build runs

Cut the feature list down to what is worth building. Each candidate is scored on value to the user, effort, and what a wrong answer costs where it appears. A wrong summary at the top of a dashboard is an annoyance; a wrong classification that routes a support ticket is a customer problem. Three to five days.
Decide where it lives in the interface. Whether it runs on demand or on a schedule, what the user sees while it works, and what they see when it has nothing useful to say. This is a product decision and it is made before any prompt is written. Two to four days.
Build the layer inside your backend. Your server calls the model; the browser never does and never holds a key. Structured responses are validated against a schema and mapped onto your existing data model, with a retry and a defined fallback when validation fails. One to two weeks.
Write the prompt and pin the output shape. Role, task, the exact response format, an explicit length limit, and worked examples. The length limit is not a style preference — generated text costs several times what supplied text costs, so a sentence capping the response is also a line on the invoice. Three to five days.
Build the cost and failure behaviour. Streaming, timeouts, caching for the fixed part of every prompt, per-user limits, and routing so that classification and extraction work runs on a small fast model while only the genuinely hard requests reach a large one. The gap between the largest and smallest models is a factor of twenty or more, which makes routing the single largest lever on your bill. One week.
Ship behind a flag, to a fraction of users first. A small percentage, watched in the logs — what people actually do with it, what it costs in practice, where it produced something useless — then widened. One to two weeks.

Typical tooling is whatever you already run, plus the model API, the Vercel AI SDK where the front end is React, a schema validator such as Zod or Instructor for structured responses, Langfuse for per-call logging and cost attribution, and your existing feature flag system.

What changes the quote

How many features, and how far apart they are. One well-chosen feature sits at the bottom of the range. Three features touching different parts of the product, each with its own data path and failure behaviour, sits near the top.

The state of the product you are adding to. A modern codebase with a clean data layer is quick to work in. An older application where the data needed for the feature has to be assembled from three places first turns a two-week job into a six-week one, and that assembly is the real work.

Whether your team is being trained as part of it. Handover that leaves your developers able to change prompts, read the logs and adjust the cost controls is a genuine piece of work with its own line in the quote. It is worth buying and it is not free.

Where these go wrong

The feature is built before anyone works out what it costs per user. A summarise button that sends the entire project history with every press costs a few cents each time, which is nothing in a demonstration. Four hundred users pressing it five times a day turns that into a recurring monthly bill of the same order as the one-off fee that paid for building it. Write the per-user monthly number down first and show it to the person paying, because it sometimes changes the design and occasionally cancels the feature.

The model's output is trusted to have the right shape. It usually does, which is exactly what makes this dangerous — the code works for weeks and then one malformed response reaches a component that expected a field to exist. Every structured response is validated against a schema, with a retry and a defined fallback, before it is allowed anywhere near your interface.

Everything is routed to the largest available model. Deciding whether a ticket is a complaint or an order does not need the same model as writing a project summary, and the price difference between the two ends of the range is a factor of twenty or more. Classification, extraction and routing belong on a small fast model, which is also quicker — so the cheaper choice is usually the better user experience as well.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

We have a list of AI features we want. Where do we start?: By cutting the list. Most product teams arrive with six to eight ideas, and the first piece of work is choosing the one or two worth building — ranked on value to the user, effort to build, and what a wrong answer costs in that particular place. Shipping two features people use beats shipping eight that sit behind a menu, and it protects the running cost as well.
Will this make our product feel slow?: It should not, and that is a design decision rather than luck. Responses stream so text appears as it is produced instead of after a pause, the parts of the prompt that never change are cached, and work that does not need the largest model does not get it. Where a feature genuinely takes time, it runs in the background and tells the user when it is ready.
What happens when the model is unavailable or returns something odd?: Three cases get defined behaviour before launch — the model errors, the model is slow, and the model returns something that does not match the expected shape. In every one of them the feature degrades and the rest of your product keeps working. A model failure should never be able to break a page.
What will this add to our monthly bill?: We give you a per-user, per-month figure before the feature is built, based on how often you expect it to be used and how much text each use sends. That number frequently changes which feature gets built, and occasionally kills one. It is a far better conversation to have in week one than after the first invoice.
Do you work inside our codebase?: Yes. This is the service in this category where the work happens in your repository, in your stack and to your conventions, behind a feature flag so it reaches a small share of users first. We work to whatever review process you already run rather than around it.
Can our own developers maintain it afterwards?: That is the intended outcome, and it is worth paying for explicitly. Handover covers how the prompts are structured and why, how to change one safely, what the logging shows, and where the cost controls are. Teams that skip this end up unable to change a prompt without calling somebody, which is a bad position to be in.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about LLM integration into a product All AI & Machine Learning services