Product & Design

Prototype Before You Commit Engineering

A week of prototyping routinely saves a quarter of building. What to prototype, at what fidelity, and how to test it so the answer is trustworthy.

Purushottam Kumar Suman
Purushottam Kumar Suman
Founder & CEO, Drema AI
7 min read
Man planning UX design concepts at a whiteboard in an office

The most expensive way to discover an idea does not work is to build it. Prototyping exists to move that discovery earlier, and the discipline is knowing what question you are asking before choosing the fidelity.

01

Match fidelity to the question

Testing whether people understand a concept needs a sketch. Testing whether they can complete a flow needs clickable screens. Testing whether they will pay needs a real price and a real button. Building a polished prototype to answer a question a sketch would settle wastes the time the prototype was meant to save.

Fidelity should be set by the question, not by how impressive you want the artefact to be.

02

Prototype the risky part only

Every project has one or two genuinely uncertain elements and a lot of routine work. Prototype the uncertainty — the novel interaction, the unfamiliar workflow, the pricing model — and skip the login screen. Complete prototypes take as long as building and answer no more.

Concept unclearSketches are enough
Flow unclearClickable screens with real content
Demand unclearLanding page with a real signup
Feasibility unclearA technical spike, not a design
03

Use realistic content

Lorem ipsum and perfectly short names hide every layout problem you have. Real names of real length, real error cases and realistic data volumes reveal the issues that would otherwise be found in the build, when changing them is expensive.

04

Give a task, then stay quiet

Demonstrating the prototype tells you nothing. Hand someone a goal — 'add a teammate and assign them this task' — then watch without helping. The silence is uncomfortable and it is where the findings come from. Five participants surface the substantial problems.

05

Technical spikes are prototypes too

When the risk is feasibility rather than desirability, the right prototype is throwaway code answering one question: can this API deliver the data we need at the latency we require. Timebox it to days, write it to be discarded, and record the answer.

06

Throw it away

The pressure to evolve a successful prototype into the product is strong and almost always wrong — prototypes are built without error handling, tests or structure precisely so they can be fast. Keep the learning, discard the code, and build properly with what you now know.

1 week
Often saves a quarter of building
5 users
Enough to find the major problems
Discard
The code, keep the learning
Purushottam Kumar Suman
Written by
Purushottam Kumar Suman
Founder & CEO, Drema AI

Founder and CEO of Drema AI. Builds AI systems, SaaS platforms and industry software — and writes about what actually survives production.

CTA Background

Got a problem like this one?

Bring it to a call with a founder.You will get a straight answer, including when the answer is no.

View Our Work
AI-First Engineering
Secure & Scalable
Built to Deliver Impact