Prototype-first design

The deck is beautiful. Twelve screens, a consistent component library, hover states on the primary button. You've walked it past your co-founder, your lead engineer, and two investors. Everyone nodded. Nobody knows what happens when a billing admin tries to downgrade mid-cycle. Or what the dashboard looks like when the table has zero rows. Or whether that modal still makes sense when a second role opens it. Those decisions are still imaginary. The prototype is static, so imagination is all anyone has.

That is where a lot of B2B SaaS design work stalls. Static mockups are good at a lot of things. Moving product decisions forward is not one of them. Teams searching prototype first design and interactive prototype discovery are usually looking for a way out of that stall, not another essay about whether Figma is dead.

Why static mockups stall product decisions

Static mockups put an imagination tax on everyone in the room.

When you walk a stakeholder through a Figma clickthrough, you are asking them to fill gaps. What happens if a user holds two roles at once? What does billing show for an expired card versus a card in a grace period versus one that needs re-authentication? The designer knows what they intended. The stakeholder is guessing. Engineering is about to build something none of them fully agreed on.

This is survivable on a simple happy path. B2B SaaS is rarely that. Roles, permissions, billing states, empty states, and multi-tenant edge cases are not decoration around the product. They are the product. A frame that only shows the clean path is half a spec dressed as a finished design.

Scripted Figma rehearsals make it worse. You control the clicks, so every demo looks clean. The moment someone goes off-script, you hear yourself say "imagine that this goes to…" which is the problem you were trying to solve by making a prototype. Chris Nicol calls this a scripted rehearsal: predetermined path, fake-enough data, decisions made on a performance.

Static mockups ask you to imagine how a product will feel. Working prototypes remove that leap of faith. You click through real interactions and find out what you are actually building while it is still cheap to change your mind.

