You have twelve prototypes and no idea which ones are load-bearing

Ask a founding team how many prototypes they have and you’ll get a number. Ask which ones are currently reachable on the public internet, and holding a live database credential, and you’ll get a pause.

That pause is the whole problem.

Cheap generation moves the constraint

For thirty years, building a working prototype was expensive enough that scarcity did your governance for you. You had two or three, you knew what they were, because each one cost weeks.

That constraint is gone. A prototype is now an afternoon. So teams have twelve — and twelve is well past the number a team tracks by memory, which is roughly four.

The constraint didn’t disappear; it moved. It used to be can we build this? Now it’s do we know what we’ve built? Almost nobody restructures for that, because the new constraint arrives quietly and looks like productivity.

The part nobody costs in

Here’s what makes this more than untidiness.

A dormant prototype is not inert. It’s a live deployment holding real API keys, quite possibly pointed at a real database with real customer data in it, running dependencies that stopped receiving security patches the day everyone forgot about it. Nobody is watching its logs, because nobody remembers it exists.

It has no owner, no monitoring and no lifecycle — and an attacker doesn’t care that you consider it abandoned. “We’re not really using that one” is a statement about your attention, not about its attack surface.

The prototypes you forgot are the ones most likely to hurt you, precisely because forgetting is what removed the supervision.

Three rules

You don’t need a platform for this. You need three rules that someone actually enforces.

1. A registry — one source of truth

Every prototype gets an entry, and the entry is the prototype’s existence. No entry, no prototype:

• ID — a stable name, so people are provably talking about the same thing.
• Owner — a person, not a team. Teams don’t archive things; people do.
• Goal — the question this prototype exists to answer. If you can’t write it, that’s the finding.
• Target user — who it’s for.
• Status — where it sits on the promotion path (below).
• Live URL and repository — because you cannot tear down what you can’t find.

A spreadsheet is fine. The rigour is in it being complete and current, not in the tool.

2. A promotion path — an explicit bar per stage

Prototypes should move through defined stages, each with a bar that has to be cleared:

Demo → it exists and shows the idea. Validated → real users touched it and the goal question got an answer. Hardened → it’s been through prototype-to-production work: real auth, a real data model, tests, staging, observability. Launched → it’s a product, with an owner and an on-call reality.

The rule that matters: nothing advances without clearing the next bar, and status is never granted by accident.

The failure this prevents is the most common one in AI-era product building. A weekend demo gets shown to a customer. The customer likes it. Someone sends them the link. Three months later that demo is load-bearing infrastructure and nobody ever decided that it would be — it was promoted to production by enthusiasm, and it never got the work that “production” is supposed to mean.

Promotion should be a decision, not a drift.

3. An archive policy — retire on purpose

Anything not being promoted gets retired, deliberately:

• Tear down the deployment — it stops being reachable.
• Revoke its credentials — every key, every token. This is the step that actually reduces risk, and the one that’s always skipped.
• Archive the repository read-only — keep the learning, remove the ambiguity.
• Record the decision — what it answered, why it stopped. One paragraph.

Killing a prototype is a maintenance action, not a failure. It’s the point of a prototype: you asked a question and got an answer, and the code was the cost of asking, not the asset. Teams that treat archiving as admitting defeat end up paying rent on every question they’ve ever asked.

What this is really about

Rules like these read as bureaucracy for a startup, so be clear about what they buy: they’re what let you keep generating freely. The reason to have a registry, a path and an archive policy is so that twelve prototypes is a reasonable number to have.

Without them, teams eventually respond to the mess by generating less — which is the one genuinely bad outcome available here. The governance isn’t a brake on the speed. It’s the thing that makes the speed survivable.

The point

Cheap prototypes are a real advantage, and they come with a real bill: an inventory to keep, a bar to enforce, and things to kill on purpose. Three rules, none of them heavy — a registry, a promotion path, an archive policy.

If your team is somewhere past the number you can hold in your head, we do this work — triage the fleet, pick what’s worth building on, and take that one to production. Book a call and we’ll start with the inventory.