The four readiness bands for AI-built apps

Most AI-built products look finished in a demo and fall apart under a second user, a payment, or a security questionnaire. Judging that gap needs a shared scale, not a vibe. Kyln grades AI-built and prototype products into four readiness bands: Prototype, Fragile, Hardening and Sellable. This page is the scale itself: how a product lands in a band, what each band means for a founder, and where to get a grade of your own.

One hard fact up front: this is not a sample report. It does not claim how many apps sit in each band, and it does not invent a grand "N". Those numbers ship only when enough genuine scorecard completions exist to publish them without padding. Until then, the useful public asset is the framework: the thing others can reuse, cite and grade against.

Why a named scale beats "is it production-ready?"

"Is it production-ready?" is a yes/no question that collapses four very different states into one word. A weekend Lovable or Bolt build that signs one user in is not the same object as a Cursor-built product with migrations, staging and a rollback path. Both can "work". Only one of them is close to something a serious buyer would trust.

A named band does three practical jobs:

1. Stops the 90% illusion. A convincing demo rarely means the product is nearly finished. The unglamorous nine tenths (auth enforcement, permissions, backups, rollbacks, observability) are exactly what a demo never exercises. A band makes that gap explicit rather than polite.
2. Gives the next step a shape. Prototype and Fragile usually mean deliberate surface work before sales pressure. Hardening means a short, ranked punch-list. Sellable means protect what is already there as volume grows.
3. Makes conversation comparable. Two founders, two tools, one shared language. That is what a free scorecard needs to be useful: a result a non-technical founder can defend to a co-founder, an investor or a buyer.

The free Production Readiness Scorecard is the instrument that produces the band. The methodology is the full method. This page is the short, citable version of the band scale.

The four bands

Bands come from a 0–100% readiness score. Each scored question on the scorecard contributes 0 to 3 points on a maturity ladder. The percentage is the points earned over the points attainable on the path you answered, so different subsets remain comparable. Full thresholds and the ladder live on the methodology page; the short form is enough to read a grade.

The band arrives with a "% ready" figure and a one-line verdict. The detailed report (email-gated, one message, no spam) ranks the three biggest risks worst-first, each with a line on what good looks like. None of that is AI inventing a grade: the score and the band are deterministic arithmetic on the answers. A model only words the risk findings into a fixed template; if it is offline, a curated bank still returns a usable report.

What each band tends to mean in practice

These are diagnostic patterns the instrument is built to surface, not frequencies claimed from a published sample.

Prototype (0–35%)

The product does something a human can click through. Authentication is usually a login screen rather than an enforcement rule. Access control, if present, is "hide the button". Deploy is often one environment called production. Secrets may sit wherever they made the demo work.

Typical founder mistake: treating the peaceful demo as evidence the product is nearly shipped. The reverse is usually true. At this band the honest next step is almost never "add features". It is deciding whether the data model is sane enough to harden in place, or whether a salvage, refactor or rebuild call is the grown-up answer.

Fragile (36–60%)

The product has more structure than a weekend build. Some of the fundamentals exist; they are not reliable under pressure. Row-level security that was never tested with a second user. A backup that has never been restored. A staging environment that does not mirror production. A deploy path someone else could not run.

This is the band where many vibe-coded apps live the week after the first real customer. The demo still works. The risk sits in the second session, the second customer, the first failed payment webhook. Hardening beats more polish.

Hardening (61–80%)

Fundamentals are largely present. The remaining work is specific: close the two or three gaps a demanding buyer or an insurer will ask about, test the failure paths that the demo never touches, and make operability boring. Contingent on the three headlines the scorecard ranks, this is often a short deliberate sprint rather than a nine-tenths rebuild.

Sellable (81–100%)

The product already carries most of what a buyer inspects: identity on every data path, secrets out of the browser, backups you would bet on, a deploy with a rollback, enough monitoring that a failure is noticed before a customer emails. The job shifts from building the floor to protecting it as the product and team grow. That is still work; it is a different class of work.

How the grade is made (short form)

Nine scored questions across eight dimensions: architecture, reliability, security (access and exposure), data, scalability, testing, procurement readiness and deployment. Each answer sits on a 0–3 ladder. The percentage is normalised to the questions answered so different founder paths stay comparable. The four bands above are simply cut-points on that percentage.

What the instrument deliberately does not do:

• It does not inspect the repository. It grades what you know and answer honestly.
• It does not invent severity rankings from marketing fluff. Severity tracks the answers and a fixed risk bank.
• It does not punish pre-revenue products for not having enterprise compliance theatre. It asks the questions that matter first: can strangers use this without you watching?

Full detail, worked ladder example and FAQ sit on the methodology page. When the stakes justify certainty, the paid readiness review (from £1,500) reads the actual code. The free grade and the paid review are designed to line up; only the review can verify the parts a UI cannot show.

What this page is not

• Not a sample of N reviews. Absolute counts, band mix and medians will publish only after a genuine post-exclusion sample reaches a publish gate of twenty or more. Cell counts that re-identify anyone will never publish.
• Not Kyln client outcomes. Verified client results live on work and case-study pages that name a real engagement. This page has none of those numbers.
• Not a failure-mode frequency table. Weakest-dimension frequencies need persistence that does not yet exist on scorecard leads. Those are a later refresh, not a claim invented for this page.
• Not a competitive ranking. Bands grade a product against a production standard, not against other tools' marketing pages.

When a genuine aggregate is ready, this page (or a sibling findings page) will state the period, the N after exclusions, the band mix and the median percentage, with methodology linked and no emails, names or free-text. Until then the citable asset is the scale itself.

Get a grade of your own

Two minutes, free, no account. The top-line band is instant; the detailed risk report opens with one email.

Run the readiness scorecard

If there are already real users or real money on the product, skip the wishful reading of a self-assessment and commission a readiness review: someone senior reads the code and tells you whether the honest next step is a week of hardening or something more. From £1,500.

Common questions

What are the four readiness bands for an AI-built app?

Prototype (0–35%), Fragile (36–60%), Hardening (61–80%) and Sellable (81–100%). They come from Kyln's Production Readiness Scorecard: a free self-assessment that grades how close an AI-built or prototype product is to something you can safely put in front of paying customers.

Is this page based on a large sample of scores?

No. This page explains the scale and how a grade is made. It does not claim how many products fall into each band. Public count and band-mix numbers land only once enough genuine scorecard completions exist to publish them honestly. Until then, inventing a sample would be a lie dressed as research.

How is the readiness score calculated?

As a percentage of the points attainable on the path you actually answered. Each scored question contributes 0 to 3 points; the total is divided by three times the number of scored questions answered, so different founders remain comparable. Full method is on the scorecard methodology page.

What should I do with a Prototype or Fragile grade?

Treat it as a directional read of what still stands between the product and a buyer a serious customer would trust. The free scorecard ranks three headline risks once you open the detailed report. When real users or real money are already on the line, a paid readiness review from £1,500 reads the actual code rather than relying on self-report.

How is this different from a code audit?

The free scorecard is a two-minute self-assessment. It reflects what you know and answer honestly; it does not inspect the repository. A paid readiness review does read the code. The two are designed to line up, but only the review can verify claims the UI cannot show.