Prototyping for Start-ups

How to test your big idea without giving away the farm

You've had The Idea. The one that wakes you up at 2am. The one you've half-explained to your partner, your mate down the pub, and a stranger at a wedding who politely nodded and backed away.

Now comes the hard bit: finding out if anyone other than you actually wants it, without spending your last penny building the whole thing first.

Good news. You don't need a finished product to get real answers. You need a prototype: a rough, fast, cheap stand-in for the real thing, built just solid enough to test one question at a time. Here's how we'd go about it.

Start by asking a smaller question

"Will people buy my app?" is not a testable question. It's too big, too vague, and it'll have you building for six months before you find out the honest answer is "no."

Break it down instead:

• Will people click on this?
• Will they hand over their email for it?
• Will they pay a deposit before it exists?
• Do they understand what it does in five seconds, or do they squint?

Each of those is answerable in a week, not a year. That's the whole trick: test the smallest thing that would change your mind.

Prototype the bit that's actually risky

Not every part of your idea needs proving. You probably already know people want faster deliveries, or cheaper insurance, or an easier way to split the bill. What you don't know is whether your specific solution to that problem actually works, or whether anyone trusts you enough to try it.

So prototype the risky bit, not the whole thing. If your idea lives or dies on one clever bit of matching logic, mock up just that. If it's really about whether people will trust a stranger with their house keys, test the trust bit before you've built the keyless entry system.

This is also, handily, a decent way to protect your idea. More on that below.

Build it fast: HTML prototypes and AI tools

You don't need a development team to make something people can click through. A well-built HTML prototype (a set of web pages that look and feel real but don't have any working systems behind them) is often all you need to run a proper test. People can click buttons, fill in forms, and get a genuine feel for the thing, while behind the curtain it's held together with sticky tape.

If budgets are limited, tools like Claude are genuinely useful here, and there's nothing stopping you having a go yourself. You can describe what you want, get a clickable prototype back in minutes, and iterate live while you're on a call with a potential customer. It won't do the deep technical thinking your product eventually needs, but for "does this concept land," it's fast, cheap, and lets you test ideas long before they're worth a single line of production code.

Equally, if you'd rather have an extra pair of expert hands, that's exactly the kind of thing we love getting stuck into too. Either way, show us what you've discovered and you'll save time and money on the discovery process, since we won't be starting from scratch working out what your customers want.

Rule of thumb: if you're using it to answer a question, prototype it fast and rough. If you're using it to run your business, build it properly. Don't confuse the two.

Hiding in plain sight

Here's a trick that sounds counterintuitive: sometimes the safest way to test an idea is to be completely open about it.

If you've got a genuinely novel idea, there's a temptation to protect it like a state secret before anyone's seen it. But most ideas aren't stolen because they were talked about. They fail to launch because nobody ever found out if they were any good.

Hiding in plain sight means putting a rough version out into the world, but showing only the surface, the experience, the promise, not the mechanism underneath. A landing page can sell the outcome ("get a quote in 60 seconds") without revealing how your pricing engine works. A prototype can let someone click through a booking flow without exposing your matching algorithm. People fall in love with what a product does for them long before they care how it's built.

Do you actually need an NDA?

Short answer: usually not as much as you think.

A non-disclosure agreement (an NDA) is a legal contract that says "don't tell anyone what I'm about to show you." They have their place, particularly with contractors, manufacturing partners, or anyone getting deep access to your actual mechanism or code. But asking every potential customer, investor, or feedback-giver to sign one before you'll show them a login screen tends to do more harm than good.

It slows conversations down. It signals paranoia rather than confidence. And most investors won't sign one at all, since they see hundreds of ideas that overlap by coincidence, and an NDA would tie their hands unfairly.

A better instinct: protect the mechanism, not the mission. Talk openly about the problem you're solving and the experience you're building. Keep the clever, hard-to-replicate bit (the algorithm, the sourcing relationships, the technical architecture) closer to your chest, and only share that with people who genuinely need to see it to do their job.

Cheap ways to test real demand

Once you've got something to show, or even before you've built anything at all, you can test demand without spending big:

• A simple ad, aimed at a landing page. Run a small budget campaign on a genuine problem statement, send clicks to a page that explains the idea and asks for an email or a deposit, and see who bites. You're not selling yet, you're measuring curiosity.
• A "fake door" test. Add a button or feature to an existing product or page that doesn't work yet, see how many people try to click it, then tell them it's coming soon.
• A waitlist with a real ask. Don't just collect emails, ask for something small in return, a deposit, a survey, a referral. People who'll only give you an email address are cheap to find and don't tell you much.
• A concierge test. Do the thing manually, by hand, for a handful of real customers, before you've automated any of it. It's unglamorous but it's the fastest way to learn what people actually need.

A case in point: our client Hidden Gems are proper masters of this. Before they committed to building their app, they used social media to build genuine interest and demand, putting in time rather than money to work out what people actually cared about. No developers, no big spend, just consistent, curious presence where their future users already were. By the time it came to scale up and invest properly, they weren't guessing. They already knew.

The goal with all of these isn't vanity numbers. It's finding out, cheaply and quickly, whether real people will change their behaviour (click, pay, sign up, refer a friend) because of what you've built. Opinions are free and mostly wrong. Behaviour doesn't lie.

The long game

None of this is about moving fast and breaking things for its own sake. It's about being honest with yourself early, so the thing you eventually build properly is something people actually wanted all along. We're Boffins: we like getting our hands dirty with a rough prototype, we like a clever test, and we're always up for the long game over the quick punt.

If you've got an idea you're turning over at 2am and you're not sure where to start testing it, that's exactly the kind of conversation we like having.