By the time a founder reaches us, they’ve usually decided the answer is an app. Most of the time, what they actually need is a five-day exercise in clarity. We sell prototyping, not MVP development. A prototype is a clickable visual demo with no backend, no database, no auth, no real data. An MVP is a working product that real users can actually use.

That distinction shifts the conversation. Instead of “how long until we launch,” we ask “what’s the riskiest assumption we need to test right now?” In May, five founders got their answer in under a week. Not one of them ended up building the app they originally pitched.

A fire inspector needed a web form. A farmer needed a push notification. A beauty chain needed to stay on Instagram. A shaving startup needed a video. A massage service needed an SMS link. The only thing they shared was the belief that an app solved everything. Those decisions form the prototype development case studies we’ll unpack here.

What planning mistake keeps showing up before a prototype exists?

Founders plan features before they’ve planned a learning exercise. They map out a full app when all they need is an answer to one question. Across these projects, the mistake is always the same: confusing completeness with usefulness.

Stephen Pelkey at Atlas Fireworks learned this with PyroSafety. Full story in best practices below.

Day one with us kills the feature list. We don’t ask what the app should do. We ask which belief, if wrong, makes the whole project irrelevant. Good planning for an app prototype identifies that riskiest assumption and builds nothing else. Heavy planning waits until after the test proves the direction.

What core components make a clickable prototype useful, not just pretty?

Surface fidelity that provokes a reaction. Navigation that feels real. Nothing under the hood. A clickable prototype doesn’t need a database; it just needs to behave like it has one.

AI tools will generate thirty polished screens in a day: login, dashboard with charts, settings. What they miss is the domain edge case that defines your product. A generic prototype for Soil Sense would show a beautiful dashboard with satellite imagery. It wouldn’t show a farmer receiving a push notification at 5:30 a.m. that reads “Plot 3: irrigate today, 22mm.” That edge case is user behaviour, not a feature.

We test every prototype with gloves, sunlight, bad signal, or a real gate code, not just in Figma. That is how Soil Sense was decided. Full story in best practices below. A prototype's job is to find the one component that changes behaviour and strip the rest away.

What framework do we use to make Starter repeatable in five days?

We pull apart the founder's assumption, find the riskiest belief, and build only the screens that test it. The rhythm is blunt. Day one, kill the feature list. Day two and three, build only the riskiest screens. Day four, test with real users. Day five, decide: build, pivot, or kill it. That is the Starter rhythm, 7 working days. The same process scales to 2 weeks for Growth and 4 weeks for Pro.

The framework held: surface the assumption, build the smallest test, measure behaviour. Rapid prototyping isn't about speed. It's about refusing to build on top of something unproven. That's the rhythm we followed across all five projects.

What best practices are held across PyroSafety, Soil Sense, Golden Estética, Revolt and Cabo Mobile?

Don’t prototype everything. The one rule that keeps surfacing in these prototype development case studies: prototype the thing you’re least sure about.

PyroSafety: Atlas Fireworks asked for an offline app with auth and sync. Field testing with real inspectors wearing thick gloves proved they couldn’t use small inputs. The prototype became a mobile web form with oversized touch targets and a one-tap signature. No app store, no sync to maintain.

Soil Sense: Nekxsum wanted an agtech dashboard with satellite overlays and soil charts. Farmers testing the prototype ignored every visual and only acted on a push notification at 5:30 a.m. telling them whether to irrigate. The outcome was a WhatsApp alert system, not a dashboard.

Golden Estética: The chain believed clients would download a dedicated booking app. The prototype showed clients never left Instagram; the extra app was a barrier. The founder kept the prototype’s design language for confirmation pages and built an Instagram-first flow.

Revolt: The waterless shaving system wanted a full ecommerce app with 3D viewers and loyalty. A prototype of a looping video on a landing page with a two-tap purchase flow drove pre-orders before any cart existed. The app was cancelled and the budget shifted to video.

Cabo Mobile: The massage service pitched an Uber-like platform with two apps. We tested an SMS booking link instead. Clients texted, got a calendar slot, and the therapist received an automatic entry. Bookings moved entirely to SMS without a single app install.

Every prototype was disposable. None were built to scale. Our prototype design services are built on this rhythm: learn, throw it away, then build with conviction. The prototype vs MVP distinction isn’t academic. Ship a prototype to paying customers and you break trust. Use it as a research tool and it saves you from building features nobody asked for. That’s the right prototype, not the biggest one. Judgment over speed.

When should you skip a prototype and go straight to MVP?

When the risk isn’t user behaviour, it’s technical feasibility. Before Protobuild launched as its own offering, a B2B SaaS startup came through our parent company’s network with a signed enterprise pilot. They had a waiting list of users who needed live auth, real data, and real integrations. The question wasn’t “will anyone use this?” It was “can our architecture handle a thousand concurrent sessions?”

That’s an engineering problem, not a discovery problem. We told them to hire a dev team and skip us. A prototype would have been a detour. They didn’t need prototyping services. They needed load testing and a production environment. When uncertainty is technical, a clickable demo adds zero clarity. The honest move is to say that.

Summary

Five founders in May saved themselves from building the wrong thing. The pattern isn’t industry-specific. It’s human. We overbuild because we mistake features for progress. A prototype forces you to confront what users actually do.

We’re not a $20/month AI tool spitting out generic screens, and we’re not a $15,000 to $100,000 agency build. We sit in the gap, where a focused prototype answers the only question that matters: what should we build? Starter is €149 for up to 15 screens in 7 working days. Growth is €225 for up to 25 screens in 2 weeks. Pro is €495 for unlimited reasonable scope in 4 weeks, with a full handover doc including architecture sketches, DB schema outline, API endpoints, and a sprint breakdown. Revisions are batched: 2 rounds for Starter, 3 for Growth, 5 for Pro. A round is one batch of feedback sent together, not one fix. Book a call at protobuild.co.

Frequently Asked Questions

1.  What exactly is a prototype at Protobuild?

It’s a clickable visual demo with no backend, database, or live data. You can tap through screens and simulate a real app experience. It’s built purely for testing and stakeholder demonstrations.

2. How is that different from an MVP?

An MVP is a working product with real data, often handling real payments or user accounts. A prototype is a simulation, a visual shell with no technical debt. The prototype answers “should we build this?” while the MVP answers “can this sustain usage under real conditions?”

3. How long does it actually take?

Starter is delivered in 7 working days from brief approval. Growth takes 2 weeks. Pro takes up to 4 weeks depending on scope. The fast turnaround is possible because we aren’t building a backend or writing production code, just focused, high-fidelity front-end screens.

4. How many screens and revisions do I get?

Starter includes up to 15 screens and 2 rounds of revisions. Growth includes up to 25 screens with 3 rounds. Pro is unlimited within reasonable scope and comes with 5 rounds. A round is one batch of feedback sent together, not one fix.

5. What do I get at handover?

You own all screens, components, and design files. Growth adds a basic handover doc with screens, components, tech stack, and data structures. Pro includes a full handover with architecture sketches, a database schema outline, API endpoints, and a sprint breakdown so a dev team can start building immediately.

6. Can I test this with real users?

Yes, and you should. The entire point of a prototype is to put it in front of actual potential users and observe what they do, not ask what they think. It’s the safest way to gather honest behaviour data without exposing an unfinished product to the market.

7. What does it cost?

Starter is €149, Growth is €225, Pro is €495. All packages are one-time payments with a fixed scope and no hidden fees. You walk away with full ownership of the prototype and all associated files, ready to use however you need.