AI PoC cost for real projects

An AI proof of concept should buy a decision, not a prettier demo. If the result cannot tell you whether to fund, change, buy, or kill the idea, the budget was wasted even when the model looked impressive in a meeting.

For planning, I use a range of $15,000 to $150,000. The low end covers a narrow workflow with clean data and one integration. The high end covers an agentic or regulated use case that needs several systems, serious evaluation, security review, and a credible path to production. Those are scoping ranges from building and reviewing these projects, not a universal price list. Team rates, data condition, risk, and the evidence required at the end change the number.

The useful way to estimate a PoC is to separate model novelty from delivery uncertainty. A familiar model attached to six unreliable systems can cost more than a custom model tested on one clean dataset. Founders often price the AI and ignore the plumbing. The plumbing usually sends the first invoice.

AI proof of concept cost buys a decision

The budget should match the value and difficulty of the decision you need to make. A team asking, "Can a language model classify these support tickets well enough for an agent to review?" needs less evidence than a team asking, "Can this system approve claims without creating unacceptable financial and compliance risk?"

Write the decision before the statement of work. A useful sentence has four parts: the user, the job, the measurable threshold, and the consequence. For example: "If the assistant answers at least 85 percent of 200 approved test questions correctly, cites the supplied source, and keeps median response time below five seconds, we will fund a production pilot." The numbers in that sentence are an example, not defaults. Your owner must choose thresholds from the economics and risk of the actual workflow.

This separates three things teams routinely blur:

• A prototype proves that an interaction can be built.
• A PoC tests whether a defined technical or business claim holds under stated conditions.
• A production pilot tests the operating system around the AI with real users, controls, support, and monitoring.

Calling a prototype a PoC leads executives to treat a staged success as evidence of repeatable performance. Calling a pilot a PoC hides production work inside an experimental budget. Both errors produce the same argument later: one side believes the team is nearly done, while the engineers know the hard work has barely started.

A small PoC commonly takes four to eight weeks. A PoC dominated by data work, regulation, or several integrations may take eight to sixteen weeks. Time should follow the learning loop, not a ceremonial calendar. If reviewers can label only twenty examples per week, adding engineers will not make the evidence arrive faster.

Realistic budgets depend on the PoC type

Different PoC types carry different cost structures, so one average number is not useful. The ranges below assume a small senior team, a bounded use case, existing cloud or model services where appropriate, and a written evaluation. They exclude a broad production rollout, continuous support, large software licenses, and major data acquisition.

Workflow automation is cheapest when the model performs one narrow transformation and a person approves the result. Think of drafting a reply, mapping an inbound request to a category, or extracting fields before an employee checks them. It becomes expensive when "automation" secretly means redesigning the whole process.

A retrieval assistant needs more than a chat screen. It needs document ingestion, chunking or another retrieval method, access control, a test set, citation behavior, and a rule for unanswered questions. A public FAQ bot over fifty clean pages belongs near the low end. An internal assistant spanning contracts, tickets, and documents for different roles moves upward quickly.

Traditional predictive work often spends more on labels and feature reconstruction than on model training. If the target outcome is missing, inconsistently recorded, or available only after a long delay, the project can fail before algorithm choice matters. A credible PoC compares the model with the current rule or human decision, not with zero.

Vision, speech, and document work grows with sample variety. Ten clean invoices from one template can make extraction look finished. Add scans, mobile photos, handwriting, several languages, and tables split across pages, and the exception queue tells a different story.

Agentic systems cost the most because the team must test actions, not just answers. Tool permissions, retries, partial completion, approval points, state recovery, and audit logs enter scope. A scripted happy path may look convincing for $20,000, but it does not answer whether the agent can touch a real order, repository, or customer record safely.

A complete estimate includes more than model work

A defensible estimate includes discovery, data, implementation, integration, evaluation, and handoff. If one of those lines is absent, someone has probably assumed another team will do it for free.

I expect a PoC estimate to identify these work packages:

