The prototype-first approach to product development

Prototyping has become one of the most talked-about shifts in how AI-native product teams work. Product teams at leading AI companies are replacing traditional internal workflows with a prototype-first development — leveraging coding agents and vibe coding tools to build simple mocks that convey product ideas better than PRDs or meetings.

This guide covers what prototype-first development actually involves, where it works, where it breaks down, and how to run it without creating problems downstream.

---

What is prototype-first development?

Prototype-first development is a product methodology where the team aligns around a working version of a feature rather than a written specification. Instead of describing how a new feature should behave, the PM or designer builds a rough version of it; the team then reacts to that and forms a shared understanding. The fundamental goal of the prototype is to speed up decision making and stakeholder alignment.

In traditional product development, the sequence runs: requirements, design, engineering, review. In prototype-first development, it compresses: rough build, team review, rebuild or ship.

The methodology isn't new, but it's gotten a lot of attention recently. Anthropic, in describing how their team builds features internally, noted that engineers routinely skip the doc and build a quick prototype in Claude Code instead — distributing it internally for feedback, buy-in, and alignment before anything goes to production. Reforge has written about similar patterns emerging across product teams. When a working prototype can be produced in a prompt and a few minutes, the economics of "write a spec or just build it" shift pretty dramatically.

---

What it looks like in practice

1. The PM or designer opens a vibe coding tool and builds something. Tools like Lovable, v0, Replit, and similar have made this genuinely fast. A basic prototype can take one prompt and a few minutes. Some teams put more time into it — simulating actual user data, aligning with a specific design system, or building out a few different flows — but the baseline cost is low.

2. The team reviews the prototype together. Engineers, designers, and other stakeholders react to something real rather than a written description. Disagreements that would have surfaced mid-build show up in the review instead — where they can be explicitly resolved and documented, rather than silently decided during implementation. Those decisions become a record of what the feature is and why it works the way it does.

3. A decision gets made about what to do next. For small, genuinely self-contained features — think a UI change with no new API surface or data model impact — the prototype may be cleaned up and shipped directly after an engineer reviews the code. For more complex ones, engineers rebuild from scratch using the prototype as a working demonstration of intended behavior.

4. The prototype is either shipped or discarded.

---

What's critical to get right

Two things determine whether prototype-first works.

The first is whether the feature has enough of a visual component that a prototype can actually drive alignment. Prototype-first is well-suited to UI-heavy features where a working demo communicates something that a written spec wouldn't. It's less natural for backend logic, data model changes, or anything where the important behavior is invisible to a user clicking around — though the underlying principle translates: a rough API mock, a working query, or a data pipeline stub can play the same alignment role that a UI prototype plays for frontend work.

The second is the engineering review step. The prototype is a communication tool, not production code. There has to be a moment where an engineer looks at what was built and makes a deliberate decision: is this shippable as-is, or does it need to be properly rebuilt? Defining clearly what's acceptable to ship with adjustments vs rebuild is an important piece to keeping code in a maintainable state. For small enough features, the prototype may genuinely be fine to ship. But if that review doesn't happen explicitly, prototype code has a habit of quietly going into production without anyone deciding it should.

---

Pros and cons

Summary of key advantages and risks of prototype-first development.

Pros

1. Facilitates alignment. The alignment benefit is immediate and real. A working prototype shows what a feature does rather than describing it. Teams spend less time debating interpretation and more time reacting to actual behavior. Prototyping also catches misalignment earlier. When engineers receive a written spec, every ambiguity in it becomes an implicit decision made during implementation. A prototype removes most of that — the behavior is demonstrated, not described.

2. Customer demos. Beyond internal alignment, prototypes are often good enough that they can be shown to early customers. Demo'ing a prototype can help identify common sales objections early on and embed more customer feedback into the product design process.

3. Limits sunk costs fallacy. When exploring an idea costs a few hours rather than weeks of speccing and planning, teams try more things before committing. That produces better decisions about what's worth building properly.

4. Sharpens PMs' understanding. Over time, PMs who prototype regularly develop sharper intuition about what's technically feasible, what actually feels right in use, and where their assumptions were wrong.

Cons

1. Prototype code ships without review. The most common problem is prototype code that ships without proper review. A prototype gets built, someone says it looks good, and it goes in — without an engineer reviewing the code itself. Prototype code handles the happy path. It skips error handling, ignores edge cases, and makes architectural decisions by accident rather than by design. When that code ships, those decisions become part of the codebase.

2. Edge cases go undocumented. Even when the prototype is rebuilt properly, edge cases that weren't documented alongside it often get missed. The prototype demonstrates the happy path convincingly enough that teams move forward without capturing what should happen when things go wrong — and that gap doesn't get filled unless someone explicitly makes it a step. A useful discipline: treat the edge cases identified during the review session as a required output, not an optional one. Even when teams know prototypes shouldn't ship directly, the pressure to move fast creates shortcuts. A codebase with accumulated unreviewed prototype code gets fragile and expensive to change.

3. PMs get attached. The methodology also breaks down when PMs become attached to their prototype code and treat it as something that should ship rather than something that should inform. That's a culture problem more than a process problem, but it's a common one.

4. Scope creeps in. A prototype can accidentally define scope that was never agreed upon. If the prototype does more than planned, the team may feel compelled to ship it as-is rather than strip it back.

---

When to use prototype-first

Good fit:

• UI-driven features with a meaningful visual component
• Early exploration before a feature is well-defined
• Features requiring alignment of several stakeholders
• Small, isolated changes where the prototype is genuinely close to production-ready

Poor fit:

• Changes to the data model or schema
• Authentication, permissions, or billing flows
• Third-party integrations
• Anything where error handling matters as much as the happy path
• Teams where engineers won't review prototype code before it ships

---

How to run it well

First, determine if the feature you're working on is suitable for prototyping. If it is, spend some time defining the exact scope of that feature — vibe coding tools have a tendency to rebuild your whole product, even if not required.

Before any prototyping starts, agree on which feature types can ship from a prototype with engineer review, and which will need a full rebuild. That classification should happen at the start, not after the prototype is done and the team is deciding whether to keep it.

Use vibe coding tools like Lovable, v0, or Replit to spin up quick prototypes. Typically, showcasing the key user flows accurately is more important than getting a pixel-perfect mockup. Use your prototype to validate your product idea in internal meetings and external demos.

Make engineering review a required step. The engineer looks at the code, not just the output, and makes a deliberate call: shippable as-is, or needs a rebuild. That decision gets documented.

---