A proof of concept is a kill-metric, not a mini product

A proof of concept is not a mini product. It is a time-boxed experiment that answers one question: does the riskiest assumption survive contact with reality? Teams that skip it usually skip it for a deadline. Then they spend the next two quarters discovering the model cannot hit latency, the integration has no audit trail, or nobody will use the workflow that looked obvious in a slide.

This is a software-engineering decision, not a TED talk. If the idea is an AI workflow, the commercial path is an AI proof of concept. If it is a product you intend to put in users’ hands, that is MVP development — and a different bar. App-shaped work also lives at Maxiom Apps. What follows is how to run a PoC so it produces a go / no-go you can defend, not a demo you cannot throw away.

What a proof of concept actually is

A proof of concept (PoC) is a short, scoped build that tests the assumption most likely to kill the project — technical feasibility, data access, latency, a regulatory constraint, or a user behavior you have not seen. It is not an MVP. An MVP has users and a learning loop. A prototype explores design. A PoC answers “can this work at all, under the constraints we already have?” Confusing the three is how a six-week experiment becomes an unowned production system.

Dropbox’s early video was a PoC of a behavior (people will watch a file sync), not of a codebase. Treat that lesson seriously: the artifact should be the cheapest thing that can falsify the claim. If you need a production-shaped app to learn the same thing, you are already past PoC and into MVP vs prototype territory.

When you need a PoC vs an MVP

You need to know	Run	What “done” looks like
Will this model, integration, or constraint actually work?	Proof of concept	Written go / no-go, metrics, and what you will not scale yet
Will a real user complete the job with a thin product?	MVP	Shipped slice, instrumentation, and a next-iteration list
Does the interaction even make sense?	Prototype	Design evidence, not production code

If the blocker is “agents cannot touch the system of record,” that is not a PoC of a chatbot. That is governed MCP. If Copilot or Cursor already wrote a pile of code and you need a snapshot before diligence, that is an AI code audit, not a new experiment.

How to run a PoC that can fail

1. Name the assumption in one sentence. “This classifier can block destructive shell commands at our latency budget.” Not “explore AI for engineering.”
2. Pick one success metric and a kill metric. Example: p95 under 400ms on the production-shaped payload, or we stop. Vanity dashboards are how PoCs never die.
3. Time-box it. Two to four weeks of senior time. If it needs a team of eight, you are building a product.
4. Use production constraints, not demo data. Auth, PII, and the slowest real integration belong in the experiment if they are the risk. Sanitized CSVs lie.
5. Write the throwaway rule. The PoC codebase is allowed to die. What you keep is the decision, the metrics, and a one-page architecture note — not an undocumented service in a forgotten account.
6. Staff it with people who have shipped this class of system. A junior spike is not evidence. If you need capacity rather than a decision, that is staff augmentation (Maxiom Dev), not a PoC.

Over-engineering is the usual failure. Extra features, extra environments, extra “while we are here” integrations. The other failure is the opposite: a happy-path notebook that never sees the identity, network, or data-classification rules the real system will face. Both produce false confidence.

What good looks like at the end

A usable PoC packet is short:

• The assumption you tested, in the original sentence
• What you built (and what you explicitly did not)
• The metric, the result, and whether it passed the kill line
• Risks that remain (data terms, latency at peak, human-in-the-loop)
• The recommended next SKU: stop, another PoC, AI PoC follow-on, MVP, or a governed production path

If you cannot attach that packet to an email, you did not finish. You ran a sprint.

Hire vs DIY

Do it yourself when the assumption is local, the data is already in your environment, and a senior engineer on staff can complete the experiment in two weeks. Hire when the risk is a class of system you have not shipped (custom models, PHI, agent tool access, 360/WebGL product work) or when a false positive would fund a six-month build.

Maxiom runs PoCs as senior-led, written-scope experiments — not a junior bench “playing with AI.” App-first products can start with Maxiom Apps. Healthcare / PHI experiments belong with Maxiom Labs. An AI coaching or wearable product that may have left wellness is AI health and fitness app development, not a generic chatbot spike. A longer startup path from idea to validation is in idea to proof of concept.

Questions we hear on PoCs

How long should a proof of concept take?

Most honest PoCs land in two to four weeks after a scoping call. If the calendar says a quarter, you are scoping an MVP and calling it a PoC.

Is a PoC the same as an MVP?

No. A PoC falsifies an assumption. An MVP is a product slice in front of users. Use MVP vs prototype when the question is product shape, not feasibility.

Should the PoC code go to production?

Only if you planned for that on day one (auth, tests, ownership). Default is throwaway. Promoting a spike is how you inherit an unowned service.

What if the PoC is an AI coding tool rollout?

That is not a model experiment. That is toolchain policy — see Claude Code governance and platform governance.

Do you process our data through third-party models?

Not as a default. Client systems stay in client environments. If a vendor model is the thing being tested, that constraint is written into scope.

Can a PoC include a mobile or 360 app?

Yes, when the assumption is the product interaction itself. That work is closer to Maxiom Apps and the Kuula case study than to an AI notebook.

What do we get besides a demo?

A written go / no-go, the metrics, and a recommended next engagement. The demo is evidence, not the deliverable.

What to do this week

Write the one-sentence assumption. Pick the kill metric. Time-box two weeks. If that list already feels like a political problem, you need a scoped AI proof of concept or an MVP conversation — not another brainstorm. Start with a 30-minute call.