Skip to content
Back to Idea Validation

Pretotyping

Build a fake front-end to test if people would use the real thing — before building the real thing.

Why

Pretotyping (coined at Google) answers "will they use it?" before you can answer "can we build it?". You build the thinnest possible illusion of the product — a UI that looks real but is hardcoded or manual behind the scenes — and watch whether people try to use it. This separates desirability from feasibility: many things are buildable that nobody wants, and pretotyping catches that gap for a fraction of the engineering cost. A week of pretotyping can save three months of MVP engineering on an idea that has no pull.

When

After a smoke test passes, before building a functional MVP. Takes 3-7 days. Skip if the core risk is technical feasibility rather than demand.

How

1. Identify the core interaction to fake
   - What is the one action the user must take for the idea to work?
   - Example: for an AI logo generator, the core action is "upload brief → see logo"

2. Build the illusion
   - Front-end: real UI in Figma-to-code or a no-code tool (Bubble, Glide)
   - Back-end: hardcoded responses or you manually fulfilling requests
   - It must look and feel real to the user

3. Put it in front of 10-20 target users
   - Share via your smoke-test responders or a small ad spend
   - Watch them use it (session recording or live calls)

4. Measure intent, not satisfaction
   - Did they complete the core action?
   - Did they try to do it again or share it?
   - Did they ask "when is this ready?" or try to pay?

5. Decide
   - Strong usage intent → build the real thing
   - Looks nice but no pull → kill, the problem is desirability not polish

Example

Idea: "AI tool that turns a Figma file into a working React component."
Pretotype (4 days):
  - Built a slick landing page + "upload Figma" button
  - Behind the scenes: I manually converted the first 5 uploads by hand
  - Sent results back within 2 hours each

Results (15 users tried it):
  - 11 completed the upload, 7 said "this is exactly what I need"
  - 3 asked for pricing, 1 tried to pre-pay
  - 2 said the 2-hour wait was too long → real product must be instant

Decision: strong desirability, real product must be fast → build with instant AI.

Common Problems

  • ⚠Making the pretotype too functional — if you spend 2 weeks building real logic, it is an MVP, not a pretotype, and you have defeated the purpose.
  • ⚠Not watching users interact with it — survey responses after the fact are unreliable; you need to see where they hesitate or drop off.
  • ⚠Interpreting "cool idea" reactions as validation — people are polite about slick UIs; measure actions (did they try again, did they try to pay).
  • ⚠Faking the wrong part — if users care about accuracy (e.g. AI output quality), a hardcoded good response over-promises and you learn nothing.

Best Practices

  • ✓Time-box the pretotype to 1 week — if it takes longer, you are building too much; cut the surface area.
  • ✓Use session recording (LogRocket, FullStory) to see real behavior, not self-reported behavior.
  • ✓Be honest in your post-test interview that it was a prototype — this tests true intent rather than politeness about a "finished" product.
  • ✓Pre-write the "kill" criteria: "if < 30% complete the core action, the idea has no pull" — decide before emotions get involved.