What prototype-first means (and what it doesn't)

Prototype-first is not "skip design." It is a reordering of where decisions happen.

In the usual flow, thinking happens in Figma. Wireframes become mockups. Mockups get approved. Then someone builds it and discovers everything the mockup did not resolve. In a prototype-first flow, those decisions move earlier, into working prototypes that can simulate the behavior, state, and logic being debated. Interactive mini-apps you can put in front of your team and users, not frames you have to explain.

Figma still wins for early sketching when direction is not settled, for journey maps that need to cover a lot of ground quickly, and for visual and design-system polish. Those are the right jobs for static tools. We still use Figma. Standard even includes 24/7 access to Figma designs. The claim is not RIP Figma. The claim is that product decisions should not wait on a picture people have to imagine their way through.

When the question is "how does this feature actually work," the answer cannot live in a frame. It has to live in something you can stand inside: real data shapes, real branching, real empty and error states, real timing. That is interactive prototype discovery. You iterate on the idea itself, not just the pixels.

You are not replacing design with code. You are moving the moment of truth earlier so the things you would normally discover in production are already resolved.

Prototype-first vs Figma vs AI prototyping tools

The SERP around this phrase is mostly essays and tools. Essays ask whether Figma prototypes are dead. Tools sell discovery-to-prototype as a product. Neither is the job Clearly does. We are an embedded design partner for SaaS, not an AI prototyping app.

Further reading, honestly: Chris Nicol's Are Figma prototypes dead?, Dust's field study on prototypes over mockups, and Cabin's AI prototyping without Figma. Dust is explicit: do not believe the catchy RIP Figma headlines. They still use Figma upstream for journeys and sketching, and downstream for visual assets. Cabin says Figma still wins for production visual design and design-system docs. We agree. We are not going to steal their frames and slap a retainer on them.

AI prototyping tools (Ideoz, Figr, Alloy, and peers) are useful for fast interactive exploration. That is a real gain. It is also not the scarce job. Judgment still sits with the team: which direction deserves to exist, whether the product logic holds, and how a prototype becomes Framer, Webflow, or React that engineering can keep. Tools accelerate exploration. They do not replace a partner, and Clearly is not trying to be one of those tools.

If the bottleneck is executing on fully specified tickets, a request-queue subscription is usually faster and cheaper. That split is the Designjoy alternatives page. If you already own the judgment and just want faster exploration, try the tools. Clearly fits when the bottleneck is definition: roles, billing, multi-role states, and edge cases that are still open. The hire-versus-subscribe version is design subscription vs hiring.

How Clearly runs it

Most of the value happens before anything is built. Engagements are weighted toward working through uncertainty with you: what to build, how to sequence it, how to tell its story. Then we shape it into a product direction. Only then do we move into production. Prototype-first discovery is on every workstream, Standard and Advanced. It is the method, not an upgrade checkbox.

Working through. We open with discovery questions, not scope questions. The goal is surfacing what is uncertain, not estimating deliverables. Which user states do not exist in the current thinking. Which flows carry conflicting logic. Which edge cases nobody has resolved. A request queue cannot do this, because it starts from a specified ticket. We start from the problem.

Shaping. Prototypes take over. A working flow resolves product direction faster than a written spec. Stakeholders react to something real. Engineering sees how the logic hangs together before a sprint is committed. Founders can feel whether the direction is right. By the time shaping is done, the open questions have answers and the team is working from the same picture.

Producing. Calmer than most teams expect. The prototype already resolved the hard calls. Production does not reopen what shaping closed. It executes on what has already been decided, in Framer, Webflow, or React, depending on the surface.

The unit of work is a workstream: a bigger initiative (a rebrand, a launch site, onboarding, a product feature) that can hold smaller related tasks underneath it. We finish the workstream before jumping to something unrelated. Scattered priorities produce scattered products. Standard runs one workstream at a time. Advanced runs two in parallel, so a second initiative does not wait on approval in the first.

Collaboration is embedded, not on-demand. Dedicated Slack. Looms when a decision needs to be walked through. Weekly progress on Standard. Check-ins as needed on Advanced. We do not run a public request board.

Pricing below is from the live homepage. Confirm on clearly.design before you buy. Pause or cancel anytime. No invented throughput claims.

Standard, $4,995/mo. One workstream at a time. Completely async, with weekly progress updates. 24/7 access to Figma. Looms and a dedicated Slack channel. Prototype-first discovery on every workstream. Framer and Webflow development. Motion design. Unlimited requests and revisions inside the active workstream. Credit card or invoice. Money-back guarantee.

Advanced, $7,495/mo. Two workstreams at a time. Continuous progress with check-ins as needed. Integration with your engineering team. Custom components in Tailwind (React or HTML). Prototype-to-production translation. Plus the Standard stack: Slack and Looms, prototype-first discovery, Framer/Webflow, motion, pause or cancel.

Shipped in the stack you actually use. Framer and Webflow when the surface is a marketing or launch site. React and Next.js when it is an authenticated product. If engineering is using coding agents, a pretty Figma file is not the handoff. That is an AI-ready design system, not a styleguide PDF. Light versions: DESIGN.md, Claude Code design skills, and the AI-ready design systems series. This page will not turn into that tutorial.

The same sequence shows up on internal tools and business portals: the expensive part is deciding what to build. The fuller partner pitch lives on design partner for SaaS startups. This page is the method.

Proof, without invented numbers

We will not manufacture case-study metrics for this page. What we can share is what founders on the homepage actually said, and where to read the work.

Andy Berkowitz, founder and CEO at Suggestion Ox, called the working mode: a prototype-first approach was great, and it made it possible to iterate fast. That is the on-brand line.

Will Andre, CEO at NodCards, compared us to the freelancers and agencies he had used: a true partnership approach. The team envisions themselves as owners in the outcomes.

Craig Hewitt, founder and CEO at Castos, hired for product and design first, not decoration. Roeland van Nieuwkerk, CTO at Wealthstack, described product thinking beyond aesthetics: how the decision hits the product, the brand, and the customer experience. Jordan Gal, founder and CEO at Hey Rosie, wanted great design without hiring in-house. Flat monthly fee, quick turnaround, high execution.

The work itself, without invented numbers:

• Cloud Accountant Staffing candidate portal: a multi-role product, not a brochure site
• Nekst directory: a two-sided marketplace that had to be clickable before it was built
• Suggestion Ox Live Q&A: states first, pixels second
• Wealthstack Budgets: monthly cashflow designed as a native part of a planning tool

More on the case studies index.

Who this is for, and who it isn't

This is a fit if you are an early-to-growth B2B SaaS founder or PM whose bottleneck is product definition, not design capacity. Open questions: role-based flows, billing logic, multi-step onboarding, authenticated states that are not fully specced. You want a senior partner in Slack who will challenge a brief, prototype the decision, then help you ship.

This is not a fit if you can already write fully specified tickets and just need a faster queue. Stay on Figma, or on a Designjoy-class board, if the briefs are complete. Hire if design is becoming a core competency and you can wait through recruiting. Pick an AI prototyping tool if you want fast exploration and already own the judgment yourself.

Bring the product problem, not a perfect brief. The discovery call is where we figure out whether prototype-first discovery with Clearly, a queue, a hire, or staying in Figma is the right next step. Start with homepage pricing if you want the live numbers, or the design partner page if you want the model before the method.