Shimira ITIn 2026, adding an AI feature to an existing product typically costs $15,000–$45,000, a retrieval (RAG) or document-automation system costs $30,000–$90,000, and an AI-first product taken from MVP to production runs $50,000–$150,000 or more. A feasibility assessment, which tells you whether the AI can do the job at an acceptable accuracy and cost before you build anything, runs $3,000–$8,000. Unlike ordinary software, an AI product comes with two bills: the build, and the cost of the model every time someone uses it. This guide covers both, with worked examples.
Key takeaways
- Start with a $3,000–$8,000 feasibility assessment. It tells you achievable accuracy and running cost before a large commitment.
- AI adds 15–30% to a comparable build, mostly for evaluation, guardrails, and data preparation.
- Running cost is requests × tokens × price. Model choice, prompt length, and caching can change it by 10×.
- Most business use cases need retrieval over your data, not a custom model.
In this guide: cost by project type · cost by use case · the AI premium · running costs · RAG vs. fine-tuning · ROI · timeline · choosing a vendor
Cost by project type
| Project | Typical timeline | Build cost |
|---|---|---|
| AI feasibility assessment Tests the task against your real data: achievable accuracy, running cost, and whether the ROI holds | 1–2 weeks | $3,000 – $8,000 |
| AI feature in an existing product Summaries, smart search, drafting, classification | 4–8 weeks | $15,000 – $45,000 |
| RAG system, document automation, or workflow agent Answers from your own documents with citations; extraction from contracts, invoices, or forms; multi-step automation with human review | 2–4 months | $30,000 – $90,000 |
| AI-first product A new product where AI is the core, from MVP to production | 3–6 months | $50,000 – $150,000+ |
These ranges reflect senior engineering from India. For the same scope, expect US and Western European agencies to quote substantially more; our hourly rates by region guide breaks down why.
Cost by use case
Most business AI projects fall into a handful of patterns. Here's where common ones usually land:
| Use case | What it does | Usual range |
|---|---|---|
| Summaries & drafting in your product | Summarize records, draft replies, rewrite content | $15,000 – $45,000 |
| Smart search | Search that understands meaning, not just keywords | $15,000 – $45,000 |
| Support assistant over your help docs | Answers customer questions with citations, hands off to humans | $30,000 – $90,000 |
| Internal knowledge assistant | Answers staff questions from policies, wikis, and past work | $30,000 – $90,000 |
| Document extraction | Pulls structured data from invoices, contracts, or forms, with review | $30,000 – $90,000 |
| Workflow agent | Triages, routes, and drafts inside a multi-step process | $30,000 – $90,000 |
| AI-first product | A new product built around AI capabilities | $50,000 – $150,000+ |
Where a project lands within its range depends mostly on data quality, the accuracy you need, the number of systems it connects to, and how much human review the workflow requires.
Why AI adds 15–30% to a build
Connecting an app to a model takes an afternoon. Making it reliable is where the budget goes, and none of this work exists in a comparable non-AI app:
- Evaluation. A test set of real examples and an accuracy harness, so you know how often the AI is right, in numbers, before launch.
- Guardrails and validation. Checking outputs before they reach users or your database, handling personal data, and defending against prompt injection.
- Data preparation. Cleaning, splitting, and indexing your documents so retrieval finds the right passage, which is most of the work in a good RAG system.
- Human review screens. The interface where people check, correct, or approve AI output in the places where mistakes are expensive.
- Iteration on real data. Prompts and retrieval tuned against your actual edge cases, not a demo dataset.
The second bill: running costs
Hosted models charge per token, roughly per chunk of text going in and coming out. A useful way to estimate your monthly model bill:
A worked example
Take a support assistant that answers 50,000 questions a month. Each request sends about 4,000 tokens of context (the question plus retrieved help articles) and gets back about 500 tokens. Using illustrative prices of $3 per million input tokens and $15 per million output tokens, typical of a capable mid-tier model:
| Tokens per month | Cost per month | |
|---|---|---|
| Input (50,000 × 4,000) | 200 million | $600 |
| Output (50,000 × 500) | 25 million | $375 |
| Total model cost | about $975 |
Route the easy half of those questions to a small model priced at around a tenth of that, and the bill drops by roughly 45%. Cut the retrieved context from 4,000 to 2,000 tokens with better retrieval, and input cost halves again. These levers are why two teams building the same feature can have monthly bills ten times apart. Always check current prices for the models you're considering.
What moves that number most:
- Model choice. Smaller models cost a fraction of frontier models and handle many tasks well. Routing easy requests to a cheap model and hard ones to a strong model is often the biggest single saving.
- Context size. Retrieval systems that stuff large documents into every request pay for all of that text, every time.
- Caching. Many requests repeat. Caching answers and shared prompt prefixes cuts cost and latency.
- Output length. Asking for concise, structured output is cheaper than long prose.
On top of the model, budget for a vector database or search index, hosting, and monitoring. If your data can't leave your own environment, self-hosted open-weight models replace per-token fees with GPU infrastructure, which costs more at low volume and less at high volume.
RAG, fine-tuning, or a custom model?
| Approach | Use it when | Relative cost |
|---|---|---|
| Prompting a hosted model | The task is general and doesn't need your private data | Lowest |
| RAG (retrieval over your data) | Answers must come from your documents, with citations, and stay current as documents change | Moderate; the most common choice |
| Fine-tuning | You need a consistent style or format, or a small model to match a large one on a narrow task | Moderate to high, plus retraining as data changes |
| Training a model from scratch | Almost never for business applications | A different budget category entirely |
Working out whether it pays off
The simplest ROI model for automation projects is hours saved × loaded hourly cost, minus running costs. An illustrative example for document processing:
- Three people spend 20 hours a week each extracting data from documents: about 3,000 hours a year.
- At a loaded cost of $35 an hour, that's $105,000 a year.
- An extraction system handles 70% of documents automatically, with people reviewing the rest: about 2,100 hours, or $73,500, saved.
- Subtract around $6,000 a year in running costs.
- Net saving of about $67,500 a year, so a $60,000 build pays back in under a year.
Your numbers will differ. The point of the feasibility assessment is to replace the assumed 70% with a measured accuracy on your own documents before you spend the build budget.
How long it takes
| Phase | Duration | What you get |
|---|---|---|
| Feasibility assessment | 1–2 weeks | Measured accuracy, running-cost estimate, go or no-go |
| Pilot | 3–6 weeks | A working system on a bounded slice, with an evaluation harness |
| Production build | Varies by scope | Integration, guardrails, monitoring, fallbacks |
| Tuning | Ongoing | Accuracy improvements as real usage exposes edge cases |
Is your data ready?
A quick checklist before you budget:
- Can the documents or records be exported programmatically?
- Are they reasonably current, or full of outdated versions?
- Do you have 50–200 real examples with correct answers to build a test set?
- Is there personal or regulated data that needs special handling?
- Is there an expert who can judge whether an answer is right?
Each "no" adds data preparation work, and it's far cheaper to find out during feasibility than mid-build.
Hidden costs most AI quotes leave out
- Your experts' time. Someone who knows the domain has to help build the test set. It is the most valuable input to the whole project and usually missing from the budget.
- Model upgrades and retirements. Providers retire and replace models regularly. Each switch means re-running your evaluation, and sometimes re-tuning prompts.
- Re-indexing. When your documents change, the search index has to keep up.
- Monitoring and review. Watching accuracy, cost, and flagged outputs after launch, because real users find edge cases no test set did.
- Compliance. Personal-data handling, data residency, and vendor terms reviewed before launch, not after a customer asks.
Questions to ask any AI vendor
- How will we measure accuracy, and on what test set?
- What will this cost to run per month at our volume?
- Which model will you use, and why that one?
- What happens when the AI is wrong or unsure?
- Where does our data go, and is it used for training?
- What happens when the provider retires the model?
Red flags: accuracy promises before anyone has seen your data, no mention of running costs, and a proposal to train a custom model for a problem retrieval would solve.
Build or buy?
If an off-the-shelf AI tool already covers most of what you need, buy it. Custom AI earns its cost when the AI has to work on your own data, sit inside your own product or workflow, or meet accuracy and data-handling requirements a general tool can't guarantee. A feasibility assessment answers this honestly, including when the answer is not to build.
That is exactly how our AI development service runs. If you'd rather add AI engineers to your own team, see hire AI developers. Either way, tell us the problem and we'll put a real number on it.