How to Prototype a SaaS Product in Two Weeks: From Clickable Mockup to Working Pilot

This playbook picks up exactly where the validation framework ends. You’ve run the tests; the demand is real. Now two audiences are asking for the same impossible thing on the same short clock: investors want to see something working, users need something to react to, and the full build is months away. The trap is treating this as a small version of the build. It isn’t. It’s a different object with a different job, and the job fits in two weeks precisely because of what you refuse to build.

There’s a saying at IDEO, the firm that made prototyping a discipline, that captures why the object is worth two weeks of anyone’s life:

“If a picture is worth 1,000 words, a prototype is worth 1,000 meetings.”

A saying at IDEO, via Tom and David Kelley, Creative Confidence

Meetings argue about what users would do. A prototype lets you watch what they actually do, and the watching is the product of this fortnight. Here’s how we run it as a SaaS development company: the tiers, then the schedule, then the measurements.

What a Prototype Is For: Learning, Not Launching

A prototype exists to answer questions cheaply, and every decision in the next two weeks follows from naming the question first. “Do users understand what this is and want to proceed?” is a question a clickable mockup answers. “Does the workflow survive contact with real data?” needs a working journey. “Can we handle 10,000 users?” is not a prototype question at all; it’s a build question wearing a costume, and trying to answer it now is how two weeks become two months.

The corollary founders resist: prototype code is scaffolding, not foundation. The thin backend you write in week two exists to produce learning, and most of it should be cheerfully discarded when the real build starts, the same way a movie set isn’t the first floor of a real building. Teams that promote prototype code into production are laying the first bricks of the pattern we mapped in the hidden APR of cheap code: a fortnight’s shortcuts financed at compound interest. Write it fast, learn from it, and let it go.

The Three Fidelity Tiers

The rule that keeps the fortnight honest: pick the cheapest tier that answers this week’s question. Fidelity you didn’t need is budget you don’t get back, and the most common two-week failure is spending both weeks polishing tier 1 because polishing feels like progress. The schedule below exists to prevent exactly that.

Week One: One Journey, One Clickable, Five Users

Days 1-2: scope the one journey that matters. Not the feature list: the single path a first-time user takes from arriving to receiving the core value. “Paste a job posting, get a ranked shortlist, export it.” Write it as numbered steps on one page, then cut: no settings, no team management, no billing, no second persona. Everything cut is written on a “later” list so the team stops relitigating it. If the journey doesn’t fit on a page, you’re prototyping two products; pick one.

Days 3-4: design the clickable. Every screen in the journey, wired together in a design tool so it feels navigable, with one discipline that separates useful prototypes from pretty ones: realistic content, not lorem ipsum. Real-looking job postings, plausible names, believable numbers, because users react to content, and placeholder text quietly hides the comprehension problems you’re paying to find. Speed matters more than polish; this is also where professional UI UX design earns its keep, since a practiced designer produces in two days what takes a founder two weeks.

Day 5: test with five users. Recruit from your validation waitlist or pilot group (people with the problem, not colleagues), give each a task, not a tour (“you need a shortlist for this role; go”), and then do the hardest thing in the whole playbook: watch in silence. Every time you explain, you erase a finding. NN/g’s research is blunt about why five is the number: a first round with five participants surfaces about 85% of the usability problems, and the better use of a sixth user is testing the fixed version later. By Friday evening you have a ranked list of everything that confused real people, which is the most valuable document the project owns.

Week Two: The Thin Backend, and Faking the Rest on Purpose

Days 6-7: fix what the tests broke, then build thin. The morning is design fixes from day 5. The rest is the thin backend for the one journey: the simplest stack your team already knows (this is no moment for new technology), one data store, deployed anywhere simple. Auth can be magic links; the admin panel can be a database GUI; email can be you.

Days 8-9: wire the real journey, fake everything else deliberately. The core journey works end to end with real data. Around it, choose your fakes consciously: the “integrations” page is a static screen, the recommendation engine is a rules file or you personally curating results overnight, notifications are hand-sent. Deliberate faking is a legitimate, honorable prototyping tool with one governing rule we established in the Wizard of Oz post: fake only what you know how to build. A human behind the curtain standing in for engineering you could do is a schedule shortcut; a human standing in for capabilities you don’t know how to build is a demo writing checks the build can’t cash, and it converts your prototype’s findings into fiction.

