Claude Partner Network · Build Prototype / POC

Every AI proof of concept is built to be thrown away or promoted. Decide which before you start.

The two have opposite correct answers on authentication, error handling and testing. Not choosing is what costs the money.

Pexon builds an AI proof of concept as one of two things, agreed in writing before the first commit: a throwaway experiment answering one question, or the first production slice built to production standards. Pilots stall when nobody chose. Two weeks from €4,900, net of VAT.

The distinction

Two kinds of proof of concept, opposite answers

DecisionThrowaway experimentFirst production slice
What it is forAnswering one question and then being deletedBeing the first slice of the real system
AuthenticationA service account is fine. It never leaves the lab.Real identity from day one, calls carrying the caller. Retrofitting this invalidates most of the work.
Error handlingLet it crash. A stack trace is a result.Real, because the failure modes are part of what is being proven.
EvaluationOne scored run against the exit criteria, by hand.A regression suite with a signed pass bar, re-runnable on every model change.
What happens when it worksIt is written up and deleted. The next build starts clean.It goes to production with the same code, under the same operating tier.

Read down either column, not across. Each column is internally consistent and the mixture is not: a throwaway built to the right-hand column wasted most of its budget, and a production slice built to the left-hand one gets promoted anyway, under pressure, and becomes the system nobody can maintain.

What each one costs

Two rungs of the published ladder

One question

Throwaway experiment

Answers
One named question, against one threshold you set.
Built with
Whatever is fastest. Service account, no test suite, no operating story.
Ends with
A scored result, a write-up, and the code deleted.
Right when
You genuinely do not know whether the task is feasible, and a no is as useful to you as a yes.

2 weeks

€4,900 fixed, net of VAT

Built to keep

First production slice

Answers
Whether this works in production, for real users, under real permissions.
Built with
Real identity, real error handling, a regression suite with a signed pass bar.
Ends with
One use case in production, on an operating tier, in your repositories.
Right when
You are reasonably confident it is feasible and the open question is whether it survives contact with your own systems.

6 to 8 weeks

from €15,000 fixed, net of VAT

How it runs

Six stages, and stage two is the one that matters

Stage 1 and stage 2 happen before any contract and cost nothing. They are also the two that most POC engagements skip, which is why so many of them end in a demo rather than a decision.

  1. Stage 0

    Where most briefs stop

    "Evaluate whether AI can help with X." No threshold, no named owner, no stated end. This is the brief that produces a demo shown repeatedly and decided never, and it is the most common document we are sent.

    Where you are today

  2. Stage 1

    Write the exit criteria

    One sentence with a number in it, agreed by the person who will act on the result. This happens before the engagement starts, and it is free. If we cannot get to a sentence with a number, that is the finding and there is nothing worth building yet.

    Half a day, before any contract

  3. Stage 2

    Choose which kind

    Throwaway or production slice, decided against the table above and written into the statement of work. This is the decision the whole page exists to force, and it takes a conversation rather than a week.

    The gate — not a phase

  4. Stage 3

    Build against the criteria

    Two weeks for a throwaway answering one question. Six to eight for a production slice, where the identity and evaluation layers are real because they are part of what is being proven.

    2 weeks, or 6 to 8

  5. Stage 4

    Score it and say the answer out loud

    The criteria are applied in front of you, including when the answer is no. A POC whose scoring happens in a slide written afterwards was not scored.

    Half a day

  6. Stage 5

    Delete it or operate it

    A throwaway is written up and removed, with the broken assumption recorded. A production slice moves onto an operating tier. The one path we will not take is promoting a throwaway because the demo went well.

    The endpoint, decided in stage 2

The brief

What has to be written down before the first commit

  • The question, with a number in it. Not "evaluate whether AI can help with claims triage" but "on 200 historical claims, routing matches the adjuster's on at least this share, and every mismatch is reviewable".
  • Which kind it is. Throwaway or production slice, in the statement of work, with the engineering consequences from the table above spelled out.
  • The owner. One named person who can rule when the criteria turn out to be ambiguous, which they will. Not a steering group.
  • The data, and how it is reached. Which system holds it, under whose permissions, and whether a connector has to exist first. This is where POC timelines actually go wrong.
  • What a no triggers. Stated in advance. A POC with no agreed meaning for failure cannot fail; it can only be extended.
  • Who switches it off. For a throwaway, the name of the person who deletes it and the date. Unowned prototypes left running are where shadow AI comes from.

