Why It’s Hard to Quote Blind
When someone asks what an AI project costs, they usually expect a number the way you would get one for a new laptop or a fixed piece of furniture. But an AI project is not a product off a shelf. It is a system you commission for your specific processes, your data, and your existing software landscape. Two companies can ask for “an AI that handles customer emails” and end up with quotes that differ by a factor of five — not because someone is padding the bill, but because the two situations are genuinely different.
The key insight is this: the price tracks scope, data readiness, integration depth, and how reliable the system has to be. It does not track “the AI” itself. The model at the centre is, in most cases, a commodity you rent by the call. What you pay for is everything around it — the work of connecting it to your systems, feeding it the right data, constraining what it can do, and making it dependable enough to run unattended.
This is why a demo is cheap and a production system is not. A convincing prototype that answers questions from a handful of documents can be built in days. It looks almost finished. But a demo only has to work once, in front of a friendly audience, on hand-picked inputs. A production system has to work every day, on the messy inputs real users send, with real consequences when it is wrong, and it has to keep working for years as your data and your software change around it. Most of the cost lives in that gap between “works in the demo” and “safe to leave running.”
The Real Cost Drivers
If you want to estimate a budget before any conversation, it helps to know which factors actually move the number. In our experience there are six that matter most. None of them is “which model you use.”
Number of use cases
One clearly defined task — say, drafting replies to a specific category of support ticket — is a contained project. Ten tasks are not ten times harder, but they are not one project either. Each use case brings its own data, its own edge cases, and its own definition of “correct.” The single biggest way to keep a first project affordable is to resist bundling. Start with one process, prove it, then extend.
Data quality and availability
AI systems are only as good as the data they can reach. If the relevant information sits in clean, accessible databases, the work is straightforward. If it lives in scanned PDFs, inconsistent spreadsheets, or three systems that disagree with each other, a large part of the project becomes data preparation before the AI does anything at all. Poor data readiness is the most common reason a quote comes in higher than the client expected.
Number of systems to integrate
An AI that only reads and writes text in a chat window is cheap. An AI that pulls a customer record from your CRM, checks stock in your ERP, and writes the result back into a ticketing system touches three integrations — each with its own authentication, its own quirks, and its own failure modes. Integration depth is often the single largest line item, because this is real software engineering, not prompting.
On-premise vs. cloud
Running on cloud APIs is faster and cheaper to set up. Running on your own infrastructure — because the data cannot leave the building — adds work: hosting an open model, sizing the hardware, and operating it. On-premise is the right answer for sensitive data, but it is an honest cost premium, not a free preference.
Compliance and audit needs
If the system operates in a regulated context, or simply needs to be auditable, you pay for traceability: logging every decision, documenting how data is handled, and building the controls that let you prove what happened. This is invisible in a demo and unavoidable in production.
The reliability bar
“Right most of the time” and “safe to run without a human checking” are very different targets, and the distance between them is expensive. The last stretch — handling rare inputs, catching its own mistakes, failing gracefully — is where much of the engineering effort goes. How high you need to set this bar depends entirely on what the system is allowed to do on its own.
What You Can Build at Each Budget
Numbers are more useful than adjectives, so here is a concrete map. We work in fixed-price tiers, and the point of quoting a fixed price is that the risk of estimating wrong sits with us, not with you. These ranges describe what a well-scoped project tends to look like at each level — not a menu, but a sense of proportion. You can read the full breakdown on the services page.
Roughly €15–25k: one focused use case in production
This gets you a single, clearly defined process automated and running for real — not a prototype, but a working system your team uses. Think of one specific document type processed automatically, one category of inquiry answered, or one recurring analysis produced on demand. The scope is deliberately narrow, which is exactly what makes it deliverable at this level and a sensible way to prove the approach before committing more.
Roughly €25–50k: a full system for one process
Here you get more than a single task — a complete system around one business process, with several connected steps, integration into the systems that process depends on, and the controls to run it reliably. This is the range where a genuine end-to-end workflow gets built: the AI reads from your systems, does its work, writes back, and knows when to hand off to a person.
€50k and up: multi-agent or platform
Above this level you are building something broader: multiple coordinated agents, a reusable platform several teams draw on, or an automation that spans several processes and systems at once. This is appropriate when the scope is genuinely large — and usually the wrong place to start.
The Costs People Forget
The build cost is the number everyone asks about. The running cost is the one that decides whether the project is a good investment over its life. A production AI system is not a finished object you hang on the wall — it is closer to a piece of operating machinery, and machinery needs maintenance.
Several things need ongoing attention. Monitoring tells you the system is still doing its job and flags when it is not. Model and dependency updates matter because the underlying models and libraries change; a system left untouched for a year will eventually break or fall behind. Drift is the quiet one: the world the AI was built for keeps moving — new products, new phrasing, new customer behaviour — and performance decays even though nothing in your code changed. Correcting for that sometimes means retraining or re-tuning on fresh data. Infrastructure — hosting, compute, the per-call cost of the model — is an ongoing line, modest for most use cases but never zero.
Because of all this, most serious deployments include a support retainer: a defined arrangement for keeping the system healthy, applying updates, and responding when something needs attention. This is not an upsell; it is the honest cost of ownership. A system nobody maintains is a system that quietly degrades until the day it fails at an inconvenient moment.
The right way to frame a decision, then, is total cost of ownership over two or three years — build plus running — measured against the time, errors, or manual effort the system removes. A project that looks expensive on the build line often looks very reasonable once you set it against what it saves, month after month, for years.
Build vs. Buy
Not every AI need justifies a custom system, and it would be dishonest to pretend otherwise. Sometimes the right answer is to buy an off-the-shelf SaaS product and be done with it. Knowing which situation you are in saves real money.
Buy when your need is common and non-differentiating. If thousands of companies want roughly the same thing — a meeting transcriber, a generic writing assistant, a standard chatbot for FAQ — someone has already built it, spread the cost across all those customers, and can offer it for a monthly fee far below what a custom build would cost. Paying to rebuild a commodity is rarely wise.
Build when one of three things is true. First, data sensitivity: if your data cannot be sent to a third-party service for legal or competitive reasons, an off-the-shelf cloud product may simply be off the table, and a custom, on-premise-capable system becomes the only responsible option. Second, specificity: if the task is tied to your particular processes, your terminology, and your systems, a generic tool will fit awkwardly and never quite do the job — the value is precisely in the fit. Third, lock-in: a custom system you own does not raise its price every year or disappear when a vendor pivots; for a capability that becomes central to how you operate, ownership is worth paying for.
The honest position is that most companies end up with a mix — buying the commodities and building the few things that are genuinely theirs. The mistake to avoid is building what you could have bought, or buying a generic tool for a problem that was always going to need a custom fit.
How to De-Risk the Spend
The uncomfortable truth about a five-figure project is that the biggest risk is not that the technology fails — it usually works — but that you commit to the wrong scope, on shaky data, before anyone has checked the assumptions. The way to remove that risk is not to demand a firmer promise up front. It is to spend a little to find out, before you spend a lot.
That is the purpose of a paid feasibility assessment. For a four-figure fee you get a structured look at your specific case: is the data actually there and usable, which systems really need to be touched, where the hard parts are, and — crucially — an honest go/no-go recommendation. If the answer is “this is not worth doing yet,” you hear it, and you have saved yourself the five-figure mistake. If the answer is “yes,” you walk away with a fixed-price quote grounded in your real situation rather than a guess.
This is exactly what our AI Readiness Check is for. It turns “it depends” into a number you can plan around, and it is fully credited toward the build if you go ahead — so a “yes” costs you nothing extra, and a “no” costs you a fraction of what a misjudged project would. Paying four figures to avoid a five-figure mistake is one of the clearest decisions in this whole field.