What an AI Feature Actually Costs to Build

Every agency answers this with a range so wide it is useless, because the honest answer depends on things they have not seen yet. So here is the structure underneath the number: what the four common shapes of AI work involve, which of them you are asking for, and what pushes each one up.

Costs below are in engineer-weeks rather than money. Rates differ by market and by who is doing the work, and a page quoting dollars would be wrong for most readers on the day they read it. Multiply by the rate you are actually comparing. These are our estimates from building this kind of thing, not an industry survey.

Four shapes of AI work

Almost every request we get is one of these, or two of them stacked. Naming which one you want is the single largest step towards a real number, and it is something you can do before talking to anyone.

Shape	What it does	To first production version
Answers from your own content	Staff or customers ask questions; it answers from your documents and cites them	4–8 engineer-weeks
Extraction and classification	Turns invoices, emails, tickets or forms into structured fields or categories	3–6 engineer-weeks
An agent that performs a task	Takes an action across your systems, not just produces text	8–16 engineer-weeks
A model inside your product	Runs on the user's device or your own servers, no third-party API	10–20 engineer-weeks

The bottom two are wider ranges for the same reason: both depend on things outside the AI. An agent is only as buildable as the APIs it has to act through, and an on-device model is bounded by the hardware you have decided to support.

What actually drives the price

None of these is the model. Model choice is a week of evaluation and then a line in a config file; if a proposal treats it as the central question, that is a signal about the proposal.

The state of your data. The single biggest variable. Clean, current, well-structured documents in one place is the cheap case. Four systems of record that disagree, scanned PDFs, and a wiki nobody has updated since 2023 is the expensive one — and the work is data work, which you would have needed anyway.
How accurate it has to be. There is a large gap between "drafts something a person checks" and "acts unattended". The second needs measurement, failure handling and a way to be wrong safely, and that is where the budget goes.
How many systems it touches. Each integration is its own authentication, its own rate limits, its own error cases. Two is routine. Six is a different project.
Whether anyone will own evaluation. If nobody on your side can say whether an answer was good, we have to build that apparatus first. It is worth doing and it is not free.
Where the data may go. "Nothing leaves our infrastructure" is a legitimate constraint and a design input. It usually means open-weight models you host, which trades some capability for control and moves hosting cost onto you.

The running cost people forget

A build estimate is not a budget. Three costs continue after launch, and only the first is usually in the plan.

Usage. Per request, scaling with volume. Cheap at pilot scale, which is why it surprises people at production scale. Worth modelling at 10× your pilot before you commit to an architecture.
Evaluation and monitoring. Quality drifts as your content changes and as providers update models underneath you. Something has to watch for that.
Provider churn. Models get deprecated on the provider's schedule. Plan for a few days of work a year to move, and avoid designs that make moving hard.

What a proof of concept should cost and prove

Two to four weeks. Longer than that and it is not a proof of concept, it is a project without a plan.

The important part is what it is for. A proof of concept should end in a decision, not a demo — and the way to guarantee that is to write down, before it starts, the number that makes it a success and what you will do if the number is not reached. "It should classify at least 85% of tickets correctly, and if it does not we stop" is a proof of concept. "See what AI could do for us" is a workshop.

It should also produce the thing you will still need afterwards: a small, real, labelled set of examples with the right answers. That test set outlives whatever model is current and is what makes the next decision cheaper.

Questions worth asking any vendor

1. What would make this cost twice your estimate?
2. How will we know it is working, in a number, and who measures it?
3. What does it cost per month at ten times our pilot volume?
4. What happens when the model you chose is deprecated?
5. Where does our data go, and what is retained?
6. What does the system do when it does not know the answer?
7. Who owns the code, the prompts and the evaluation set at the end?

The sixth is the most revealing. A system with no answer to it will invent something confidently, and that is how these projects lose the trust of the people who were supposed to use them.

When not to build

Three cases where we would tell you not to, because saying so early is cheaper for both of us.

The process is not written down anywhere. If no human can describe the rules, the project starts with the operations work, not with the AI.
It happens ten times a month. Automating a rare task rarely pays back the cost of maintaining the automation.
An existing product already does it. If your data is not the differentiator, buy it. We would rather tell you that than bill for rebuilding it.

How we work

We are a small team of engineers rather than an agency: you talk to the people writing the code, there is no account manager in between, and we are selective about what we take on. On the AI side that means LLM integrations, retrieval over your own content, agents, and deploying models you host yourself — alongside the .NET, Python, TypeScript and cloud work the rest of the studio does.

We also ship our own Windows software, including a text assistant that runs a language model entirely on the user's PC, so the on-device and privacy-constrained end of this is not theoretical for us.

Tell us what you are trying to build

Describe the problem rather than the solution — what someone does today, how often, and what it costs when it goes wrong. You will get a reply within one business day, with a scope and a number, or with a reason we think you should not build it.

Start a project

Frequently asked questions

How much does it cost to build an AI chatbot for my business?

For a chatbot answering from your own documents, budget four to eight engineer-weeks to a first production version, and expect the range to be set by the state of your content rather than by the AI. Multiply by whatever rate you are working with. Anyone quoting a figure before seeing your documents is quoting a template.

What makes one AI project cost three times another?

Usually the accuracy bar and the number of systems involved, not the model. Going from a demo that is right most of the time to something that is right often enough to act on unattended is where most of the budget goes, and it is spent on evaluation, edge cases and fallbacks rather than on prompts.

Should we build or buy?

Buy when what you need is a common capability and your data is not the differentiator. Build when the value comes from your own data, your own workflow, or a constraint an off-the-shelf product cannot meet — most often that the data may not leave your infrastructure.

What should a proof of concept cost and prove?

Two to four weeks, ending in a decision rather than a demo. Before it starts, write down the number that makes it a success and what happens if the number is not reached. A proof of concept with no failure condition will always succeed and will tell you nothing.

What does it cost to run once it is built?

Three things, and the first is the one people budget for: model usage per request, which scales with volume; monitoring and evaluation, which does not go away; and periodic work when a provider deprecates or changes a model, which happens on their schedule and not yours.

Can the data stay on our own infrastructure?

Yes, and it changes the design rather than ruling the project out. Open-weight models can run in your own environment or on the device. Expect to trade some capability for that, and expect the hosting and operations cost to move onto your side of the line.

How long before we see something working?

A rough version that handles the common case usually exists within the first two weeks. The remaining time goes into the cases that are not common, which is also where the difference between a demo and a product lives.