What drives the cost of a custom AI project?

What does the first quote leave out?

When a company plans a custom AI project, attention goes to the quote: what will be built, how long it will take and what the build costs.

That matters, but it skips the bigger question: what will the solution cost to run, review and keep useful over the next few years?

A custom AI solution keeps changing after launch. Your systems are updated, your processes shift, the models behind it improve or are retired, and staff find new things they want it to do. That is when the choices made at the start show their effect on cost.

Two companies can have a similar problem and a similar budget, yet one will pay little to keep its solution running while the other keeps needing specialist help for small changes. The difference rarely comes down to the skill of the builder. It usually comes from how well the work was understood before the build began: which steps were included, what the solution connects to, and who is expected to look after it.

How do scope and integrations affect the cost?

When an AI tool disappoints, the usual reaction is to buy a bigger plan or a more powerful model, hoping that spending more will fix it.

Sometimes it does. Often it is like fitting a bigger engine to a car with worn brakes.

Consider an example, a firm that wants an assistant to answer questions about its contracts. If the contracts sit in six systems, in different formats, with no agreed names, the build has to read, clean and reconcile all of it. Each extra source and each connection to a system, such as an email platform, a document store or a CRM, adds design, testing and upkeep. Scope grows quietly. A narrow solution that handles one contract type from one source can be built and checked quickly, while a broad one that touches everything costs far more and is harder to trust.

A better approach is to start with the work that matters most and connect only what it needs. Integrations are usually the largest hidden driver, because every system has its own access rules, formats and quirks. Fewer, well-chosen connections keep the first version affordable and make later additions easier.

The benefit goes beyond price. A smaller scope is quicker to test, easier to explain to staff and simpler to keep reliable.

How does usage change the running cost?

Usage is the cost that surprises people most, because it is invisible at the time of the quote.

Most AI solutions that use language models are billed by how much they are used. More requests, longer documents and more steps per task all raise the running cost. A solution that works well for ten people may cost very differently when two hundred use it every day, so volumes should be estimated up front.

Design affects usage too. A solution that sends a whole document to a model for a simple lookup uses far more than one that retrieves only what it needs. Good design keeps the bill in check.

Usage is therefore a design question as much as a pricing one. It should be estimated, monitored and capped from the start, with alerts when it moves.

Why does data readiness matter so much?

Data readiness decides how much of the budget goes on preparation rather than on the solution itself.

If your records are complete, consistent and accessible, a solution can use them straight away. If they sit in scattered files, scans and inboxes, someone must find, clean and organise them first.

This work can look like overhead, but it is often where the value is made. A solution is only as reliable as the information it reads, and fixing the data once helps every later project.

That is why we look at the data early. During the Embedded Week we see what exists, where it lives and how reliable it is, so the build plan reflects what is really there, not what everyone hopes is there.

What about human review?

Human review is a cost that is easy to forget. For any output that matters, a person checks the draft, corrects it and approves it. This is not a flaw. It is how quality, accuracy and accountability are kept.

The cost shows up in two places. First, the build must include the review steps, such as screens for approval, flags for low-confidence results and a clear record of who approved what. Second, the people doing the reviewing need time. If a solution saves an hour of drafting but adds forty minutes of checking, the gain is smaller than it seems, so the review should be designed to be quick.

The amount of review depends on the stakes. A summary for internal use needs a light check. A customer letter or a financial figure needs more. In regulated sectors, AI supports professional judgement and does not replace it, and the rules differ by jurisdiction, so the level of review should be set with your own professionals.

Review is not waste. Leaving it out saves money for a short time and then costs far more when errors reach clients.

What do training and adoption add to the cost?

A solution that nobody uses delivers no value, however well it is built. Training and adoption are part of the cost of a project, not an extra to be squeezed out.

Staff need to know what the solution does, what it does not do, when to trust it and when to check. They also need time to change how they work. A short, practical session for each team, using their own examples, goes much further than a general demonstration.

Change management is cheaper when it starts early, with the people who will use the solution.

Two examples show the range. A small team with one clear workflow may need a short training session and a written guide. A larger organisation with several departments will need sessions for each group, named champions in each team, and a way to collect feedback and fix problems. Neither is wrong. The cost differs because the number of people and the amount of change differ.

In both cases, the training should be planned and priced at the start, not added at the end.

What does upkeep look like after launch?

Upkeep is the cost that continues after launch. It is easy to overlook, because nothing seems wrong until something changes in your business.

Suppose a supplier changes its file format, a model is updated and behaves differently, or your team adds a new step to its process. Someone has to notice, adjust and test. If nobody owns upkeep, small issues grow until the solution is no longer trusted. Monitoring, updates and occasional improvements are all part of the real cost.

A solution built to be maintained is cheaper to keep. It has clear documentation, logs that show what happened and settings that your team can change without rewriting anything. That makes updates quick and keeps you from depending on one person's memory.

Upkeep can be handled by your own team after training, by the builder, or by a mix of both. Decide which before launch.

Why start with discovery?

Developers like to talk about models, vectors and pipelines. No business buys a custom AI project to own any of these. It buys time back, fewer errors, faster replies and more consistent work.

Cost therefore only makes sense when set against a clear result for the business.

A review step is worth paying for when it protects quality. An integration is worth paying for when it removes copying and waiting that costs more than it does to build.

A larger scope is justified only when it removes more work than it adds in cost, upkeep and risk. Being technically impressive is not a reason. Be wary of any plan that cannot say which work it removes.

Put simply, each part of the project should earn its place by saving time, cutting errors, speeding up responses or making future changes easier.

Who for?

We never begin by choosing a model or a tool. We begin by seeing how your people work.

That is the Embedded Week. We sit with your team for a week and watch the tools, the hand-offs, the copy-pasting and the waiting. We map where the time goes, and only then decide what is worth building.

This may seem far removed from cost, yet it settles most of the factors above before any money is spent on a build.

Next, we build a custom AI solution for your company specifically, not a generic product, and train your team to run it. Sometimes an off-the-shelf tool is enough, and we will say so. Our aim is a scope you can understand and a cost you can predict.

A good project plan is rarely noticed, since its value is measured by the surprises that never arrive.