AI proof of concept with Claude: a 6-week plan

TL;DR

A Claude proof of concept earns its budget only if it can fail. Define the kill criteria before week one, measure the baseline before anyone logs in, and keep the irreversible settings out of the POC entirely. Six weeks is enough for one use case with one cohort. Anything broader produces an opinion rather than a decision.

What does a proof of concept have to prove?

A POC has to prove three things: that the output is good enough for the actual reviewers, that the review effort is smaller than the work it replaces, and that the volume claim behind the business case is real. Everything else, including whether the technology works, is already known and does not need six weeks.

That reframing matters because most POCs are scoped to answer a question nobody doubts. Claude will produce a plausible summary of a contract. The open questions are whether a lawyer accepts it, how long checking it takes, and whether the department really handles 2,000 contracts a month or 300.

What a POC cannot prove, and should not be asked to:

Question	Why a POC cannot answer it
Will this scale to 500 users?	Rate limits, support load and governance behave differently at scale
What is the annual saving?	Freed capacity converts to cash only through decisions made later
Is this GDPR compliant?	That is an assessment and a contract question, not an experiment
Which model should we standardise on?	Models change faster than the procurement cycle
Will adoption stick?	Six weeks measures novelty, not habit

What has to be set up before week one?

Four things, and three of them take longer than people expect: the account and workspace with the right residency setting, the measurement baseline, a defined reviewer cohort, and the kill criteria signed off by whoever will stop the project. Start the clock after these are done, not before.

The residency setting is the one genuinely irreversible decision, so handle it first. Workspace geo is fixed when a workspace is created and cannot be changed afterwards, and only "us" is currently available, per the data residency page. On the first-party API, inference_geo accepts only "global" and "us". If the POC uses real personal data and the production route has to be an EU region, run the POC on that route from the start, on Bedrock, Google Cloud or Microsoft Foundry, where the endpoint or inference profile determines the region. Our Claude data residency guide lists the settings per route.

Our recommendation for the setup order:

1. Decide whether the POC uses real data. If yes, the residency route and a processor agreement come first, and that is a two to four week lead time in most organisations. If no, use synthetic or anonymised data and start immediately.
2. Create a dedicated workspace. Never run a POC in a workspace you intend to keep, because the geo setting is permanent and the POC’s keys and spend will pollute the reporting.
3. Switch measurement on. The spend report refreshes daily with a one-day delay and supports custom ranges reaching back 90 days, so a baseline from before the POC is available only if you capture it first.
4. Name the reviewers, not the users. The reviewer cohort is what the POC actually tests. Two or three people who will check output against a source, with time allocated.
5. Write the kill criteria. Three numbers: minimum acceptable output quality, maximum acceptable review time per item, and minimum volume. Signed by the person who can stop the project.

One plan note that trips up pilots: audit logs, the Compliance API and SCIM sit on the Enterprise plan, which has a minimum of 20 seats self-serve and 50 sales-assisted. A ten-person POC cannot have them. Use the Team plan, which starts at 2 seats at 20 USD per Standard seat per month annually with up to 500 USD per month in pooled API credits, or the Console with a dedicated workspace, and accept that the governance tooling arrives with the production rollout. Our Claude Team plan guide covers what the smaller plan does and does not include.

What does a six-week POC look like?

Six weeks splits into three two-week blocks: build and calibrate, run against real volume, then decide. The decision week is non-negotiable and has to be in the plan from the start, because a POC without a scheduled end becomes a permanent pilot.

1. Week 1: calibrate on 20 known-good items. Take 20 cases where the correct answer is already known and compare. This produces the quality baseline and usually changes the prompt three or four times.
2. Week 2: measure the review loop. The reviewers check 20 fresh outputs and record the time taken per item and the error types found. This is the number the business case lives or dies on.
3. Weeks 3 and 4: run at realistic volume. Enough items to hit the volume claim pro rata. If the department says 2,000 a month, process at least 250 a week. A POC that processes 30 items has tested nothing about volume.
4. Week 5: break it on purpose. Feed the edge cases, the malformed inputs and the cases the department describes as unusual. Record what happens when the answer is wrong and nobody notices.
5. Week 6: decide against the kill criteria. Write the result against the three numbers from the setup. Build, cut, or run a second POC with a changed scope. All three are valid outcomes.

Two measurement habits separate a POC that produces a decision from one that produces enthusiasm. Record the token counts per item rather than the total, because the per-item number is the only thing that extrapolates. And record review time per item in the same table, because the ratio between the two is the whole business case.

What does a POC cost?

A POC’s token cost is almost always trivial, and its real cost is reviewer time. For a document use case processing 1,000 items with 8,000 input and 1,500 output tokens, the token spend is under 2 USD on Haiku 5.5 and about 31 USD on Sonnet 5.5. Two reviewers at half a day a week for six weeks is the expensive line.

Our arithmetic on current list prices, for 1,000 items at 8,000 input and 1,500 output tokens:

