Prototype, MVP, and Production Product
A prototype proves that an idea can be represented. An MVP tests whether a small but usable product creates value. A production product is prepared for continued use, operational failures, real data, and ongoing maintenance.
What You Will Be Able to Decide
- Distinguish a prototype from an MVP.
- Explain why an MVP is more than an unfinished product.
- Identify when production safeguards become necessary.
- Classify a proposed product stage.
- Ask a consultant what risks have intentionally been deferred.
A founder asks a consultant to build an application.
The founder may describe the first version as an MVP. The consultant may hear a prototype. The users may assume they are receiving a production product.
All three parties can use the same words while expecting different levels of reliability.
The difference matters because product stage changes what should be built, tested, documented, protected, and maintained.
The same distinction helps with personal software. A private reading tracker can begin as a rough experiment, but once it stores irreplaceable notes or becomes part of a daily routine, backup and recovery become part of the product decision.
Start Here: Build a Request Tracker with Fictional Data
You can work through this path without learning a programming language first. You will still need to describe the result, inspect it, and check that it behaves as promised. The practice project is a request tracker: add a fictional request, view the list, edit its status, delete it after confirmation, and export your records.
Use one person, one browser, and made-up records for the first version. Leave payments, customer logins, email sending, and live integrations out of the first build. A small complete workflow is easier to understand than several impressive screens that do not work together.
Read the MVP guide first, then AI-assisted building, testing, and infrastructure. Keep a project folder containing your brief, screenshots, test results, and launch notes. Each guide produces something you can use in the next stage.
- Write the problem: I lose track of requests and need to see which ones are new, in progress, or done.
- Name the first user: me, using fictional data in one browser.
- List the fields: request title, notes, status, and date created. Decide which are required.
- Describe success: I can add, find, update, delete, and export a request without losing another record.
- Choose a stopping point: a tested browser-only demonstration before real users, accounts, or shared data.
Give the AI a Brief You Can Check
A requirement says what the app needs to do. An acceptance check explains how you will know it did it. Write both in ordinary language before asking for code. The model can suggest missing cases, but you decide what belongs in this first version.
For the request tracker, define allowed status values and what happens when the title is empty. Decide whether deleting a record requires confirmation, whether cancelling leaves it untouched, and what an empty list should show. Include phone-sized screens, clear labels, keyboard access, and helpful error messages.
Keep a short list of assumptions. Browser storage belongs to that browser and website address; it is not a shared database or a backup. If the real goal is a team app, say that now so the later data and permissions work is planned rather than hidden.
Before collecting real records, decide which details are necessary, who can view and change them, how long they are kept, and how an owner can delete or export them. Agree whether a team shares every request or sees only assigned requests. Use those decisions as testable rules rather than assuming a login makes the data private.
Help me define a small request tracker for one beginner. Use fictional data. Before coding, propose the screens, fields, allowed statuses, storage choice, acceptance checks, and what we are deferring. Explain each technical term when it first matters. Ask about choices that change the outcome. Keep the first version small enough for me to inspect.Own the Accounts, Source, and Spending Limit
Use an AI builder that gives you a working preview and access to the source files, or an assistant that can work inside a project folder. Create the project, source repository, hosting, and any later database account under an account you control. Enable the account's two-step verification and keep recovery details somewhere private.
A repository is the project's saved source and change history. A commit is a named snapshot; a branch is a separate line of changes. You can use GitHub's web interface or a desktop client, and ask the agent to explain its equivalent workflow. You do not need to memorize Git commands to understand which version is saved and which version is live.
Set a spending ceiling before enabling model APIs, hosting upgrades, or a database. Ask what costs depend on usage, how you will see the bill, and how to stop the service. Store passwords and API keys in the appropriate secret settings, never in an ordinary prompt, screenshot, public repository, or browser-delivered code.
What Does a Prototype Actually Prove?
A prototype is used to explore or demonstrate an idea.
It may show how screens connect, how a technical concept could work, or how a user might complete a task. A prototype can be interactive without being dependable.
Think of it as a model apartment. It helps someone understand the layout and appearance. It does not prove that the full building has reliable plumbing, fire exits, legal approvals, or long-term maintenance.
A prototype may contain:
- hard-coded sample data
- incomplete workflows
- temporary integrations
- limited error handling
- no user permissions
- no backup strategy
- no operational monitoring
This can be reasonable when the purpose is demonstration or learning.
The danger begins when a prototype quietly becomes the live product without its risks being reviewed.
Technical term
MVP
MVP means minimum viable product. “Minimum” limits the scope. “Viable” means that the product is useful enough to test with its intended users. “Product” means that the core workflow is complete enough to be used rather than merely demonstrated.
What Must an MVP Workflow Include?
An MVP for a booking product may allow a user to:
- find an available time
- make a booking
- receive confirmation
- allow the business to view the booking
It may exclude:
- advanced analytics
- multiple calendar providers
- loyalty programmes
- complex team permissions
- automated marketing
- extensive personalisation
The excluded features reduce scope. The included workflow still needs to function coherently.
An MVP should test a meaningful assumption, such as:
A collection of incomplete features does not answer that question.
Will independent consultants use a simpler booking system if it reduces administrative work?
What Changes When Real Users Depend on It?
A production product is prepared for continued real-world use.
“Production” refers to the live environment used by real users. It does not mean that the product is finished forever.
Production readiness usually introduces concerns such as:
- authentication
- authorisation
- backups
- monitoring
- error reporting
- data recovery
- deployment rollback
- privacy
- security updates
- documentation
- support
- account ownership
How Much Production Protection Does This Product Need?
The stage cannot be chosen through appearance alone.
A basic internal tool used by three employees may tolerate several hours of downtime.
A product processing payments or medical information requires stronger safeguards even when it has very few users.
Ask:
- Does it store sensitive data?
- Can it move money?
- Can one user access another user’s information?
- What happens if the data is lost?
- What happens if the service is unavailable?
- Can the team recover from a failed deployment?
- Who is responsible for maintenance?
The answers determine which production controls are already necessary.
What Warning Signs Should You Look For?
- Nobody can clearly state whether the current build is a prototype or live product.
- Real users are entering data into a system built only for demonstration.
- “We will add security later” has no defined review point.
- The product has no documented backup or recovery process.
- Critical accounts are owned by an individual contractor.
- A polished interface is being used as proof of production readiness.
What Should You Ask a Consultant?
- What stage is the current product actually prepared for?
- Which risks have been deliberately deferred?
- What would prevent us from giving this to real users today?
- Which production controls are already required because of our data or workflows?
- What must be completed before the next user group is invited?
- How would we recover if the next deployment failed?
Key takeaway
Key Takeaway
A prototype demonstrates an idea. An MVP tests a useful assumption. A production product accepts responsibility for continued real-world use.
Continue the Beginner Path
Use the same fictional request-tracker project through planning, building, testing and deployment. Each stage gives you an artifact to carry into the next.
Reuse the Guide with Your AI Assistant
The bd-guide-skillsfolder turns this path into a reusable skill. Open its SKILL.md, follow your assistant's skill-loading instructions, and ask it to guide your own small app through the four stages. Read the scope and permissions before use.
A Relevant Companion Skill
Marketing behavior and decision frameworks — Clarify who needs the app, the task they want to complete, and the evidence behind the offer.