Working Prototype

A working prototype is an early version of a product or feature with enough real functionality to test a specific assumption. It does not need production-ready code, complete design, or every planned feature. It does need the behavior that your test depends on.

For example, a team designing a booking service could build a simple flow that checks actual appointment availability and confirms a reservation. This working behavior lets participants test whether the booking experience makes sense. A set of linked screens could test navigation, but not whether availability and confirmation work correctly.

A working prototype is one of several ways to explore an idea. Start by deciding what you need to learn, then choose the lightest method that can produce useful evidence. See the prototype guide to compare approaches.

When should you build a working prototype?

Choose a working prototype when the question requires real behavior, rather than only a visual explanation or a simulated interaction.

• A core calculation matters. A pricing estimator must perform realistic calculations to show whether users understand and trust the results.
• A specific integration matters. A prototype can test whether a payment, calendar, or API handoff works under the intended conditions.
• An end-to-end task matters. Participants need to complete a meaningful interaction and encounter realistic success or error states.

Do not build functioning software simply because it looks more convincing. For early feedback on labels or screen order, a paper prototype or clickable prototype may be faster. If you need to test the value of a service before automating it, consider a Wizard of Oz experiment.

The sections below also discuss physical prototypes, stakeholder demonstrations, and production decisions. These are useful applications, but a working prototype is not a mandatory stage for every idea. Choose the fidelity needed for the specific question rather than building the most elaborate version by default.

The importance of working prototypes

A working prototype is a precursor, a harbinger of a product that is constructed to test a concept or process. It serves to demonstrate to investors and marketing companies the viability of an idea.

It is essential not to underestimate the significance of a working prototype. Attempting to cut corners by skipping the functional prototype stage and moving forward without having demonstrated the functionality of your product to yourself and others would be a grave mistake. The adage holds true, “a picture is worth a thousand words,” and a working prototype will effectively convey the seriousness and professionalism of your new product or invention.

The process of building a working prototype

To achieve the desired level of fidelity, working prototypes are implemented with the bare minimum necessary to collect feedback from users as if it were a finished product. For physical products, 3D printing, fabrication, and the utilization of “off the shelf” parts are commonly employed to construct and develop functioning prototypes. Conversely, for digital products, real code is used to make light features work as if they were in the final product.

For digital products, AI app builders such as Lovable, Bolt, v0 and Replit have changed what “working” costs. A product manager or designer can describe a feature in plain language and have a deployed web app with a database, login and real data in a day or two, without waiting for engineering capacity. AI coding assistants do the same for developers working in an existing codebase.

The process of building a working prototype involves creating a functioning digital or physical model of a product’s design that a target user can then test. Understanding how to create a prototype is a crucial step in the journey of transforming an idea into a manufactured product.

Why create working prototypes?

Building a working prototype can yield many benefits:

• Assessing Functionality. Building a model of your proposed idea can aid in determining whether your product functions as intended. After testing your product with a prototype, you can determine whether it is worthy of further investment in time and money. Furthermore, it allows for adjustments to be made to ensure optimal performance and customer satisfaction.
• Cost-Effectiveness. Creating one or two prototypes is typically a less expensive process than mass-producing a product without testing it first. This is because a prototype allows for the perfecting of the product’s design before incurring the expense of production and potentially having to recall the product due to defects. Additionally, it can be used to ensure the production process is economically viable.
• Demonstrating to Investors. A prototype of your product can also aid in showcasing to investors what your product aims to accomplish and how well it works. It also offers the opportunity to answer any questions they might have about the product, thereby convincing them of its worthiness as an investment.
• Determining Usefulness. Allowing select members of your intended audience to use your prototype can help determine whether they find the product to be useful. Feedback can be gathered to learn more about what they like and what might require improvement, leading to the creation of an even more useful prototype or advancing towards mass-production.
• Highlighting Appropriate Materials. A prototype can aid in determining specific materials required and the outline of the eventual product’s shape. It can also help determine that changing the shape or fastening parts together differently can make the product sturdier than originally believed.
• Facilitating Discussions. Developing a prototype can provide specific, clear answers to questions about the product’s dimensions, weight, mobility, and other aspects. This can aid external parties in determining whether they want to invest in or assist with the final product.

When is my working prototype ready for production?

The mockup process, from the first working prototype to the last, is a costly and time-consuming endeavor that can be mentally taxing. Through extensive testing, reworking usability issues, and rethinking design decisions, you might ultimately arrive at a product that is ready to take to market. A conclusion might also be that your product idea is not better than current market standards or just doesn’t have a market to serve.

Problem-solution fit vs product-market fit

A working prototype focuses more on problem-solution fit than product-market fit. A working prototype is an early example, model of a product built to test a concept or process to be learned from or to show investors and marketing companies. It allows for testing of the product’s functionality and usability, and it can help to identify and solve any issues that may arise with the design. However, a working prototype is not necessarily a good way to test whether a product has merit in a market.