1. Decision design: use case boundary, baseline, success metrics, failure conditions, and named decision owner.
2. Data readiness: access, sampling, cleaning, labeling, permission checks, and a frozen evaluation set.
3. System build: model or service selection, prompts or features, retrieval, orchestration, and a minimal user surface.
4. Connection and control: required integrations, authentication, logging, human approval, and handling for timeouts or bad outputs.
5. Evaluation and handoff: repeated test runs, error analysis, cost projection, architecture notes, and a recommendation.

For a $40,000 knowledge assistant, a plausible allocation might be $5,000 for decision design, $8,000 for data preparation, $12,000 for retrieval and application work, $7,000 for one integration and access control, and $8,000 for evaluation and handoff. That is a worked budget, not a rate card. It helps expose disagreement early. If the client expects five integrations but the connection line can fund only one, the scope is wrong before work starts.

Model usage during a PoC is often a modest line compared with engineering, domain review, and data work. Do not conclude that inference cost is irrelevant. Measure tokens, calls, media minutes, or accelerator time during the test, then project them at expected volume. A design that passes quality tests but loses money on every completed task has failed the business claim.

Internal time belongs in the budget even when it does not appear on the vendor invoice. Product owners must answer workflow questions. Security staff review access. Domain experts label examples and adjudicate disputed results. Finance or operations validates the unit economics. A cheap proposal that consumes hundreds of unplanned staff hours is not cheap.

Bad data inflates the budget before the model starts

Data uncertainty is the most common reason a sensible estimate grows. Teams say they have years of data, then discover that the usable fields live in exports with changing schemas, labels reflect several conflicting policies, and nobody owns permission to use the records for model testing.

Run a paid data readiness check before fixing the full PoC price when any of these conditions exist:

• The team cannot produce a representative sample within two business days.
• The desired outcome is not recorded directly or has changed meaning over time.
• Sensitive records require redaction, residency controls, or legal review.
• Images, audio, or documents vary by source, format, language, or quality.
• Domain experts disagree on the correct answer for the same examples.

The check should end with an inventory, a sample profile, a labeling rule, access approval, and an estimate of usable coverage. It should also identify leakage. If a feature records what happened after the decision you want to predict, the model can score beautifully in a notebook and fail the moment it sees a live case.

Keep the final evaluation set away from daily prompt and model tuning. Teams that repeatedly inspect test failures and tune against them turn the test into training data. Split examples by the unit that will matter in operation. For customer support, that may mean separating by customer or time period rather than randomly scattering messages from the same conversation across sets.

Synthetic data can test formats, edge handling, and system load. It cannot, by itself, prove performance on messy human behavior that the generator did not reproduce. Use it to supplement scarce cases and to probe known failures. Keep enough real, representative samples to support the decision.

If the data check shows that labels cannot be trusted, stop and repair the measurement process. Building a more elaborate model on ambiguous targets produces a more expensive ambiguity. That is a valid PoC result because it prevents a larger spend based on false confidence.

Integrations, controls, and evaluation create the surprises

Integration count alone is a weak estimate. Integration behavior determines effort. Reading from a stable export is different from writing to a live system that has rate limits, granular permissions, duplicate events, and business consequences when a retry runs twice.

Price each connection against a concrete contract: read or write, authentication method, environments available, data volume, latency target, error behavior, and owner. If a sandbox does not exist, the PoC may need a simulator or a reversible action. That work must appear in scope. "Connect to the CRM" is not a scope item.

Security also changes with the action boundary. An assistant that reads public documentation needs basic application controls. A system that reads private contracts needs identity propagation, permission filtering, retention decisions, and evidence that one user cannot retrieve another user's material. An agent that changes records needs tools with minimal permissions, approval rules, idempotency, and an audit trail.

NIST's AI Risk Management Framework organizes work around Govern, Map, Measure, and Manage. For a PoC, I would not turn the entire framework into paperwork. I would borrow its discipline: document the context and affected people, select measures for the risks that matter, record residual risk, and make one owner decide whether the evidence permits the next stage. A risk register with four lines that changes the design is better than forty pages nobody uses.