Day 10: the pilot goes live. Five to ten users from the validation cohort, using it for real work, knowing it’s an early pilot. Real stakes, honest framing, and the meters below already agreed.

What to Measure in the Pilot

Three numbers, written down before day 10 so the results can’t be negotiated afterward. Task completion: did they finish the journey without you helping? A pilot where three of eight complete unaided is telling you something a demo never would. The drop-off point: where exactly did the others stall, and what did they say there? The location of failure is the spec for the next iteration. Willingness to continue: did they book a second session, or ask to keep their access when the pilot window closed? The first two tell you what to fix. The third is the tell, for the same reason week-four retention anchored the validation framework: nobody asks to keep using a thing they were merely being polite about.

The Line Between a Fair Prototype and a Misleading Demo

The same object plays two rooms in the same fortnight, and the disclosure rules differ. With users, fakery needs no announcement; you’re testing their behavior, and the curtain is the method. With investors, the line is bright: show the prototype proudly, and answer “is this working?” with the truth: “this journey is real; these parts are simulated and here’s the build plan for them.” Sophisticated investors have seen a thousand demos, and the founder who volunteers the seams reads as credible while the founder caught hiding them reads as radioactive; this is the exact dynamic we dissected in the Sugar Rush MVP post, where speed impressed nobody once credibility cracked. The prototype’s job with investors isn’t pretending to be the product. It’s proving you know precisely what the product must do, because you watched ten real people try it.

Turning Prototype Learnings into a Build Spec

The fortnight’s real deliverable is a build spec with evidence attached, and it has four parts: the journey map annotated with observed failures (“4 of 8 stalled at the export step, all for the same reason”), the ranked fix list from both test rounds, the deliberate-fakes register with what replacing each one actually requires, and the pilot metrics as the baseline the real product must beat. That document changes the economics of everything after it: scope debates get settled by observations instead of opinions, estimates attach to journeys users completed rather than features imagined, and the thin backend retires with honor. Walking into a build with that file is the difference between commissioning software and commissioning an experiment at software prices, and it’s the artifact any competent web development services partner should ask to see before quoting.

FAQs

What is the difference between a clickable prototype and an MVP?

A clickable prototype is wired screens with no real backend: it tests comprehension and desirability in days. An MVP is a real, if minimal, product that users adopt over weeks. The two-week playbook sits between them: a clickable in week one, and a working pilot (one real journey on a thin backend) in week two, producing the evidence that makes the eventual MVP build a safer bet.

How many users should test a SaaS prototype?

Five per round, per the Nielsen Norman Group’s finding that a first test with five participants surfaces about 85% of usability problems. The productive move after five is fixing and retesting with a fresh five, not recruiting more into the same round. Recruit people who actually have the problem, give them a task rather than a tour, and watch without helping.

Can I show a prototype to investors, or does it need to be a working product?

Show the prototype, and volunteer the seams: which journey is real, which parts are simulated, and what the build plan is for each. Investors evaluate whether you understand your product and users, and a prototype backed by pilot observations demonstrates that better than a fragile full build. What damages credibility isn’t fakery; it’s concealed fakery discovered by a question.

What should the prototype fake, and what must be real?

The core value journey must be real end to end with real data, because that’s where behavior and retention signals live. Everything around it can be faked deliberately: static settings pages, hand-run fulfillment, manual notifications, with one rule: only fake capabilities you know how to build. Faking the impossible turns your findings into fiction and your demo into a liability.

How much does it cost to prototype a SaaS product?

Run internally, the cost is two focused weeks from a designer and a developer plus small tooling fees. As an engagement with a product prototyping services team, it’s a fixed two-week sprint, typically a small fraction of the full build’s budget. Either way it’s the cheapest insurance in product development: it converts the largest unknowns (will users understand it, complete it, and want to keep it) into observations before the expensive decisions are made.

Sources

• Nielsen Norman Group, Why You Only Need to Test with 5 Users (based on Nielsen and Landauer, 1993)
• Tom Kelley and David Kelley, Creative Confidence: Unleashing the Creative Potential Within Us All (2013), source of the IDEO prototyping saying

Looking for timeline and cost estimates for your app?

Contact us

Nilesh K.

Marketing Manager

Nilesh Kadivar leads Marketing & GTM at Techuz, where he helps startups and enterprises turn software, AI, and automation ideas into shipped products. He's spent 10+ years in business development and enjoys writing about tech trends, growth strategy, and the realities of building for the web and mobile.