Prototype First: Test Your Idea in 30 Minutes Before You Spend Six Months Building It

Every developer knows the expensive question: is this idea worth six months of my life?

For most of us, the honest answer used to be "I don't know until I build it" — and building it was the six months. That equation is changing. AI coding agents can now turn a rough idea into a clickable, working prototype in well under an hour. The prototype won't be the product. But it can answer the question that matters most: should I build this at all?

That shift — from "build to find out" to "prototype to decide" — is quietly becoming the most valuable skill in AI-assisted development. Here's how to use it well.

The prototype is a question, not a product

A prototype has one job: to make the idea concrete enough to judge. It needs to answer three questions:

1. Does the core interaction feel right? Can a user do the one thing the app exists for, end to end?
2. Is the hard part actually hard? Every idea has one risky piece — a tricky integration, a workflow nobody has nailed, a performance constraint. The prototype should touch that piece first.
3. Would anyone care? Show it to five real people. Watch where they hesitate. Their confusion is data.

Notice what is not on that list: clean code, a design system, authentication, billing, tests, deployment pipelines. A prototype that has all of those is not a prototype — it's a product with a deadline you didn't need.

The 30-minute loop

Here is the loop I use when an idea is worth testing but not yet worth committing to:

1. Write the one-paragraph brief first

Before touching any agent, write a short brief in plain language:

• Who is it for?
• What is the single thing they do with it?
• What does "working" look like in a demo?

Keep it under 150 words. If you can't describe the idea in a paragraph, the agent can't build it either — and that confusion is itself useful information.

2. Give the agent a throwaway job

Tell the agent explicitly that this is disposable: use the simplest stack, hardcode the data, skip auth, skip tests. A typical prompt looks like this:

Build a throwaway prototype, not production code.
Stack: a single-page app, no auth, no database — hardcode sample data.
Goal: let a user paste a URL and see a summary card in under 2 seconds.
Stop when the core flow works in the browser. Do not add features.

The words "throwaway" and "stop when" matter. Without them, agents keep polishing — adding settings pages, refactoring, gold-plating — and your 30-minute test becomes a 3-hour project.

3. Run agents in parallel, not in sequence

One of the biggest practical wins is running several agents at once, each on a different angle of the same idea: one builds the main flow, one tries a different UI approach, one attacks the risky integration. You compare the results and keep the best.

A simple way to organise it:

Terminal 1: agent A — build the core flow (input → output)
Terminal 2: agent B — build an alternative UI for the same flow
Terminal 3: agent C — spike the risky part (the API call, the parser, the export)

Three prototypes in 30 minutes tell you far more than one polished prototype in three hours, because the comparison itself is information: which approach felt natural, which one broke, which one a user understood without explanation.

4. Demo it to a human within the hour

A prototype sitting on your laptop has answered nothing. Show it to someone — a friend, a colleague, a user from the target audience — and watch them use it without guidance. The moments they pause, misclick, or ask "what does this do?" are the findings. Write them down verbatim; your memory will smooth them over by tomorrow.

5. Decide, then delete or commit

After the demo, make a binary call:

• Kill it. The idea doesn't survive contact with a user. You spent 30 minutes, not six months. That's a win.
• Commit to it. The core works and someone wants it. Now — and only now — throw the prototype away and start the real build with a proper plan, because prototype code is optimised for speed, not survival.

The most common failure mode is the middle path: keeping the prototype and slowly turning it into the product. Prototype code is full of shortcuts that become permanent bugs. If the idea is worth building, it is worth rebuilding properly.

What a prototype cannot tell you

Being honest about the limits is what makes this workflow trustworthy rather than hype:

• It can't validate the boring 80%. Auth, payments, error handling, scale, maintenance — the prototype skips all of it, and that is where most products actually live or die.
• It can't tell you if the code is good. Agents write plausible-looking code fast, and plausible is not the same as correct. The prototype proves the idea can work, not that the code is safe. Review anything you keep.
• It can't replace your judgement. If the prototype is impressive but you don't understand how it works, you don't own it — you're renting it. The demo that matters most is the one where you can explain every part of what you just built.

That last point is also the answer to the most common criticism of this style of working: that it produces developers who can't code. The skill hasn't disappeared; it has moved. It used to be writing every line. Now it's knowing what to ask for, recognising when the output is wrong, and understanding the system well enough to fix it. Developers who build on top of their own experience — their own libraries, their own hard-won knowledge of the domain — get far more out of agents than developers who start from zero, because they know what "good" looks like.

The habit that compounds

Prototype-first is not a tool choice. It's a habit: every idea gets a cheap test before it gets an expensive commitment. After a few months of it, you build a second skill on top — a sense for which ideas die in the prototype stage and which ones survive. That instinct is worth more than any single tool, because it protects the one resource you can't get back: the six months you would have spent on the wrong thing.

So the next time an idea excites you, resist the urge to start building it properly. Build it badly, quickly, in parallel — and let the prototype tell you whether it deserves the real thing.

— Written by Davis George · zhuan.xyz