Evaluation needs a budget because quality is not one number. A retrieval assistant may need answer correctness, source support, refusal behavior, tests of access controls, latency, and cost per resolved question. An extraction system may need field accuracy plus the percentage of documents sent to human review. An agent may need task completion, counts of unauthorized and duplicate actions, and recovery after tool failure.

Use a baseline that represents the current choice. Google's Rules of Machine Learning advises teams to design metrics first and keep the first model simple while getting the pipeline right. I agree with the simplicity, but a PoC does not always need production infrastructure. It needs enough of the real data and serving path to expose the uncertainty under test. Mock everything else and record what remains unproven.

Fixed price work needs fixed evidence

A fixed price works when the inputs, boundary, and acceptance evidence are fixed. It fails when a buyer asks a vendor to absorb unknown data quality, unlimited stakeholder feedback, and unspecified integrations under one number. The vendor either prices a large risk premium or protects margin through change requests.

The clean structure is a discovery at a fixed price followed by a PoC at a fixed price. Discovery resolves access, inspects samples, agrees on the baseline, and produces the acceptance matrix. The second price then covers known work. If uncertainty remains high, divide the PoC into capped stages with a stop decision after each stage.

A useful agreement with a fixed price states:

• The exact workflow, user group, dataset snapshot, and environments in scope.
• Deliverables, including code, configuration, test set, results, error analysis, and handoff notes.
• Acceptance thresholds and who adjudicates answers where judgment differs.
• Assumptions about client access, review turnaround, and external service accounts.
• Exclusions and a written rate or method for approved scope changes.

Never use "working AI assistant" as acceptance language. It cannot settle an invoice dispute. Use observable evidence, such as: "On evaluation set v1, the system returns the approved answer or an acceptable equivalent for at least 170 of 200 questions, includes a supporting source for every answered question, exposes no document outside the test user's permission group, and responds within the agreed latency for 95 percent of runs."

Fixed price should not mean fixed technical choices. Let the team switch a model, retrieval method, or prompt when the deliverable and constraints remain unchanged. Buying a named implementation can trap both sides in a weak approach. Buy the evidence and the handoff artifacts.

Payment milestones should follow risk retirement. A practical schedule might attach payment to approved scope and data access, a complete baseline, evaluation completion, and final handoff. Do not attach most of the money to a polished demonstration. That rewards presentation before evidence.

An acceptance matrix keeps the demo honest

The acceptance matrix should exist before implementation because it defines what the project must learn. It turns a vague ambition into cases that can pass, fail, or reveal a missing policy.

For a support knowledge assistant, I might use this compact version:

The values are illustrative. The structure is the reusable part. Each claim has a test, a threshold chosen by the business, evidence that survives the meeting, and a consequence. Without the last column, teams quietly lower the bar after seeing results.

Evaluate failure clusters, not just the aggregate score. If the assistant gets 90 percent overall but fails nearly every question about cancellations, the launch decision depends on how often that category occurs and what a wrong answer costs. Averages hide concentrated risk.

Record the configuration for every run: model version, prompt or feature version, retrieval settings, dataset version, and relevant system parameters. You need enough detail to reproduce a result. A screenshot of a good answer proves only that one good answer happened.

The handoff should include rejected approaches and remaining unknowns. Future engineers need to know why a method failed, which test cases are unstable, and what the PoC mocked. Otherwise the production team pays to rediscover the experiment.

A small senior team is usually cheaper

Most PoCs need two to four active builders, not a miniature enterprise program. A practical team may include one technical lead who owns architecture and delivery, one AI or data engineer, and one product engineer who handles the workflow and integration. A domain expert and security reviewer contribute part time. One person can cover several roles on a narrow project, but each responsibility still needs a name.

Adding specialists can shorten independent work, yet PoCs contain many sequential decisions. The model choice depends on the sample. The application flow depends on early errors. The evaluation design depends on what reviewers can judge consistently. Five developers cannot parallelize a missing definition of "correct."

Senior people cost more per day and often less per answer. They cut attractive dead ends, reuse established components, and know when a demo shortcut would invalidate the test. Junior staff can contribute well when the work has clear boundaries, but a proposal built mostly around inexpensive hours may spend those hours discovering the boundaries.

