From prototype to product: what gets added once there are live users
The app opens, the buttons work — on your screen everything is fine. The first real person will type a name with a space, submit the form twice and close the tab halfway. Below are four layers a prototype does not have, and five checks taking fifteen minutes.
The app opens, the buttons work — on your screen everything is fine. The first real person will type a name with a space, submit the form twice and close the tab halfway. 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 built an application. It opens, the buttons work, the data saves. On your screen everything is fine.
Then the first real person arrives, and it turns out they typed a name with a trailing space, submitted the form twice, opened it on 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 is supposed to go.
A prototype and a product are different things. What lies between them is not a number of features but four layers a prototype does not have by definition.
That is the very gap that loses people in training series on building apps: what comes out at the end 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. Access and who is who
A prototype does not care who uses it. A product almost always does.
What appears: registration, log-in, access recovery, separation — what one user sees and another does not.
Where it usually breaks: somebody sees somebody else's data. The most common and most expensive mistake in this layer is the "is this the right user" check being done in the interface rather than where the data actually gets served.
The practical consequence: if the project has personal accounts, that is not cosmetics but a place needing somebody who understands the consequences.
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 never arrived.
An honest boundary. Taking payments is the zone where building blind is not on. Not because it is technically hard but because the cost of an error is somebody else's money and legal liability.
What to do if that experience is not yours: say plainly to the client that a specialist does that part and you build the rest. The ability to turn down 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 wrong data, with no connection, on a repeat submission, with a file that is too large.
The rule: a prototype shows a result, a product explains a problem. A white screen with no explanation is not a technical fault, it is the absence of a layer.
Five checks to run before delivery:
- Submit an empty form
- Submit twice in a row
- Enter deliberately wrong data
- Open it on a phone
- Turn off the connection mid-action
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 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 and 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 on processing them appear. That is a legal rather than a technical part of the project, and it gets discussed with the client before rather than after.
What else changes
Three things that are not layers but without which delivery will not work.
Speed. On your computer everything is fast. For somebody on a phone with a weak connection it may not be.
Support. Who fixes it if it breaks. Whether that is in the price. The absence of that point means you will get called on for free and indefinitely.
Credentials. Everything registered to the client rather than to you. A website tied to your email address is a mine that goes off in a year.
How to quote with the layers in mind
Here is the main practical conclusion for money.
A prototype and a product differ in price by several times, and the client does not know that. They see a working screen and assume the job is done.
So the quote gets built by layer rather than as one sum:
- The foundation: screens, logic, data
- Access and permissions
- Taking payment
- Error handling and validation
- Publishing, credentials, handover
- What the client pays for themselves afterwards — domain, hosting, services
- How many rounds of revisions are included
A quote of seven lines defends itself. People argue with the items rather than the total. And you can see immediately where scope can be cut rather than price.
The market price range. From my scrape of 848 listings: a multi-page website — $245–730, a system or pipeline — $490–1 460, against a $30–75 median for one-off work.
A caveat: my scraper has no separate "development" category, so the share of such jobs is understated and the ranges are a guide taken from adjacent categories and practice.
What to say to "I'll build it myself in an evening"
The objection is honest, and it will come up more and more. Arguing is pointless — yes, they will.
The answer is not about the building 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.
Building a screen and getting a working product are different tasks, and the second does not take an evening.
And the counter-question that closes the subject by itself: "when were you planning to get to it?" The answer is almost always "I never have time".
What is available on the platform
Website templates — 343 prompts, each with a ready brief running to dozens of pages: structure, typography, animation behaviour. The preview is visible before you run it. That covers the foundation so you spend your time on the layers rather than the first screen. The Plus plan.
Skills for Claude Code — more than 10 000, chains of agents for standard tasks. The catalogue is open to everyone, the files come with Basic, advanced ones with Creator+.
The engineering assistants — nine of them, including the programming mentor: they will help work out what the project is missing before delivery. From Basic.
The legal category — thirteen assistants. Personal data, terms of service, a development contract with rights passing on payment. From Basic.
Registration is free and opens three days of full Basic access.
Where to start today
One action. Take your last built project and run the five checks from the third layer: empty form, double submission, wrong data, a phone, a dropped connection.
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. Some of it comes off.
Module 5, the lesson "Analysing website performance" — a review of what you built: where a visitor stumbles, what does not work on mobile, where the path to the target action gets lost.
Module 5, lesson 12 — a local AI agent that reads the whole project. Unlike a chat, it sees every file and can walk the layers itself: where errors get handled, where data lands, where the keys sit.
What that changes. The five checks from this article you do by hand in fifteen minutes. An agent runs them across the whole project and finds what you did not think to check.
Module 5 comes with the Plus plan.
---
What to read next
[App architecture as a building](/en/blog/app-architecture-as-building) — so you know where to fix what.
[Why a project falls apart at the third revision](/en/blog/spec-coding) — how not to break what worked.
[What of this actually sells](/en/blog/what-sells-from-vibecoding) — which formats need all four layers.
[A specialist's portfolio site](/en/blog/specialist-portfolio-site) — the simple case needing fewer layers.
[Skills for Claude Code](/en/blog/claude-code-skills-guide) — the full guide to skills.