The Gated Sequence That Turns an Idea Into a Design
The prototype development process is a gated sequence that turns an idea into a validated, production-ready design: requirements, concept and design, first prototype, test and iterate, freeze, and handoff. Each step produces a deliverable, and the program advances only when it exists. The process starts with requirements, not the design: what the product must do, in what environment, at what cost, and under what constraints. The requirements list, function, performance, environment, and schedule, is the reference for every later decision, and it prevents the design from drifting toward what is easy instead of what is needed. The requirements should include the validation criteria, because a requirement without a test is a hope, and the test plan belongs with the requirement.
Concept, Design, and the First Prototype
The concept step explores the approaches and selects the direction; the design step turns the concept into geometry, the CAD model, the material selection, and the critical features. The design should be reviewed for manufacturability before the first prototype is ordered, because the DFM review is cheapest when the geometry is still moving. The deliverable is a design that can be prototyped: a model with the critical features marked, the materials named, and the tolerances assigned. A design that cannot be manufactured cannot be validated, so the DFM review is part of the design step, not a surprise at quoting.
The first prototype is built to answer the first question, and the process, printed, machined, cast, or fabricated, is chosen by the question and the stage. A geometry question needs a printed part; a performance question needs a machined part in production material. The first build produces the first data and the first surprises: the features that were wrong in CAD, the tolerances that were optimistic, and the assembly steps that do not work, and the findings become the input to the next iteration. The rapid prototyping service and the CNC machining service are the common routes, and the prototype type guide defines which to choose first.
Test, Iterate, and Record
The test step checks the prototype against the requirements, and the iterate step fixes what failed. The loop, build, test, fix, repeat, is where the design matures, and the number of iterations follows the risk and the stage: cheap iterations early, expensive builds late. The iteration should be recorded: each version, the change, the test result, and the decision become the design history, and the history transfers to production. A program that iterates without records rediscovers the changes at first article, and the schedule pays for it.
| Step | Deliverable |
|---|---|
| Requirements | Requirements and test plan |
| Concept and design | CAD, materials, critical features |
| First prototype | A part that answers the first question |
| Test and iterate | Data, findings, design history |
| Freeze | Locked design, complete drawing |
| Handoff | Validation data, production spec |
Freezing the Design
Freezing the design is a decision, not a milestone label. The design is frozen when the remaining uncertainty no longer justifies changing it: the fit is validated, the performance data supports the requirement, and the cost of a change now exceeds the value it would add. The freeze locks the revision, the drawing, the tolerances, and the materials, and it should be recorded in the design history with the reason. Freezing too early locks in a flawed design; freezing too late spends the schedule testing a moving target. The release criteria, what evidence is required to freeze, should be written in the requirements step, so the freeze is an audit, not a debate.
Handoff to Production
The handoff transfers the design and its evidence to production. It should include the validated CAD, the complete drawing with the datum and tolerance strategy, the material specification, the inspection plan, and the design history that explains why the requirements are met. The production supplier uses this package to build the process, and the first article verifies that the process reproduces the validated design. The inspection framework and the tolerance guidance describe the drawing and inspection language the handoff needs, and the low-volume manufacturing service receives the validated design for the first production runs.
Budgeting the Prototype Process
The budget should be written as a sequence, not a single build. Each step, requirements, concept, first prototype, iterations, freeze, and handoff, has a cost, and the iterations carry the variation: cheap early rounds with printed parts, expensive late rounds with production-intent processes. The budget should name the expected number of iterations and the gate that ends each round, and hold a contingency for the failed round that must repeat. Material and finish costs change by stage, so the plan should state the expected grade and finish at each step, and the per-part price should be read as fixed cost plus variable cost, which explains why the first article is expensive and later parts are cheaper. The rapid prototyping and low-volume quotes show this structure directly.
Common Mistakes and the Tools That Prevent Them
The common mistakes are skipping the requirements step, iterating without records, freezing on a schedule rather than on evidence, and treating a prototype as a production part. Each is a stage mismatch, and each has a tool: a written requirements and test plan, a design history, release criteria, and a process that matches the stage. Standards such as NIST measurement practice frame how the validation data is generated and reported, and the process guides on this site, for prototype testing methods and the prototype type definitions, keep the sequence on track.
Planning for Design Changes and Their Cost
Design change is the normal state of a prototype program, and the plan should absorb it rather than fight it. The cost of a change is lowest when it happens in CAD, higher when it requires a new build, and highest when it is discovered after tooling. That cost curve is why the DFM review happens early, why the first prototypes are cheap, and why the freeze step exists at all: it marks the point where the cost of change exceeds its value. The plan should name the expected change points, the revision control that keeps the team aligned, and the evidence each revision must produce before the next build is ordered.
Revision control is part of the handoff. Each version of the design, with its change log and test data, is the history that production will use to understand the part, and a missing record becomes a mystery at first article. Tools and process guides, such as the rapid prototyping service, the prototype quantities guide, and the prototype budgeting reference, keep the change and cost structure visible, so the program spends on evidence and keeps a complete record of how the design matured.
Scaling from the Validated Prototype
Once the design is frozen and the handoff package is complete, the next step is scaling the process, not the design. The first article at the production supplier verifies that the process reproduces the validated part; the pilot run confirms the variation stays inside the tolerance; and the low-volume runs prove the economics before a full launch. The prototype that validated fit and function becomes the production reference, and the same material, fixture, and inspection standard continue into the run. Keeping the prototyping and production under one review loop, as the low-volume manufacturing service does, protects the continuity that makes the handoff safe.
Tools That Support the Process
Few of these steps require special software; the tools are the requirements document, the DFM review, the design history, the inspection record, and the release checklist. A simple requirements and test plan written before the first build keeps every later decision anchored; the DFM review, done on the actual geometry, converts most manufacturing risk into a fixed design; the design history makes the iteration transparent; and the first-article record at handoff confirms the production process reproduces the validated part. Teams that keep these five tools current finish a prototype program with the evidence production needs, instead of rediscovering the design at first article.
The practical discipline is to treat each step’s deliverable as a gate. If the requirements are not written, the concept review is guesswork; if the DFM review has not happened, the first prototype is a surprise; if the test data is not recorded, the iteration teaches nothing. The gate discipline is what the rapid prototyping workflow and the DFM checklist enforce, and it is the difference between a prototype program and a series of expensive experiments.
FAQs
What is the first step of prototyping?
Defining the requirements and the test plan. The requirements are the contract for every later decision, and the validation criteria say how the prototype will prove the design.
How many iterations does a prototype need?
As many as the risk and the stage require, with cheap iterations early and expensive builds late. The number is not fixed; it follows the evidence each round produces against the requirements.
When should the design be frozen?
When the remaining uncertainty no longer justifies a change: fit and performance are validated, and the cost of a change now exceeds the value it adds. The release criteria should be written in the requirements step.