Requirements written before anyone has touched the software are mostly guesses. The prototype model in software development accepts that and builds a simplified working version first, so users can test it and correct the requirements before full-scale development starts.
Teams pick it when requirements are vague or likely to shift. The main difference from waterfall is timing. Users get their hands on working software at the start of the project instead of the end.
The IEEE Computer Society’s SWEBOK Guide (V4.0, 2024) files prototyping as a technique under requirements validation. The prototype model is what you get when a whole project process is built around that one technique.
What Is the Prototype Model in Software Development?
A rough working version takes the place of the specification. Users react to it, the team adjusts, and the cycle repeats until the requirements hold up.
Most people can’t say what they need until they see something running. That is the whole reason the approach exists, and it explains why users get a prototype to react to instead of a document to approve.
The first version is the prototype. It is incomplete on purpose, with limited functionality, because its job is to produce better requirements and not a finished product.
The wider practice is software prototyping, which also shows up in Agile and design work, so the model is only one use of it.
Where the Prototype Model Sits in the SDLC
It sits at the front of the life cycle, where requirements are still soft.
Most lifecycle models fix the requirements first and build second. The prototype model puts a working draft between those two steps.
Stakeholders bring rough requirements. The team runs a quick design, builds a working prototype and has users evaluate it, then repeats the cycle until they accept it. What comes out is a set of agreed requirements, plus a prototype that is either discarded or kept as the base for the final system.
The prototype is a means of getting requirements right. It becomes the deliverable only under the evolutionary type.
Prototype vs Proof of Concept vs MVP
People swap these terms constantly, though each one tests something different.
A prototype is built to be evaluated, and often thrown away. A proof of concept is narrower, a check that the technical idea can work at all.
An MVP is different in kind. Eric Ries popularized the term through The Lean Startup and defined it as the version of a product that yields the most validated learning about customers for the least effort.
That makes the MVP a market test and the prototype a requirements test.
Phases of the Prototype Model
The work starts with requirements gathering and moves through quick design, a prototype build, user evaluation and refinement before it reaches full-scale development.
- Stakeholders state the requirements they know, and gaps are allowed at this stage.
- The team does a quick design of only the parts users will see, such as screens, flows and key inputs.
- Developers build a working prototype with limited functionality, favoring speed over clean code.
- Users try the prototype and report what is wrong, missing or unclear.
- The team changes the prototype or the requirements, then goes back to evaluation.
- Once users accept the prototype, the real system is designed, built and tested to production quality.
Phases 3 to 5 form a loop. The team repeats build, evaluate and refine until stakeholders accept the prototype, a small case of iterative software development.
When the loop ends, the agreed requirements go into the software requirements specification, and full-scale development starts from that document.
How User Evaluation Runs
Kara Pernice of Nielsen Norman Group (2016) argues that testing a prototype beats testing the finished product, because rewriting code costs far more than discarding a prototype, even a paper one.
Evaluation takes one of two forms, depending on how much of the prototype responds on its own. In a clickable prototype, links and menus respond automatically, though the designer has to script every response before the test. A static prototype works differently. A person plays the computer during the session, through Wizard of Oz, paper prototype or steal-the-mouse methods.
Static prototypes are faster to prepare. They also put pressure on the person acting as the computer, and per the same NN/g article, a wrong screen can distort the user’s expectations for the rest of the session.
Types of Prototyping: Throwaway, Evolutionary, Incremental and Extreme
What separates the types is what happens to the prototype afterwards. Throwaway prototypes get discarded and evolutionary ones grow into the product. Incremental prototypes are built as separate parts and merged, while extreme prototyping is a three-phase method aimed at web applications.
| Type | What happens to the prototype | Best fit | Main limit |
|---|---|---|---|
| Throwaway | Discarded once requirements are agreed | Unclear requirements, new technology | Build effort is spent twice |
| Evolutionary | Refined into the final system | Systems that keep changing | Early shortcuts reach production |
| Incremental | Built as separate parts, then merged | Modular systems | Parts must be integrated at the end |
| Extreme | Built in three phases, interface first | Web applications | Needs agreed service contracts |
Throwaway Prototyping and Brooks’s Advice to Plan to Throw One Away
Throwaway prototyping builds a prototype only to learn from it, then discards it once requirements are agreed. Teams reach for it when requirements are unclear and the technology is new.
Fred Brooks gave the idea its best-known form in The Mythical Man-Month (1975): plan to throw the first system away, because the team will end up doing so anyway.
In 1975 Brooks framed the real choice as planning the discard or promising the pilot system to customers. Building one and throwing it away was a given.
By the 20th anniversary edition in 1995 he called his own advice wrong, because it assumes the sequential waterfall model, which postpones user feedback. He now favored building incrementally.
Brooks wrote about a whole pilot system, not a screen mockup. His correction hits expensive first systems, and it does little to a cheap interface prototype built to settle requirements.
Evolutionary Prototyping
Nothing gets discarded here. Each round of feedback improves the prototype until it becomes the final system.
That suits systems whose requirements keep changing after launch, but it only works if the first build has a clean architecture. When the team skips cleanup, early shortcuts end up in production, and that failure mode is worth weighing before choosing this type.
Incremental Prototyping
Teams build separate prototypes for separate functions, then merge them into one system. Each part gets its own evaluation loop, so feedback arrives per function instead of for the whole product.
Don’t confuse this with incremental development, which releases working slices of the product in sequence. Incremental prototyping combines separately evaluated prototypes into a single system.
Extreme Prototyping
Extreme prototyping is aimed at web applications, and it keeps the interface apart from the services behind it by building in stages.
- Build the interface as plain static pages.
- Wire that same interface to stub services that return fixed data.
- Replace the stubs with working business logic.
The method needs agreed service contracts between front-end and back-end teams. Without them, the stubs drift away from the real services.
Rapid Prototyping: Technique, Not a Separate Model
Rapid prototyping means building a prototype fast, with tools that favor speed over durability. It is a way of working inside throwaway or evolutionary prototyping, not a fifth type.
That matters when reading other guides, since some list it next to the four types as if it were a different process.
Low-Fidelity and High-Fidelity Prototypes, and the Tools That Build Them
Sketches, wireframes and static screens count as low fidelity, and what they test is structure and flow. A prototype that looks and responds like the finished product is high fidelity, which makes it the better choice when detail is the question.
What Fidelity Measures
Nielsen Norman Group (2016) defines fidelity as how closely a prototype matches the look and feel of the final system. It looks at interactivity, meaning whether links and menus respond on their own, and at visuals such as realistic hierarchy, spacing and screen size. The third area is content and navigation, which is either full text and images or stand-ins.
A prototype can sit high in one area and low in another. A clickable wireframe is low on visuals and high on interactivity.
When Low Fidelity Is Enough
Early on, sketching is enough. Rough prototypes are cheap to change, and users judge them more freely.
A wireframe or a paper screen is the usual low-fidelity artifact, and NN/g notes that designers grow less attached to sketchy work than to polished work.
Stakeholders also read a rough prototype as unfinished, so nobody expects it to ship tomorrow.
When High Fidelity Pays Off
According to NN/g, high-fidelity prototypes let teams test workflow and specific components such as mega menus and accordions, along with type legibility and image quality.
Test participants also behave more like they would on live software, because the prototype looks like it.
The downside is the same polish. A finished-looking design tempts executives to approve it for release as is.
My rule of thumb is to raise the fidelity only when a question can’t be answered at the current level.
Which Tools Build Which Fidelity
Tools sort by how much behavior they can fake. The roundup of prototyping tools covers more options than the ones below.
- Balsamiq describes itself as a low-fidelity wireframing tool that pairs paper-style sketching with a digital workflow, and it stays low-fidelity by design.
- Sketch handles screen-level interface design for polished mockups, and Axure RP can import its artboards through a plugin.
- Figma connects frames into flows with hotspots, overlays and Smart Animate. Per its help center (checked October 2026), presentation view shows only frames that have at least one connection.
- Justinmind builds clickable prototypes for web and mobile apps.
- Axure RP supports conditional logic, variables and working forms, and as of October 2026 its site lists version 11.
Pick the tool by the question being asked. Structure questions need only a sketch tool. Flow questions need something clickable, and logic-heavy tools make sense only when the prototype has to behave like the real system.
Advantages and Disadvantages of the Prototype Model
The prototype model buys early user feedback and lower requirements risk. The price is extra build effort and thinner documentation, and users tend to expect too much too soon.
On the plus side, users see a working version early, so wrong assumptions surface before the design is final. Missing functionality shows up during evaluation instead of after release. Customers stay involved through every loop, which builds acceptance of the result, and requirement changes cost little while only a prototype exists.
The downsides are real, though. Each extra iteration adds build and evaluation cost. Documentation trails behind requirements that keep shifting, and users expect the finished system soon after the first demo. That last one is the hardest to manage, I think, because a demo looks finished to anyone who isn’t building it.
What Early Feedback Is Worth
The cost of weak requirements is measurable. PMI’s 2014 requirements management study found that 5.1 percent of every dollar spent on projects and programs is wasted because of poor requirements management.
Catching those errors early is the job of requirements engineering, and the prototype model does it with a working draft instead of a document.
The “cheaper when caught early” part is contested. Boehm’s cost-of-change curve holds that defects cost more the longer they linger, yet Menzies, Nichols, Shull and Layman (Empirical Software Engineering, 2017) studied 171 projects from 2006 to 2014 and found no consistent or substantial delayed issue effect.
The authors suggest the effect appears only in certain kinds of projects. Read together, the two sources point to one conclusion. The prototype model pays off where requirements are the main risk, not on every project.
How Does the Prototype Model Compare With Waterfall, Spiral, Agile and RAD?
The prototype model builds a draft to learn the requirements, and waterfall fixes them before any building starts. Spiral wraps prototyping inside risk analysis. Agile ships working software in short cycles, and RAD bundles prototyping with timeboxes and tooling.
| Model | Process style | When users see working software | Cost and risk driver |
|---|---|---|---|
| Prototype | Build, evaluate, refine, then full build | At the start, as a prototype | Repeat iterations add cost, requirements risk drops |
| Waterfall | Sequential phases | At the end | Late feedback raises requirements risk |
| Spiral | Risk-driven cycles | In each cycle, often as a prototype | Risk analysis sets the scope of each cycle |
| Agile | Short iterations | Every couple of weeks to a couple of months | Change is welcome late, so scope needs active control |
| RAD | Prototyping inside timeboxes | Early, as working models | Relies on user workshops and design tools |
Reliable like-for-like cost figures across these models are scarce, so the table lists cost drivers rather than prices.
Prototype Model vs Waterfall
W. W. Royce’s 1970 WESCON paper, usually cited as the origin of the waterfall model, never used the word and warned that a single sequential pass is risky.
He recommended a pilot version of the system before the delivered one, which is close to what the prototype model formalizes. The textbook contrast between the two is sharper than Royce’s own paper.
In practice, waterfall treats user feedback as a late phase, while the prototype model makes it the first phase.
Prototype Model vs Spiral Model
In the spiral model, prototyping is one risk tool among others. The prototype model makes it the whole process.
Barry Boehm’s spiral model (IEEE Computer, May 1988, pp. 61-72) is a risk-driven approach, and a cycle uses a prototype only when risk analysis says one will reduce uncertainty.
Boehm’s paper applies the model to the TRW Software Productivity System, with early rounds spent on a feasibility study and a concept of operations, then top-level requirements.
Spiral is the better fit for large projects with several unknowns, whereas the prototype model works when a single unknown, the user need, outweighs the rest.
Prototype Model vs Agile
In the prototype model, the prototype exists to produce requirements, and it is often discarded once they are agreed.
Agile works from a different premise. The principles behind the Agile Manifesto call for delivering working software every two weeks to two months, with the shorter end preferred, and they welcome changing requirements even late in development.
The two combine well. A prototype loop fits inside a sprint, and frequent delivery keeps a prototype from drifting into a long, unreleased build.
Prototype Model vs RAD and DSDM
RAD and DSDM both build prototyping into a larger process.
James Martin formalized the rapid application development approach in his 1991 book, as a response to plan-driven waterfall work. RAD pairs prototyping with joint application development sessions and CASE tools.
DSDM came later. It was created in 1994 by the DSDM Consortium (now the Agile Business Consortium), and it lists prototyping beside timeboxing and MoSCoW prioritization as core techniques.
The prototype model is the smaller unit, a way of working that both frameworks absorb.
When Should a Team Use the Prototype Model?
Use it when the biggest project risk is not knowing what users need, and when users can review repeated versions.
Projects That Fit
- Requirements that are unclear or change fast
- Interface-heavy products, such as web and mobile apps, where users judge the screens
- Stakeholders who can’t describe their needs until they see something running
- A client or user group that can sit through repeated review sessions
- New technology, where a throwaway build tests feasibility first
Projects That Do Not Fit
When requirements are fixed and well understood, the prototype loop is pure overhead.
Safety-critical systems need behavior specified and verified up front, so trial and error on the real thing is a poor fit.
Tiny one-off tools fail the cost test too, because the prototype can cost as much as the build.
And if nobody is available to review, the model ends there. Without reviewers, the loop has no input.
A Decision Rule for Choosing It
Prototype the riskiest requirement first, and stop when another round no longer changes the requirements.
Write the stop condition as acceptance criteria before the first build, so the loop ends on evidence instead of fatigue.
Teams already practicing agile development can run the loop inside a sprint instead of ahead of the project.
Take a clinic booking app where the confusing part is rescheduling an appointment. The team prototypes only that flow, tests it with patients and receptionists, and builds the rest after the flow stops changing.
Where the Prototype Model Breaks Down
Trouble usually comes from scope creep in open-ended feedback rounds, a prototype shipped as the product, an expectation gap, or documentation that lags the requirements.
| Failure | Appears when | Control |
|---|---|---|
| Scope creep | No stop condition exists | Fix acceptance criteria before the first build |
| Prototype shipped as product | Deadline pressure meets a working demo | Decide throwaway or evolutionary up front |
| Expectation gap | Users see a working demo and assume it is nearly done | Label it unfinished, show only the flows under test |
| Documentation gaps | Requirements change every loop | Log each change, rewrite the specification at acceptance |
Scope Creep
PMI’s Pulse of the Profession found that 52% of projects completed in the prior 12 months had scope creep or uncontrolled changes in 2018, up from 43% five years earlier.
The prototype loop invites that pattern, because every evaluation round produces new requests and each one looks small.
Cap the rounds or the time before the first build, and send new requests through formal change request management. Without both, evaluation rounds continue until the budget runs out.
A Prototype Shipped as the Product
It happens when a working demo meets a deadline and the team promotes the prototype instead of rebuilding it.
The bill arrives as technical debt, because code written for speed now carries production traffic and every later feature.
The fix is to declare the prototype’s fate, throwaway or evolutionary, in the project plan. For throwaway work, building in a stack the team will not ship takes promotion off the table.
Expectation and Documentation Gaps
Users who see a working screen assume the rest is nearly done. Tell them in writing what the prototype lacks, like error handling and security, and performance too.
Documentation has its own problem. Every loop changes the requirements, so the written specification falls behind. Log each change during the loop and rewrite the specification once, at acceptance.
Both are cheap to prevent.
Prototype Model FAQ
How many iterations does the prototype model need?
No standard number exists. The count depends on how unclear the requirements are, so most teams budget a time limit per round instead of a fixed number of rounds.
Who invented the prototype model?
No single person is credited. Boehm’s 1988 survey of process models notes that Royce’s 1970 paper already built prototyping into the life cycle through a “build it twice” step, and it cites McCracken and Jackson (1982) for the evolutionary development model.
Royce’s pilot-system idea is the earliest of these.
Does testing still happen after the prototype is accepted?
Yes. Evaluating a prototype checks the requirements, not the production code, so the final system still needs full testing, deployment and maintenance like any other life cycle model.
Is a prototype the same as a mockup?
No. A mockup shows how the interface looks, while a prototype also responds to user actions.
A mockup is high on visuals and low on interactivity, so it often serves as the first step toward a high-fidelity prototype.
Building the Smallest Useful Prototype First
The prototype model starts with the smallest prototype that can test the riskiest requirement, usually one clickable flow, and grows only after that test returns an answer. The order matters because reviewer availability is the scarcest input.
- Book the reviewers before the build.
- Rewrite the riskiest requirement as a question a user can answer.
- Sketch the flow, then build only what the question needs.
Starting this narrow has a cost, since other requirements stay untested and later rounds will surface surprises the first test could not.
For the sketching step, a shortlist of app wireframing tools is the natural next read.
This advice changes if your release cycle is short enough to put real software in front of users inside one sprint, because then a separate prototype is unnecessary. Position verified October 2026.
- Notepad++ Android Options: Apps That Come Close - October 21, 2026
- Data Management Services: A Practical Guide for Growing Companies - October 21, 2026
- MongoDB Cheat Sheet - October 20, 2026
