For founders with an AI-built prototype

You built an AI prototype. What do you do now?

The demo works. You built it in days, not months — with Claude, Lovable, Bolt, or Cursor — and it shows exactly the product you mean. People who see it get it. But it cannot take real users yet: there are no real accounts, no admin, no email, no safe way to change what already works. The first step was fast. The next step is suddenly unclear.

The shape of the moment

This page is for the specific situation where one of these is true:

• You are not a developer, and you built it anyway — evenings, weekends, one more prompt. It proves the idea. Now investors, first customers, or your own ambition want it to be real, and “real” means accounts, operations, support — things the prototype quietly does not have.
• You are a developer, and you generated the core in a week — deliberately, because that was the fastest way to find the product. Now you are facing the part that was never the fun part: identity, admin, email, logging, deployment. You know how to build them. You also know they will eat the next months.
• An agency or a freelancer delivered an AI-accelerated prototype and the engagement ended. What remains runs — but nobody on your side owns its shape, and the person who prompted it into existence is gone.
• The prototype quietly became the product. Real users — sometimes real money — flow through code that was never structured to carry them, and every change is now made with held breath.

In all four, the code is not the urgent problem. The urgent problem is that the prototype has no structure ready to receive the next contributor — and the next contributor is already arriving: the first hire, tomorrow’s AI session, or you, six months from now.

You inherited this system on day one

An AI-built system has, from the moment it exists, a property that took traditional software a decade to develop: the author is gone. The author was a session, and the session ended. It left no memory of why it chose what it chose. You cannot ask it. And the next session is not the same author returning — it is a new one, re-deriving the architecture from whatever the code happens to look like that day.

This is the same situation as inheriting a backend whose developers left — arrived at in ten days instead of ten years. The mental model of the system never existed in any head that persists. Every change is made by someone — human or AI — reconstructing intent from code. That is what makes a system inherited. Age was never the point.

Why more prompting does not fix this first

The reflex is to keep going: ask the next session to add accounts, then an admin, then email. Each request works, locally — that is what makes the reflex so durable. The failure mode is not bad code. It is that each session re-derives the architecture from whatever the code happens to look like; each derivation differs slightly; the same problem ends up solved three ways; rules end up living wherever a session happened to put them. Nothing about it is visible on any single day. All of it compounds. (How to use AI coding tools without creating false confidence walks through the mechanism.)

Hiring does not fix it first either. A developer arriving at a pile of session-derived code spends their first months re-deriving identity, email, admin, logging, and deployment under pressure to ship — the months that decide whether the product gets a structure or an accumulation. What is missing is not capacity, and it is not more generation speed. It is a structure that absorbs the speed: one place rules live, one worked example the next contributor — developer or AI session — can follow.

The prototype is welcome — it becomes the spec

None of this argues the prototype was a mistake, and none of it means starting over. The prototype is the most precise specification you will ever hold. Every screen in it is a product decision you already made and already tested against your own judgment — which is exactly what a written spec tries, and usually fails, to capture.

In a foundation build the prototype is treated that way: the first workflow is read out of it, not invented in a workshop. The screens that earned their keep survive — sometimes the frontend survives intact. What gets replaced is the part that was never load-bearing: the accidental backend behind the demo, exchanged for identity, admin, email, failure visibility, and deployment that connect as one system.

The honest cost: the foundation does not preserve the prototype’s internals, and it does not pretend to. It preserves the decisions the prototype encodes.

What is decided before the build starts

The first step is deliberately small, and it is free: a scoping conversation that turns the prototype into a build plan. In an AI-prototype engagement it answers, in writing:

• Which foundation modules the product actually needs — identity, operable admin, email, failure visibility, deployment — and which are deferred.
• The first workflow, named and bounded — read out of the prototype, end to end: sign-up to action to admin to email to failure record.
• What survives — which screens and flows carry over as the spec, and which parts were demo scaffolding.
• Where it deploys and who owns the hosting account.
• What is explicitly out of scope, and the risks named before any code is written.

Those answers become the scope of the fixed €10,000 Prototype to Product + First Workflow package — agreed in writing before any work is billed.

The foundation it plans for is not a diagram. It is the working shape of two live products — CompanyGraph and the site you are reading — and it reports its own existence:

When the System Report is the right first step instead

One version of this situation needs a different door. If the prototype has already become the production system — real users, real money flowing through it, integrations accreted across months of sessions, and no one who can say what breaks when something changes — then it is no longer a prototype. It is an inherited system with stakes, and the honest first step is the System Report: a read-only, fixed-scope investigation that maps what the system actually does and what is safe to change, before anything is rebuilt. Forcing that situation into a fixed-price build means pricing risk nobody has seen.

You do not need to diagnose your own system to choose the right door. That call is short, and the first conversation makes it honestly.

When this is the wrong fit

If the prototype is a brochure site with a contact form, it does not need a foundation — keep it simple. If it is an experiment you may abandon next month, keep prototyping; a foundation pays for itself only once the product is meant to carry users. And if you already run a structured backend — identity, admin, deployment in place — your question is feature work, not foundation work.

The foundation fits the narrow, common moment in between: the prototype has proven the product, and the next money — yours or an investor’s — should land inside a structure, not beside one.