When comparing vendors, ask them to price the same scope on a single page and return the assumptions separately. Examine the proposed evaluation, exclusions, client time, ownership of artifacts, and production gaps. A low total with no labeling, security review, or error analysis is a different product, not a better price.

Ask who will actually work on the project. Sales credentials do not matter if the named technical lead disappears after kickoff. Request one anonymized example of a test artifact, such as an acceptance matrix or failure analysis, rather than a collection of polished interface screenshots. You are checking how the team reasons about evidence.

Avoid a percentage contingency hidden inside every line. Put uncertain work into an explicit allowance with a trigger and a ceiling. For example, the agreement might include up to forty hours for document normalization, used only if the readiness check finds the listed format problems. The buyer sees the risk, and the vendor does not need to assume the worst everywhere.

Ownership also affects price. Clarify who owns custom code, prompts, labeled examples, evaluation cases, and generated documentation, plus which reusable vendor components remain theirs. A cheap PoC that cannot be maintained or retested without the original vendor may create an expensive dependency. That can still be an acceptable trade when speed matters, but make the choice before signing.

Cheap PoCs work only when the question is narrow

A PoC below $15,000 can be useful when the data already exists, the workflow has one step, an existing model can do the work, and the decision needs limited evidence. A technical spike lasting a week may determine whether a file format can be parsed, whether an API supports the needed response time, or whether a small labeled sample shows any predictive signal.

Do not buy a cheap PoC when the decision carries high risk or requires several departments to trust the result. Compressing evaluation, access control, or domain review does not remove the work. It moves the work after the demo, when expectations are harder to reset.

Tools that require little or no programming are good for testing an interaction or an internal workflow with modest volume. They cut interface and orchestration work when their connectors match the systems involved. They do not repair weak labels, define success, or remove the need to test permissions and failures. Use them because they fit the uncertainty, not because the phrase "AI PoC" seems to demand custom code.

Buying an existing product is often the correct comparison. Before commissioning a build, test whether a vendor product covers the common workflow and whether your difference matters to customers or operations. Build when proprietary data, a distinct workflow, unusual controls, or meaningful unit economics create an advantage. Buy when the process is standard and configuration gets you to the decision faster.

The popular recommendation to "just build a chatbot over your documents" is wrong for many first projects. It is popular because the demo is easy and executives recognize the interface. It fails when nobody has a repeated question worth answering, permissions are messy, or the answer does not trigger useful work. Start with the expensive manual decision or handoff, then ask where AI can reduce time or error.

Production readiness is a separate budget

A successful PoC authorizes another decision; it does not erase production work. The next budget may include resilient infrastructure, monitoring, support, user training, incident response, accessibility, vendor review, data lifecycle controls, and integration hardening. None of those should be smuggled into a PoC estimate, and none should be assumed free afterward.

Ask the PoC team for a production gap report with three columns: proven, partially proven, and untested. A knowledge assistant may have proven answer quality on a frozen set, partially proven permission filtering in one environment, and left production load, disaster recovery, and ongoing content updates untested. That wording prevents "the PoC passed" from becoming "the product is ready."

Estimate the next stage before the final presentation. The estimate can remain a range, but it should identify the expensive unknowns and likely operating cost. Decision makers then compare total cost with the expected savings or revenue, not the attractive price of the first experiment.

Kill criteria belong in the original agreement. Stop if the usable data cannot support the claim, if the baseline already meets the business need, if required controls destroy the economics, or if the workflow owner will not adopt the change. A stopped PoC with documented evidence has done its job.

At oleg.is, I use a fixed Team & AI Audit to identify engineering savings and choose the first bounded transformation before anyone funds a larger build. The same discipline applies to an AI PoC: pay first to remove the uncertainty that could make every later dollar pointless.

Do not end the project with a stage demo and applause. End it with the frozen test results, failure clusters, cost projection, risk register, production gaps, and a signed decision. If the team cannot assemble that packet, the PoC produced software but did not produce proof.