From prototype to product: what gets added when live users appear

From prototype to product: what gets added when live users appear

The application opens, the buttons work — on your screen everything is fine. The first live person will enter a name with a trailing space, submit the form twice and close the tab halfway through. Below are four layers a prototype does not have and five checks taking fifteen minutes.

The application opens, the buttons work — on your screen everything is fine. The first live person will enter a name with a trailing space, submit the form twice and close the tab halfway through. Below are four layers a prototype does not have and five checks taking fifteen minutes.

Working for you does not mean working for everyone

You assembled an application. It opens, the buttons work, the data saves. On your screen everything is fine.

Then the first live person arrives, and it turns out he entered a name with a space at the end, submitted the form twice, came in from a phone in landscape and closed the tab halfway.

You checked none of that, because you were working as a user who knows how it should be done.

A prototype and a product are different things. Between them lies not a number of features but four layers a prototype does not have by definition.

That is the very gap that loses people in tutorial series on assembling applications: what comes out is a snake game or a practice meditation app — working and needed by nobody. It cannot be sold and cannot be shown to a client.

Let us go through what gets added.

Layer 1. Entry and who is who

A prototype does not care who uses it. A product almost always does.

What appears: registration, login, access recovery, separation — what one user sees and another does not.

Where it usually breaks: a person sees somebody else's data. The most common and most expensive error at this layer is the "is this the right user" check being done in the interface rather than where the data is actually served.

The practical consequence: if the project has personal accounts, that is not cosmetics but a place where somebody who understands the consequences is needed.

Layer 2. Money

The most frightening layer, and rightly frightening.

What appears: taking payment, a "paid" status, what happens on a failed payment, refunds, documents.

Where it usually breaks: the payment went through and access did not open. Or the reverse — access opened and the money did not arrive.

An honest boundary. Taking payments is the zone where you cannot build blind. Not because it is technically hard but because the cost of an error is other people's money and legal liability.

What to do if that experience is not yours: tell the client plainly that this part is done by a specialist and you assemble the rest. The ability to decline a piece of a task is worth more than the ability to take all of it.

Layer 3. Behaviour on errors

The layer that separates a product from a mock-up more than any other, and it is almost always skipped.

What appears: what gets shown on an empty form, on invalid data, with no connection, on a repeat submission, on a file that is too large.

The rule: a prototype shows the result, a product explains the problem. A white screen with no explanation is not a technical failure but the absence of a layer.

Five checks to run before delivery:

Fifteen minutes. They catch most of what a client will find on day one.

Layer 4. Data and what happens to it

What appears: where the enquiries actually land, whether a notification arrives, whether they can be exported, whether there is a backup, what gets deleted and when.

Where it usually breaks: the enquiries arrive but nobody looks at them. Or they sit somewhere they cannot be retrieved from.

Separately on personal data. As soon as you collect names, phone numbers and email addresses, requirements for their processing appear. That is a legal part of the project rather than a technical one, and it is discussed with the client before rather than after.

What else changes on the way to a product

Three things that are not layers but without which delivery does not happen.

Speed. On your computer everything is fast. For somebody on a phone with a weak connection it may be different.

Support. Who fixes it if it breaks. Whether that is in the price. The absence of that point means you will be interrupted for free and indefinitely.

Credentials. Everything registered to the client rather than to you. A site tied to your email address is a mine that goes off in a year.

How to price with the layers in mind

Here is the main practical conclusion for money.

A prototype and a product differ in price by several times over, and the client does not know that. He sees a working screen and thinks the job is done.

So the quote is drawn up by layer rather than as one sum:

A seven-line quote defends itself. People argue with the items rather than the total. And you immediately see where the scope can be reduced rather than the price.

The order of market prices. From our bot's feed of 5 986 jobs over four months: a multi-page site $245–730, a system or a pipeline $490–1 460, against a median one-off job of around $60.

A caveat: my parser has no separate "Development" category, so the share of such jobs is understated and the ranges are a guide from adjacent categories and from practice.

What to say to "I will assemble it myself in an evening"

The objection is honest, and it will be heard more and more often. Arguing is pointless — yes, he will assemble it.

The answer should be not about assembly but about the four layers: what happens when somebody enters data wrongly, where the enquiries land and who retrieves them, what happens to a payment on a failure, who fixes it in a month.

Assembling a screen and getting a working product are different tasks, and the second does not take an evening.

And a return question that closes the subject by itself: "when were you planning to get to it?" The answer is almost always "never quite got round to it".

What the platform offers for finishing a product

Site templates — 343 prompts, each with a ready brief running to dozens of pages: structure, typography, animation behaviour. The preview is visible before launch. That covers the base so you spend your time on the layers rather than on the first screen. Plus plan.

Skills for Claude Code — over 10 000, chains of agents for standard tasks. The catalogue is open to everyone, the files come with Basic, advanced ones with Creator+.

The "Engineers" category assistants — nine of them, including the programming mentor: they will help work out what is missing in a project before delivery. From Basic.

The legal department — thirteen assistants. Personal data, terms of service, a development contract with rights passing after payment. From Basic.

Registration is free and opens three days of full Basic access.

Where to start today

One action. Take your most recent assembled project and run the five checks from the third layer: empty form, double submission, invalid data, phone, connection dropped.

Fifteen minutes. Usually three of the five fail — and that is exactly the difference between "works for me" and "can be handed to a client".

Fixing them will not make you a developer. But it will make the product a product.

How to check the layers rather than guess

The four layers and five checks above are manual work. Part of it can be removed.

The lesson “Working with files. Site performance analysis” in the “Automator” course — an examination of what you assembled: where a visitor stumbles, what does not work on mobile, where the path to the target action gets lost.

An agent in Claude Code with the skills from the list below reads the whole project. Unlike a chat, it sees every file and can walk the layers itself: where errors are handled, where data lands, where the keys sit.

What that changes. You do the five checks from this article by hand in fifteen minutes. The agent runs them across the whole project and finds what you did not think to check.

The “Automator” course is included in the Plus plan, and the skills below are advanced (Creator and up, or $9 one-off, or 1000 XP).

What to study for this transition

The “VIBE CODING” and “AI-Assistants” courses, Creator plan — they cover exactly the finishing: not "how to assemble quickly" but how to make what you assembled survive the first live user.

The express course “Claude: from the first prompt to your own library of mega-abilities”, Creator plan — structured prompts and your own Skills for the task. Connecting agents to real data through MCP is covered by the express course “AI agents” (Creator, Make, N8N, Full plans) and the FastMCP skill. A prototype lives on invented examples, a product on real ones, and that is separate work.

Ready interfaces instead of your own. The Application interfaces section, Plus plan — prompts for dashboards, account areas, mobile screens. What in a prototype is usually drawn "however it turned out" is already designed here.

Assistants, Basic plan: Software engineer — a code review before delivery. UX designer — how the product is perceived by somebody seeing it for the first time. Programming mentor.

Skills for the move from demo to product

All the skills below are advanced: Creator and up, or $9 one-off, or 1000 XP.

The main difference between a prototype and a product in one sentence. The fourth item: in a prototype you do what is clear first, in a product you do what is unclear first. Otherwise the unclear surfaces at the end and everything gets rewritten.

What to pick up on the platform for this task

What to read next

An application's architecture as a building — so you know where to fix what.

Why a project falls apart at the third correction — how not to break what was working.

What sells from what you assemble — which formats need all four layers.

A specialist's portfolio site — the simple case, where fewer layers are needed.

Skills for Claude Code — the full guide to skills.

Also on AI SKILLS