Why pilots stall

Four reasons, and none of them is model quality

Collected from engagements and from pilots we were asked to rescue rather than to build. The pattern is consistent enough to publish.

  • The data was not reachable. The brief assumed a system had an interface, and building one was the actual project — discovered in week two of a four-week POC.
  • The permission question arrived late. The prototype ran as a service account, the review asked whose permissions a request carried, and the answer invalidated the architecture rather than a detail of it.
  • There were no exit criteria, so the POC could not end. It was shown to successive audiences, each of whom asked for one more thing, and the budget ran out before a decision was taken.
  • It succeeded and nobody would operate it. No team had agreed in advance to own the output, so a working system was switched off two quarters later having changed nothing.

When we are the wrong choice

If you already know the task is feasible — and for most text and document work in 2026 you do — a feasibility POC is two weeks spent confirming the obvious, and the money belongs in the production slice. If you want a demo to secure budget rather than an answer to a question, say so: that is a legitimate need, it is a different piece of work, and pretending it is a POC produces a bad demo and a worse decision record. And if the honest blocker is that your data is unreachable, no prototype moves that; the connector or data-layer work comes first and a POC built on an export proves something about the export.

Sources: Amazon Bedrock pricing — published per model and per million tokens · Anthropic — the Model Context Protocol specification. Read 28 October 2026. Vendor documentation changes; verify against the current release.

Claude Partner Network — Certified Services Partner

Pexon Group is a Certified partner in Anthropic's Claude Partner Network (Services Track), granted on 1 October 2026. This site is published by PEXON ROMANIA S.R.L., a separate legal entity in the same group, and the party you contract with here.

Where this goes next

What a sponsor asks before signing a POC

Why does it matter which kind of POC we are building?

Because the two have opposite correct answers on almost every engineering decision: authentication, error handling, test coverage, data handling, who operates it. A throwaway that was built to production standards wasted most of its budget. A production slice built as a throwaway gets promoted anyway, under pressure, and becomes the thing nobody can maintain. The expensive outcome is not choosing.

What are exit criteria, concretely?

A sentence agreed before the work starts that says what result ends the POC, in either direction. Not "evaluate whether AI can help with claims triage" but "on 200 historical claims, the agent's routing matches the adjuster's on at least this share, and every mismatch is reviewable". The threshold is yours to set; our job is to refuse to start without one.

What happens if the POC fails its criteria?

It ends and you have the answer, which is what you bought. That is a successful engagement and we would rather say so plainly than dress it up: a two-week no is cheaper than an eighteen-month maybe. The write-up says which assumption broke, because that is usually reusable even when the use case is not.

Can a throwaway POC be promoted later?

Rewritten, not promoted, and the plan should assume that from the start. If promotion is a realistic outcome you want, buy the production slice instead — it costs more over the first six weeks and less over the first year. The one path we argue against is building a throwaway and then promoting it because the demo went well.

Who owns the POC while it runs?

A named person on your side who can make the call when the criteria are ambiguous, which they will be. A POC with no owner drifts into a demo that is shown repeatedly and decided never, and the drift is not anyone's fault — there is simply nobody whose job it is to say stop.

What does it cost?

A throwaway experiment answering one question is the two-week fixed-price entry at €4,900. A first production slice, built to production standards with the identity and evaluation layers real, is the pilot engagement from €15,000 over six to eight weeks. Both net of VAT. Model consumption is billed to you directly by Anthropic, AWS or Microsoft at their published rates.

Next step

Bring the question, and the number that answers it

Thirty minutes with the architect who would build it. If we cannot get to one sentence with a number in it by the end of the call, there is nothing worth building yet and we will say so.