What Can You Actually Build With a Rapid Prototype?

The most common thing I hear from non-technical founders before we start working together is some version of: "I don't want to spend €20,000 on something nobody wants." That's a completely reasonable fear, and it's exactly the problem rapid prototyping is designed to solve.

But "rapid prototyping" is one of those phrases that sounds reassuringly professional while meaning almost nothing to someone who hasn't seen it in practice. So instead of explaining the concept, let me show you what it actually looks like.

What a Prototype Is (and Isn't)

A prototype is a working piece of software that does one or two things well enough to test with real people. It's not a mock-up in Figma. It's not a landing page with a waitlist form (though that has its place). And it's definitely not a finished product with a polished UI, a marketing site, and a payment integration.

It's functional and fast to build. Its whole shape is decided by the single question you're trying to answer, which is usually: "Will people actually use this?"

The tools I reach for most often are Ruby on Rails for the back-end and either plain Hotwire or a lightweight React front-end depending on how interactive the thing needs to be. Rails especially earns its keep here, because the convention-over-configuration approach means you're not making a hundred setup decisions before writing a single line of actual product logic. I've written more about why Rails is still the right call for MVPs if you want the longer version.

Real Examples of What Gets Built

A Booking and Scheduling Tool

One of the most common requests I get from small service businesses is some version of: "I'm managing all my bookings over WhatsApp and I'm losing my mind." A prototype for this is usually a simple web app where customers can select a time slot, fill in a short form, and get a confirmation email. The business owner gets a basic admin view showing upcoming bookings.

That's it. No Stripe integration yet. No automated reminders. No customer accounts. Just: does the core loop work, and does it save the owner time?

Built in Rails with Action Mailer for the emails, this kind of thing takes roughly a week. If clients start using it and the owner stops losing bookings, you've validated the idea. Then you decide what to build next.

An Internal Data Dashboard

A client came to me with a folder full of Excel files that three people were updating separately, emailing back and forth, and regularly overwriting each other's work. The prototype was a simple web dashboard: a shared interface where the same data lived in one place, could be filtered and sorted, and where each user had a login so you could see who changed what.

No fancy analytics. No integrations. Just the data, visible, editable, and not broken every time someone saved over the wrong version.

This is a case where even a rough prototype makes a dramatic difference immediately, because the before-state is so painful. It also tends to reveal, quickly, what the team actually needs next, which you can't always know in advance. The longer version of this diagnostic is in when Excel is enough.

A Lead Qualification Workflow

A founder I worked with was spending two hours a day doing initial intake calls that filtered out 80% of leads before anything interesting happened. The prototype was a multi-step form that walked potential clients through a series of qualifying questions, scored their responses, and either booked a call automatically or sent them a polite "not quite the right fit" email.

The logic wasn't complicated. The form was built with a bit of Stimulus for the step-by-step flow and a simple scoring table in the database. But the founder went from two hours of intake calls per day to about twenty minutes, within a week of going live.

That's the thing about prototypes for workflow problems. You don't need to solve the whole problem. You need to solve the expensive part.

A Client-Facing Portal

Agencies and consultants often manage client work through a combination of email threads, shared Google Drives, and the occasional Notion page someone forgot to update. A prototype client portal is typically a simple authenticated web app where clients can log in, see the status of their project, upload files, and leave comments.

Not beautiful, not feature-complete. But it replaces the email thread. That alone is usually enough to prove the value.

A Scenario That Comes Up More Than You'd Think

Someone has a niche B2B idea. They've talked to ten potential customers and they all said "yes, I'd pay for that." The founder wants to know whether to hire a development agency and spend €40,000 building it properly.

My usual answer: not yet. Build a prototype first. Specifically, build the one screen or the one workflow that represents the main value of the product. Let five of those ten customers actually use it, even if it's rough around the edges and you're manually handling some things behind the scenes that will eventually be automated.

If they use it and find it valuable, you have real signal. If they don't, you've learned something important for a fraction of the cost. The "yes I'd pay for that" conversation is useful, but it isn't the same as watching someone actually reach for their wallet.

This approach has a name in lean startup circles. It's sometimes called a "concierge MVP," where you manually handle back-end operations while the user interacts with a simple front-end. Unglamorous, but it works. For the fuller argument on scoping, see what an MVP actually is.

Timelines You Can Realistically Expect

A focused prototype with a clear scope (one primary workflow, basic authentication, and a simple admin view) is typically a one to three week project. That assumes the requirements are reasonably well-defined going in, which is worth spending a day or two on before writing any code.

The scope creep risk is real. "Can we just add..." is the phrase that turns a two-week prototype into a two-month one. The discipline of keeping a prototype small isn't just about saving money. It's about keeping the feedback loop short enough to be useful.

What you get at the end isn't something you'd necessarily show to investors as a finished product. But it's something real people can use, that proves a real workflow, with real data. That's worth more than a slide deck.

If you have a business idea you want to test before committing to a full build, I can help you scope and build a prototype that answers the right questions quickly. Get in touch and we can talk through what that looks like for your specific situation.