Prototype First. Code Second.

When I built my first app, I was convinced I had the next big thing. I'd identified a real problem. I'd designed a thoughtful solution. I'd shipped a clean V1 with what I thought were the essential features.

Nobody used it. Like, almost nobody. Flat-earth wrong about the demand.

That failure cost me a year. It also taught me the lesson I've watched repeat across more than thirty-five client projects since: the most expensive mistake in tech isn't building the wrong way. It's building the wrong thing — and building it well.

Why we skip the prototype

Engineers want to build. Founders want to ship. Both feel like progress when characters are landing in a file. A prototype, by comparison, feels like procrastination dressed up as process.

It isn't. A prototype is a forcing function. It makes you decide what the product is before deciding how it works. Those are two completely different problems, and conflating them is how you end up six months in with a beautifully architected product that nobody wants.

What "prototype" actually means

It is not a Figma file the team admires and then ignores. A prototype is something that puts your assumption in front of a real human and lets them tell you whether you're right.

That can be:

• A waitlist landing page. This one alone has saved me and my clients more wasted months than anything else. Build a single page that describes the product as if it exists. Add a form. Share it. If you can't get a hundred people who match your target customer to give you their email, you don't have a problem worth building for. I've used this on roughly 80% of the products I've validated. It works.
• A clickable Figma flow handed to five potential users with a single instruction: try to do the thing the product is for.
• A Notion doc walking through the workflow end to end, sent to ten people who'd be the buyer.
• A no-code MVP held together with Airtable, Zapier, and patience.

If it answers "would someone actually pay for this?" before any production code is written, it counts.

The five-step version I now use

After enough projects, I've reduced this to a sequence I run on every new idea — mine or a client's:

1. Identify a painful problem people will pay to solve. Not a mild inconvenience. A real one.
2. Deeply understand the target customer. Specific person. Specific context. Specific budget.
3. Brainstorm two or three simple features you think could solve the problem. Not twenty. Three.
4. Build an imperfect MVP — fast. A week, not a quarter.
5. Talk to users. Validate. Adjust. Then loop.

Steps one through three are the prototype. Steps four and five are where engineering enters. If you skip the first three, you're building on faith.

The 40% number

Tracked across the last batch of Lambdaa projects, prototyping first cut wasted engineering effort by roughly 40%. That number isn't precise — it's a rough average across very different codebases — but the direction is consistent.

The savings come from three places:

1. Killing dead features early. Roughly one in three "must-have" features dies in user testing. Cheaper to kill them in Figma than to remove them from a production database after launch.
2. Tightening scope. Watching a real user fumble through a prototype reveals what's essential and what's vanity. The list of "must-have" features always shrinks.
3. De-risking architecture. When you know the actual usage shape, you stop building for imagined load.

The hard part

Prototyping isn't the work. The hard part is convincing yourself that an afternoon of clicking through mockups with three users is more valuable than an afternoon of writing code.

It is. Almost always.

I lost a year learning this. The 35 founders I've worked with since have lost considerably less. The ones who took it seriously from day one shipped products people actually use. The ones who didn't shipped beautifully engineered software into a silence that didn't care how clean the code was.

Build the prototype first. Save yourself the year.