Startups

Taking an AI prototype
to production.

A prototype proves something is possible. Production proves it is reliable, affordable and supportable. The gap between them is where most AI products quietly stall.

All AI for Startups →

What changes

Compare your options

None of the right-hand column is exotic. It is simply work that a prototype is correct to skip and a production system cannot.
Criterion	Prototype	Production
Input data	The examples you chose	Whatever users actually send
Failure handling	Happy path	Typed errors, retries, fallbacks
Cost	Rounding error	A line item that scales with usage
Latency	Nobody timed it	A user-facing budget you must hold
Quality	Judged by eye	Measured against an eval set
Model changes	Whatever is newest	Pinned, with regression gates
Secrets and access	In the code	Managed, rotated, least-privilege
Observability	Console logs	Traces, cost metrics, quality alerts

The three that bite hardest

Cost at real volume

Prototypes use long contexts and generous retries because nobody is counting. At production traffic that arithmetic can exceed your revenue per user. Fixing it usually means smaller models for the easy cases, caching, and shorter contexts — architectural changes, not configuration.

The long tail of real input

Users send empty strings, other languages, forty-page pastes and prompt injections. A prototype tested on curated input has no defence against any of it, and the failures are often silent rather than loud.

Quality drift nobody sees

Model versions change, your content changes, user behaviour changes. Without a regression suite the first signal is a customer complaint — by which point the drift has been running for weeks.

Questions

Questions about Prototype to Production.

How long does hardening take?

For a prototype with a sound architecture, typically four to eight weeks: evaluation infrastructure, cost optimisation, error handling, observability and security. If the architecture needs changing — commonly because cost only works with a different model strategy — it is longer, and we would say that at the start rather than discovering it halfway.

Can you work on a prototype we built ourselves?

Yes, and it is a common starting point. We begin with a review that tells you plainly whether it is a foundation with gaps or a prototype whose shortcuts are structural. Both answers are useful; only one of them is comfortable.

What if inference cost makes the product unviable?

Better to know now. There are usually levers — routing easy requests to a cheaper model, caching aggressively, trimming context, batching what does not need to be synchronous — and together they can move cost substantially — sometimes by an order of magnitude. Occasionally the honest conclusion is that the unit economics do not work at your price point, and that is worth surfacing before you scale into it.

Do we need all of this before launching?

No, and doing so is its own failure mode. Evaluation and cost visibility should come before meaningful traffic, because both get harder to add later and both prevent expensive surprises. Full observability and hardened error handling can follow real usage. What you should not launch without is the ability to tell whether quality is getting worse.