Model	Per item	1,000 items
Claude Haiku 5.5	0.0016 USD	1.55 USD
Claude Sonnet 5.5	0.031 USD	31 USD
Claude Opus 5.5	0.062 USD	62 USD

Add the three adjustments that change it: a 10 percent premium if you run on a regional endpoint, 1.1x if you use US-only inference on the first-party API, and a 50 percent reduction if the work runs as batch inference on Bedrock, which Anthropic’s models support there.

For a developer POC the figures are different and published. Claude Code averages around 13 USD per developer per active day, so a six-week POC with five developers working four days a week lands at roughly 1,560 USD in tokens. Anthropic’s own guidance is to start with a small pilot group and establish a baseline with the tracking tools before wider rollout, which is the same advice from the other direction.

Where POC budgets actually go, as our estimate rather than a sourced benchmark:

Line	Typical cost of a six-week POC
Tokens	50 to 2,000 USD depending on the use case
Seats	Two to ten Team seats, 40 to 200 USD per month
Reviewer time	10 to 20 person-days, the dominant line
Engineering time	10 to 15 person-days
Processor agreement and residency setup	0 days with synthetic data, 5 to 15 with real data

The conclusion to draw from that table: never scope a POC around saving token cost. Scope it around whether the reviewers accept the output, because their time is the budget.

Run it yourself or outsource?

Run the POC yourself when you have an engineer who can write prompts and a department willing to allocate reviewer time. Bring in a contracted prototype when the use case needs integration work your team cannot schedule, or when you need the result in six weeks and internal capacity is three months out. Keep the kill criteria and the reviewer cohort in house either way.

What an external prototype engagement should and should not own:

Element	Who should own it
Prompt and pipeline construction	External is fine
Integration with internal systems	External, with your code review
Reviewer cohort and quality judgement	You, always
Kill criteria	You, signed before the start
Residency and workspace creation	You, because the setting is permanent
The final recommendation	You. The builder is not a neutral judge

Our view: a contracted prototype is good value for the engineering, and poor value for the evaluation. A party paid to build the prototype has an interest in the prototype succeeding, however honest they are. Keep the quality judgement with the people who will live with the output, and keep the decision with the person who signed the kill criteria.

What to demand from a contracted POC:

1. Kill criteria written into the statement of work, with your three numbers in it.
2. Per-item token counts and per-item review times in the final report, not totals.
3. At least 250 items processed per week in the volume phase, not a demo set.
4. An edge-case week with the failures documented rather than smoothed over.
5. The prompts, pipeline and evaluation set delivered as code in your repository.
6. No production workspace created by the vendor, since workspace geo cannot be changed later.

Our AI business case guide covers how to turn the POC’s two numbers into a portfolio decision, and our Claude API key guide covers the account setup paths including the routes that need no Anthropic account.

FAQ

What is an AI proof of concept?

An AI proof of concept is a time-boxed experiment that produces a build-or-cut decision. For Claude it should test three things: whether the output passes the real reviewers, how long reviewing each item takes, and whether the volume claim behind the business case holds. It is not a test of whether the technology works.

How long should a Claude POC run?

Six weeks for one use case with one reviewer cohort: two weeks to calibrate and measure the review loop, two weeks at realistic volume, one week breaking it on purpose, one week to decide. A POC with no scheduled end date becomes a permanent pilot and never produces a decision.

What does a Claude POC cost?

Token cost is usually trivial: under 2 USD on Haiku 5.5 or about 31 USD on Sonnet 5.5 for 1,000 document items, and roughly 1,560 USD for a five-developer six-week Claude Code pilot at 13 USD per developer per active day. The dominant line is reviewer time, typically 10 to 20 person-days.

Which plan should a POC run on?

Team or the Console with a dedicated workspace. The Enterprise controls, including audit logs, the Compliance API and SCIM, require a minimum of 20 seats self-serve or 50 sales-assisted, so a small pilot cannot have them. Team starts at 2 seats at 20 USD per Standard seat per month annually.

Which POC decisions are irreversible?

Workspace geo, which is fixed at workspace creation and currently offers only "us". Create a throwaway workspace for the POC and never run it in one you intend to keep. If the production route needs an EU region, run the POC on a regional endpoint on Bedrock, Google Cloud or Microsoft Foundry from the start.

POC vs pilot: what is the difference?

A POC answers whether to build and ends in a decision. A pilot assumes the decision is made and tests the rollout: enablement, support load, governance and adoption. Running a pilot while calling it a POC is how organisations end up with a production dependency nobody approved.

Sources

1. Anthropic: Model and feature pricing (28 October 2026)
2. Anthropic: Data residency (28 October 2026)
3. Claude Code: Manage costs effectively (28 October 2026)
4. Anthropic Support: What is the Enterprise plan (28 October 2026)
5. Anthropic: Claude pricing plans (28 October 2026)
6. AWS: Amazon Bedrock pricing (28 October 2026)
7. Anthropic Support: Usage analytics for Team and Enterprise plans (28 October 2026)