An Honest Answer Is a Cost Structure, Not a Price List
Ask five firms what an AI project costs and you will get five ranges that share no common definition of what is inside them. The honest reason is that the same one-page brief can cost twenty thousand dollars or two hundred thousand, and the difference is almost never the model. It is the condition of your data, the number of systems the thing has to talk to, how accurate it has to be before anyone will trust it, and which regulator is watching. What we can publish without lying is the structure of the spend: which lines exist, roughly what share each one takes, and which variables move the total.
Six lines cover almost every AI build we have scoped. Discovery and scoping typically runs 5 to 10 percent of the first-year budget. Data work runs 25 to 40 percent and is the line most often estimated at zero. Build, meaning the retrieval pipeline, prompt and context assembly, orchestration and the application itself, runs 20 to 30 percent. Evaluation runs 10 to 15 percent. Integration into your systems of record runs 15 to 25 percent. On top of those, carry 10 percent contingency, because the first look at real data changes something. These are planning shares we use ourselves, not survey results.
Quote effort before money. A tightly scoped assistant over one clean document source is typically 12 to 20 person-weeks of engineering. A mid-size system with two or three integrations, a real evaluation harness and a permission model is typically 25 to 45 person-weeks. A regulated deployment with multiple systems of record, audit logging, human review workflows and a formal risk assessment is typically 60 to 120 person-weeks. Convert those at your own blended rate, internal or external. Whatever rate you use, the ratios between the lines hold, and the ratios are the part that actually helps you plan.
If you want currency bands, here are ours, and they are planning bands we own rather than quoted market rates. The small band lands around USD 25,000 to 45,000, roughly TL 1.0 to 1.9 million. The mid band lands around USD 60,000 to 130,000, roughly TL 2.5 to 5.5 million. The regulated band starts around USD 200,000 and can pass USD 450,000, roughly TL 8 to 19 million. The lira figures track the exchange rate, so re-derive them the week you sign. Before you spend any of it, agree what you are buying: scoping the project properly is what makes these numbers mean anything.
Discovery and Scoping: Five to Ten Percent That Decides the Other Ninety
Discovery is the cheapest line on the budget and the only one that changes every other line. Ours run 2 to 4 calendar weeks and consume 4 to 8 person-weeks of effort, split between an engineer, a data person and someone who sits with the users. The output is not a slide deck. It is a named use case with a measured baseline, an inventory of the data with sample files actually opened, a written acceptance test, a list of every system the solution must read from or write to, and a risk classification. If a discovery ends without those five artefacts, it was a sales meeting.
The most expensive mistake we see is skipping the baseline measurement. A team commits to reducing document review time without ever timing document review. Six months later the system works and nobody can prove it, because there is no before. Measuring the baseline usually costs 2 to 5 person-days: shadow ten people for a week, count cases, time them, record the current error rate. Do it before the vendor arrives, so the number is yours. Everything downstream, including whether you renew in year two, depends on a figure somebody wrote down in week one.
Discovery also decides how much of the build gets thrown away. In projects that skipped it, we typically see 20 to 40 percent of the first build rewritten once real data and real permissions show up, and that rework is not covered by anybody's contingency line. Discovery is also the right place to ask whether you should be building at all. Several honest answers end with buying something off the shelf, which is the subject of our note on build versus buy. A discovery allowed to conclude do not build is worth more than one that is not.
Data Work: The Largest Line, and the One Estimated at Zero
Data work is 25 to 40 percent of a first production build, and it is the line that almost every internal budget puts at zero because the data is assumed to exist. It does exist. It is just spread across a document management system, a shared drive, an ERP, three inboxes and someone's laptop, with duplicates, with permission rules that live only in people's heads. Turning that into something a retrieval system can serve reliably is an engineering project with its own tests. If a proposal you receive does not have a data line larger than its build line, the vendor has not looked at your data.
The sub-tasks are concrete and estimable once someone has opened the files. Extraction and layout handling for scanned material typically runs 3 to 8 person-weeks per 100,000 pages. Deduplication and version resolution runs 2 to 4 person-weeks on a corpus of a few hundred thousand documents. Mapping who is allowed to see what, and making retrieval enforce it rather than the interface, runs 2 to 5 person-weeks. Building a golden set of 200 to 300 real questions with agreed correct answers runs 2 to 4 person-weeks, most of it your subject experts' time rather than the vendor's.
Two surprises recur. The first is that 5 to 15 percent of a real corpus turns out to be unusable: unreadable scans, drafts nobody can identify as drafts, documents superseded years ago. Someone has to decide what happens to them, and that is a business decision, not an engineering one. The second surprise is calendar rather than effort. Getting production data access approved inside a mid-size Turkish company routinely takes 3 to 8 weeks of legal, information security and system-owner sign-off. Start that clock on day one of discovery, not on day one of the build.
Budget your own people's time as a real cost rather than as free capacity. On a mid-size build we expect 8 to 15 days of subject-matter expert time spread across the project, mostly for labelling, adjudicating the golden set and reviewing early outputs. Teams that refuse this end up with a system tuned to what an engineer guessed the right answer was, which is exactly the system that fails its first month in production. We have written the practical version of this line separately in preparing data for an AI project, including how to sample a corpus before you commit to anything.
Build and Evaluation: The Harness Is a Budget Line, Not a Task
Build is 20 to 30 percent, and it is the part everyone pictures when they imagine an AI project. It covers chunking strategy, embedding and indexing, hybrid retrieval, reranking, prompt and context assembly, the orchestration around tool calls, and the application surface people actually use. On a mid-size system this is typically 8 to 14 person-weeks. It feels like the whole project during weeks four to eight and then stops being interesting, because the model was never the hard part. The hard part is proving the thing is right often enough to be trusted, and that is a separate line.
Evaluation is 10 to 15 percent, and it deserves its own line because it is the only mechanism that lets you change the system later without gambling. Concretely it means a golden set, retrieval metrics measured separately from answer quality, an automated regression run that anybody on the team can trigger, assertions on cost and latency, and a scoring rubric that a human agreed with before the numbers looked good. Initial construction is 4 to 8 person-weeks on a mid-size build. Without it, the first model upgrade turns into a week of people arguing from anecdotes about whether the system got worse.
The architecture you pick moves the split between these two lines. Retrieval-heavy systems push effort into data and integration; approaches that involve ince ayar move effort into dataset construction and training runs, and raise the cost of every later change. We compare the two honestly in RAG versus fine-tuning. As a planning rule we assume that any approach requiring a retrain in order to update knowledge adds 3 to 6 person-weeks per refresh cycle, plus a standing obligation you will still be paying in year three.
Integration: The Surface Nobody Counts Until Week Nine
Integration is 15 to 25 percent, and it is where optimistic plans die quietly. As a planning figure, each additional system of record adds 3 to 6 person-weeks: one to understand the data model, one or two to build and test the adapter, one to handle the failure cases nobody mentioned. A system that reads from one document store is a fundamentally different project from one that reads a document store, writes to an ERP, checks entitlements in an identity provider and posts to a ticketing tool, even though the two demos look identical.
The line also carries the unglamorous items: single sign-on, propagating each user's permissions into retrieval so that nobody can ask their way into documents they cannot open, rate limiting, retries, audit logging that will satisfy whoever eventually asks for it, and the interface itself. In Turkish mid-market environments we regularly meet on-premise ERPs with no usable API, document systems that expose only a nightly export, and network rules that require the whole system to run inside the customer's own data centre. Each of those is 2 to 4 person-weeks that no generic estimate contains.
Then there is the part that is not engineering at all. Rollout, training material, a pilot user group and a month of somebody answering questions is typically 1 to 3 person-weeks of vendor effort plus a meaningful amount of your own operational time. Systems that skip it get measured on adoption they never had. If forty people are supposed to use a tool and twelve actually do, your effective cost per user has tripled without a single line of the budget changing. We budget this explicitly now, because the alternative is a technically correct system that next year's review records as a failure.
Run-Rate: What the System Costs Every Month After Go-Live
Almost every AI budget we are shown stops at go-live. The system then costs money every month for as long as it is switched on, in six places: model inference, the vector database, the compute and hosting around it, human review of outputs, periodic re-evaluation, and ordinary maintenance. Treat run-rate as a first-class line during scoping, because it decides whether the business case survives contact with year two. A project that pays back in fourteen months on build cost alone but in thirty-one months once run-rate is included is a genuinely different decision.
Inference is the line people fear and usually misjudge in both directions. The right unit is not tokens, it is cost per completed task: one answered question with citations, one contract clause extracted, one ticket triaged. Plan it, measure it during the pilot at realistic prompt lengths, then multiply by honest rather than optimistic volume. Our planning band for a retrieval-augmented answer with reranking and a moderate context is roughly USD 0.01 to 0.08 per answered question, which is our own assumption and not a price list. At 4,000 questions a month that is USD 40 to 320; at 400,000 it is a budget line with a name and an owner.
The rest is steadier. A managed vector database holding a few million chunks typically plans at USD 200 to 1,500 per month depending on replication and whether it must sit inside your own network; self-hosting trades that spend for roughly 0.2 to 0.5 of an engineer's ongoing attention. Human review of a sample of outputs starts around half a day per week per workflow and should fall as confidence rises rather than disappear on a fixed date. Re-evaluation after a model or provider change is 1 to 3 person-weeks each time, and we plan for two to four of those a year.
Add ordinary maintenance, which we plan at 15 to 25 percent of build cost per year: dependency updates, prompt and retrieval drift, new document types, small feature requests, and the eventual incident. Summed, a healthy annual run-rate for a mid-size system lands at roughly 20 to 35 percent of the original build cost, and the low end is only reachable if the evaluation harness exists. Put the number in the business case from the start rather than discovering it in month thirteen; the way to keep it honest over time is described in how to measure AI return on investment.
The Four Things That Move the Number by Three to Five Times
First, the condition of your data. Born-digital documents in one system with consistent metadata is the cheap case. Scanned material of mixed quality spread across five repositories, with no reliable document type field and no way to tell current from superseded, is the expensive case, and the gap between them is 1.5 to 3 times on the data line and close to 2 times on the total. All of this is measurable before you sign anything. Pull a random sample of 300 documents and count how many are scanned, how many are duplicates, how many nobody can classify. That count predicts your budget better than any other single number.
Second, the integration surface. One system of record, read-only, is the cheap case. Four systems, two of them written to, one of them a product from an earlier era with an export-only interface, is roughly 1.8 times the total on its own. Write access is disproportionately expensive because it drags in approval flows, reversibility, audit trails and a considerably harder security review. If you can defer writes to phase two and ship a read-only version first, you often cut the first release by a quarter and learn what the writes should actually do.
Third, the accuracy bar. Going from an internal assistant where 85 percent correct with visible citations is genuinely useful, to a system whose output reaches a customer or a regulator unreviewed, is not ten percent more work. In our experience the last eight to twelve points of accuracy cost about as much as everything before them, because they are earned in data cleanup, hard negative cases, retrieval tuning and evaluation rather than in the model. Decide early whether a human stays in the loop. Keeping one is very often the cheapest correctness mechanism available.
Fourth, the regulatory tier. A KVKK-relevant workload touching special-category personal data under Law No. 6698 brings documentation, retention rules, access controls and frequently a hosting constraint. In the EU, the AI Act, Regulation (EU) 2024/1689, became applicable on 2 August 2026, with the Annex III standalone high-risk categories now applying from 2 December 2027 following Regulation (EU) 2026/1744, while the Article 50 transparency obligations took effect on 2 August 2026 as scheduled. Landing in a high-risk category adds 20 to 40 percent to a build in our planning, mostly in documentation, logging, oversight design and testing evidence rather than in application code.
A Worked Example, in Person-Weeks and in Money
Take an insurance brokerage with a 40-person back office in Istanbul. They hold roughly 180,000 policy documents, endorsements and claim files, about 22 percent of them scanned, mostly in Turkish with a minority in English. They want an internal assistant that answers coverage questions with citations to the exact clause, and they want it running inside their own network. Baseline measurement during discovery showed each of eleven specialists spending about 70 minutes a day locating and re-reading documents. That number is what the whole business case rests on, and it was measured before anyone wrote code.
The scope came out at 45 person-weeks over five calendar months with a peak of three and a half people. Discovery took 5 person-weeks. Data work took 14: extraction and layout handling for the scanned portion, deduplication that removed 11 percent of the corpus as exact or near-exact copies, a document type classifier because the existing metadata field was unreliable, permission mapping, and a golden set of 240 questions built with four of their specialists. Build took 11. Evaluation took 6. Integration took 9, covering single sign-on, permission-aware retrieval, the internal web interface and audit logging.
At our planning bands that lands in the USD 90,000 to 140,000 range, roughly TL 3.8 to 5.9 million, plus the client's own twelve days of specialist time. Note the shape rather than the total. The data line was larger than the build line. Evaluation cost more than half of build. Integration cost nearly as much as build. Every proposal that quotes you a large model-related number and a small data number is describing a different project from the one you will actually run. The lira figures move with the exchange rate and should be re-derived at signature.
Year-one run-rate came out around 22 percent of build cost. Inference at roughly 3,800 questions a month sat in the low hundreds of dollars, the in-network vector database and compute dominated the monthly spend, half a day a week of specialist review was kept deliberately rather than removed at go-live, and two re-evaluations were budgeted against expected provider changes. Against a baseline of eleven people times 70 minutes a day, recovering even half of that time is worth substantially more than the run-rate, which is why the baseline measurement mattered more than any technical decision in the project.
Why a Fixed Price on an AI Project Is Usually a Warning Sign
Buyers ask for a fixed price for good reasons: budget approval is easier and risk feels transferred. On an AI project, a fixed price offered before the vendor has opened your data means one of three things. They have padded it by 40 to 80 percent to cover what they cannot see, which you pay for whether or not the risk materialises. They intend to renegotiate at the first change request, which is the same price with worse politics. Or they have not understood that accuracy depends on data they have not looked at, which is the worst of the three.
The asymmetry is specific and worth naming. A vendor can fix-price a login screen because everybody knows what a login screen is. Nobody can fix-price the sentence the assistant will answer coverage questions correctly without knowing whether the coverage documents are legible, consistent, current and correctly permissioned. Any proposal that promises a percentage accuracy figure before data access is quoting a number it invented. It is worth asking directly how the figure was derived, on what corpus, against what golden set and measured by whom, and then watching what happens. In our experience you get either a specific method or a change of subject.
Fix-price the parts that are genuinely knowable. Discovery and the data assessment: fixed, capped, with a defined deliverable. Infrastructure and environment setup: fixed. Each integration adapter against a frozen interface contract: fixed. Training, documentation and handover: fixed. Then run the uncertain middle as capped time and materials with milestone gates, where each gate is an acceptance criterion agreed in writing before the work starts and where stopping is a real option. That structure gives you genuine budget control instead of the illusion of it, and testing for it is one of the more useful exercises when choosing an AI development partner.
How We Cost Projects at HatsonTech
We do not quote a build before a paid discovery, and the discovery itself is fixed price, capped, and small enough that walking away afterwards is a rational choice rather than a sunk-cost problem. During it we open a real sample of your documents, run extraction over a few thousand of them, build a first golden set with your people, list every integration point, and write down the acceptance criteria in language a non-engineer can check. The output belongs to you whether or not we build anything, including the sample results, the data assessment and the estimate broken down by line.
What we have seen across our own products has shaped these numbers more than any external source. On caseon.ai and DiligenceAI, both of which work over long, messy and legally significant documents, the data and evaluation lines consistently dominated everything else. On VinçTakip and SYDhub the integration line dominated instead, because the value sat in existing operational systems rather than in text. The consistent lesson across all four is that model choice moved the budget least. If you want the failure mode this whole structure is designed to avoid, we wrote it up in why AI pilots never reach production.
We would rather be the firm that tells you the data line is 40 percent than the one that discovers it in month four and asks for a change order. If you are building the business case now, start with the baseline measurement, add the run-rate before you present it, and read our overview of AI for business for the decisions that sit above the budget. When you are ready to price something specific, our custom software development practice scopes and quotes it line by line, in person-weeks first and money second. We will also tell you when the honest answer is that the project is not worth its own run-rate.