Product-market fit is the process of determining whether there is a market for a product and whether the product is the right fit for that market. It involves researching target customers, understanding their needs and pain points, and determining whether the product can effectively solve their problems. While a working prototype can help to test and improve the problem-solution fit, it may not necessarily be able to test whether there is a market for the product.

For example, a working prototype of a product may function perfectly and solve a specific problem, but it may not be something that people are willing to pay for or that they even need. In contrast, a product-market fit evaluation would test whether there is a demand for the product and whether it is a good fit for the target market. Therefore, a working prototype is a useful tool for testing and improving the problem-solution fit, but it is not the only tool that should be used to evaluate a product’s potential in the market.

Testing problem-solution fit

However, a working prototype can help determine whether a solution works well to solve a specific problem. In this regards, consider the following four qualities:

• Problem Solving. It solves the problem you set out to solve.
• Expected Results. It gives you the results you’re looking for.
• Differentiation. It differentiates itself from other similar products on the market.
• Superiority. It’s the best option out there.

Ultimately, a successful product-solution fit comes down to the user experience. If the user experience cannot be improved upon by other products, the prototype may be ready to be market-tested.

What should you test?

Intention and customer problems

To ensure your project is moving in the right direction, consider the following questions as you create your prototype

• User Expectations. Before users even view the prototype, what would they expect to be able to do with it? How would they expect it to look?
• Comprehension. Once the prototype is shown to users, do they understand what it does? How does it measure up to their expectations?
• Missing Features. What features are missing from the prototype?
• Design Elements. Does anything seem out of place or unnecessary?
• User Experience. How do users feel when using the prototype?
• Wishlist. If users had a magic wand, what would they change about the product?
• Likelihood of Use. How likely are users to use this product once it is finished?

First glance

A critical aspect of the design process is ensuring that the design effectively communicates the purpose and functionality of the product or website at first glance. To validate this, consider the following questions:

• Product Purpose. What do you think this product is for?
• Functionality. What do you think can be done on this website, in this app, or with this product?
• Use Case. When would you use this product or website?
• Target Audience. Who do you think this tool is for?
• Associations. Is there anything this tool resembles? If yes, what?
• Confusion. What, if anything, doesn’t make sense in the design?

Tasks specific use-cases

To effectively evaluate the usability of your website or product, it is essential to develop task-specific questions that align with the actions users will take within your industry. There are no catch-all questions in this category, as that will depend solely on the specific product you are developing. However, consider the following examples for inspiration.

E-commerce and Retail

• How did you recognize that the product was on sale?
• What information about shipping was missing, if any?
• What were the accepted payment methods?

SaaS

• How did you know the plan you picked was the right one for you?

Travel

• Do you think booking a flight on this website was easier or more difficult than on other websites you have used in the past?

Banking and FinTech

• Did sending money via this app feel safe?

Internet

• Do you think data gathered by this app is reliable?

Usability

As you evaluate your prototype, it is crucial to address any lingering concept, flow, or basic usability issues. To do so, consider the following questions:

• Functionality. Does the prototype fulfill its intended purpose?
• Design Alignment. Do users believe the product’s design aligns with its intended purpose?
• Intuitiveness. What is the first action users would want to take on the product? Can they do so easily?
• Confusion. Does exploration of the product lead to confusion at any point?
• Distraction. Are there any elements that distract or impede the user experience?
• Ignored Features. Are there any features that are consistently ignored by users?
• Information Architecture. Does the information architecture and navigation make sense? Can users easily find what they are looking for?
• Target Market Relevance. Does your target market feel that the product was designed for them?
• Frequency of Use. What would make users want to use the product frequently?
• Recommendation. How likely are users to recommend the finished product to a friend?
• User Description. How would users describe the product using their own words?

Planning your next session: Recruiting future testers

Instead of recruiting brand new participants for each testing session, consider asking current testers if they would be interested in participating in future research. Additionally, inquire if they know of anyone else who might also be interested. Ask:

• Would you be interested in participating in future research?
• Who else should I talk to?

Who else should I talk to?

Consider running a first round of remote, unmoderated tests with tools such as Maze or Lyssna, which now use AI to summarize open-ended answers and recordings. Then, recruit a few select users who would be interested in coming in for a more in-depth session. This approach allows for the selection of participants based on the quality of feedback provided during initial testing, rather than bringing in participants who may not offer the same level of insight.

The Thinking Aloud and Remote User Testing plays cover how to run sessions and analyze the results.

Working prototypes in the age of AI builders

The traditional advice was to save working prototypes for last because they were expensive. For many digital products that is no longer true: building is now often faster than designing a polished clickable prototype. That shifts where the risk lies.

• Speed makes it tempting to skip the question. When building takes an afternoon, it is easy to build first and think later. Write down the assumption you are testing and the behavior that would change your mind before you prompt the builder. Development speed is becoming a commodity; deciding what is worth testing is not.
• A working prototype is still not a product. Generated code is rarely secure, maintainable or scalable. Treat it as disposable, avoid collecting sensitive customer data in it, and check the builder’s handling of authentication and data before real users sign in. AI-assisted coding is fast, but structure still moves slow.
• Polish distorts feedback. A prototype that looks finished invites praise rather than critique, and makes stakeholders assume the work is nearly done. Tell participants it is an early version.
• Measure behavior, not just opinions. Because the prototype actually works, you can put it in front of real users over days or weeks. Add analytics, such as PostHog, to see whether people come back and complete the task, which is far stronger evidence than what they say in a session.

