By davelock·Published 12 April 2026·5 min read

5 Questions to Ask Before You Build a Prototype

Prototyping Without a Plan is Expensive Learning

Most founders jump straight from “I have an idea” to “let’s build a prototype.” It feels productive. You’re making something tangible. But without a clear reason for the prototype, you’ll spend weeks building the wrong thing, testing the wrong assumptions, and burning cash on iteration that doesn’t move the needle.

A prototype should answer specific questions about your product. If you don’t know what questions you’re asking, you don’t know when you’re done–and you’ll keep iterating.

Before you spend time and money building, ask yourself these five questions. They’ll save you weeks and thousands of dollars.

1. Does This Actually Solve a Real Problem?

This is the foundation. If your product solves a problem nobody has, or solves it for a market so small it doesn’t matter, you’re done. No prototype changes that.

Reality check: Have you talked to 10–20 potential users and confirmed they experience this problem regularly enough to spend money on a solution? Or are you building something you think is cool?

A prototype doesn’t validate the problem; it validates the solution to a problem you’ve already confirmed exists. If you haven’t done the problem validation yet, do that first. Talk to users. Watch them work. Understand what they’re currently doing and why your idea is better.

This phase costs nothing but time. A prototype built without it is premature.

2. What Are You Actually Testing?

This is where most prototyping goes wrong. Founders build a prototype that’s “pretty close” to the final product, then hope it reveals the answer to everything: Does it work? Will people buy it? Can we manufacture it? Can we do it profitably?

That’s five different questions bundled into one expensive prototype.

Be specific. Ask yourself: What is the core assumption I’m trying to validate? And design the prototype to test only that.

Examples:

Concept validation: Does the core mechanism work as theory suggests? (Test: build a rough mechanical model; doesn’t need to be pretty or durable)
Usability validation: Can people understand and use this without training? (Test: build a realistic mockup; doesn’t need to work perfectly internally)
Manufacturing validation: Can this be made at the cost and volume we need? (Test: get manufacturer quotes on your design; don’t build a prototype–ask the factory)
Material validation: Does this material perform as needed in the use case? (Test: small material samples under realistic load/environment; not a full prototype)
Integration validation: Do all the components work together correctly? (Test: benchtop assembly; doesn’t need to fit in final housing)

Each of these requires a different prototype. Trying to answer all five at once means you’re either overbuilding the prototype or underbuilding it.

Name what you’re testing. Design the cheapest prototype that answers that specific question.

3. What’s the Cheapest Way to Test This Assumption?

Assuming you know what you need to test, there are usually three ways to do it:

Simulation or CAD analysis: Before you build anything, run FEA, thermal analysis, or dynamic simulation. Costs a few hundred dollars. Rules out bad ideas fast.
Benchtop or mockup prototype: 3D print, laser cut, or hand-assemble the core concept. Rough, not production-like, but answers the core question. Costs $1,000–$10,000.
Production-intent prototype: Built in the actual manufacturing process with production materials and tolerances. Answers everything but is expensive and slow. Costs $50,000–$500,000+.

The rule: Use the cheapest method that actually answers your question. If simulation answers it, don’t build a prototype. If a 3D print answers it, don’t tooling. If a benchtop test answers it, don’t do a full production run.

Most founders skip straight to production-intent because it “feels right” or because they want to be thorough. That’s how you burn $100k validating something you could have learned for $5k.

4. What Does Success Look Like?

Before you build, define success. Not “the prototype works”–that’s too vague. Define measurable criteria.

For a mechanical prototype: “The joint holds under 50kg load with less than 2mm deflection at the tip” or “The locking mechanism engages in under 0.5 seconds with one hand.”
For a usability prototype: “Five out of five test users can assemble this without instructions” or “The control interface is intuitive enough that 80% of users find the setting within 20 seconds.”
For a manufacturing validation: “The unit cost at 5,000 units is under $35” or “Lead time is less than 12 weeks.”

Write these criteria down before you start building. When you’re done, you’ll know immediately whether you succeeded or whether you need to iterate. This also stops the “let’s just tweak it a bit more” spiral that burns time and money.

5. What Happens After the Prototype?

Prototyping is not the end. It’s a waypoint. Know where you’re going next.

If the prototype succeeds: What’s the next milestone? Beta testing with customers? A second-round prototype to optimize cost? A manufacturing quote? Validation with investors? Define it before you start building this one.

If the prototype fails: Is it a failure of the concept, or a failure of your execution? Do you iterate on the design, or do you drop the idea and move on? Having this conversation before you’re emotionally attached to the build saves months of pursuing dead-end designs.

If the prototype is inconclusive: What additional information do you need? A second test? A different variant? Another round of user feedback? Be honest with yourself about what “success” requires. Don’t iterate indefinitely because you’re not sure.

Plan the validation path before you prototype. “Build something and see what happens” is not a plan.

The Prototype Decision Framework

Here’s how to run this in practice:

List the core assumptions you need to validate for the product to be worth building.
For each assumption, define one testable question.
For each question, identify the cheapest prototype/test that answers it.
Define success criteria for that test.
Define what you do next if you pass or fail.
Build only what’s on the list.

Most founders skip steps 1–5 and jump to step 6. That’s why they iterate forever.

Next Steps

If you’re about to prototype, apply this framework first. Spend a day answering these five questions. It’ll clarify the next 8–12 weeks of work and save you from building the wrong thing.

The Innovate Engineer Viability Sprint walks you through this validation planning systematically, including how to define success criteria, choose your prototype approach, and set up your testing roadmap. Start your free sprint today.