Cheaper ways to test?

The prototype guide compares paper, clickable, and working prototypes by the uncertainty each can help investigate. Use it to decide which behavior must function before investing in a working model.

Even when an AI builder makes the prototype cheap, the test itself is not free: you still need to recruit participants, run sessions and interpret the results. If the question is whether people understand the concept or want it at all, a Paper Prototype, a Clickable Prototype, a Fake Door or a Concierge test may answer it faster and with less risk of anchoring on one solution.

Some things can’t be tested with lower fidelity prototypes, which is when a Working Prototype is what you need to move forward. Physical products remain expensive to prototype. In that case, consider building a cheap LEGO prototype mock-up of what you want to end up with, first.

Working prototype example: appointment booking

Illustrative example, not a report of an actual study.

A team wants to introduce appointment booking for a small clinic. The risky assumption is that customers can select a real available slot and understand when the booking is confirmed.

Element	Example
Assumption	Users can select an available appointment and recognize a confirmed booking without staff assistance
Smallest working feature	A booking form, a limited set of real available slots, server-side reservation handling, and confirmation/error messages
Test task	“Book the next available afternoon appointment and check whether it is confirmed”
Evidence to collect	Task completion, mistaken expectations, duplicate booking attempts, time to confirmation, and explanations in participants’ own words
Decision	Fix unclear states or failed handoffs before adding more appointment types or expanding the service

The team does not need payment processing, a full customer portal, or polished account settings to answer this question. A working prototype isolates the behavior under test.

How to build and test a working prototype

1. State the assumption. Write a question that could change a product decision: “Can a new customer complete a real booking without help?”
2. Define the smallest realistic behavior. Identify the calculations, data, integrations, or responses that must actually work. Simulate or omit everything else.
3. Set boundaries. Use safe test data, limit access, mark unimplemented paths, and plan for errors. Avoid collecting real sensitive data unless necessary and appropriately protected.
4. Prepare representative tasks. Ask participants to attempt a real-world goal instead of telling them where to click.
5. Observe behavior. Note completion, workarounds, errors, confusion, and whether the prototype delivered the expected result.
6. Decide what happens next. Repair the tested interaction, change the concept, run another experiment, or invest in a more complete product.

Use the Experiment Sheet to record the assumption and success criteria before your session, then capture the findings in the Learning Sheet.

Working prototype vs. clickable prototype vs. MVP

Method	What it does	What it does not establish
Paper prototype	Explores layout, vocabulary, and steps using sketches or paper screens	Real response times, integrations, or working logic
Clickable prototype	Lets users navigate linked screens and try prepared tasks	That backend calculations or integrations work
Working prototype	Runs the limited functionality needed for a realistic task	Production reliability, scalability, or sustained demand
Minimum viable product (MVP)	Puts a minimal product in a real usage context to learn from actual adoption and value	Product-market fit from a single successful release or test

These categories overlap. A working prototype can be part of an MVP, and a clickable prototype can include real code. The distinction that matters is which assumptions the implementation actually tests.

What should you measure during a prototype test?

Prefer observable evidence to opinions about whether participants “like” a finished-looking design.

• Task completion: Could the person achieve the intended outcome without intervention?
• Functionality: Did the essential calculation, data retrieval, or integration produce the correct outcome?
• Comprehension: Did the person understand what the system had done, especially after an error?
• Unexpected behavior: Where did participants hesitate, take a different path, or make an incorrect assumption?
• Follow-up decision: What will the team change, stop building, or investigate next?

A prototype that works technically may still solve an unimportant problem. A successful usability session does not prove willingness to pay, repeat use, or product-market fit. Combine it with demand-focused experiments where needed.

Frequently asked questions

What is a working prototype?

It is a limited but functioning version of an idea, built so real users can attempt a relevant task and the team can test a specific assumption before full development.

Does a working prototype have to work?

The critical interaction being tested must work. Other screens and features can be simplified, omitted, or simulated. Be explicit about those limitations when interpreting results.

Is a working prototype the same as a functional prototype?

The terms are often used interchangeably. Both emphasize real behavior rather than appearance alone, though the exact scope depends on the industry and the question being tested.

What is an example of a working prototype?

A booking form connected to real availability data is one example. A pricing calculator that performs the actual calculation or a limited integration that sends and receives real data are others.

Does a working prototype prove product-market fit?

No. It can demonstrate functionality and reveal usability problems. Market demand, willingness to pay, and repeat usage require additional evidence.

What to do next

If the remaining uncertainty is about labels or navigation, try a clickable prototype. If you want to simulate advanced behavior without building the backend, explore Wizard of Oz prototyping. For a broader comparison, see prototype types and how to choose them.