It Works When You Demo It

The demo always goes well.

You've done it a dozen times now. Same three clicks, same test order, same sample customer called Test Test. It looks good. People lean in. Someone says "hang on, you built this?"

Then you hand the laptop across the table, and inside about forty seconds it's sitting on a blank white screen.

Nothing has actually gone wrong there. You've just watched the most useful thing a prototype can do, which is show you the distance between working and working.

Why does it break the second someone else touches it?

Because you have been walking one path through it, and they aren't.

You know the postcode field wants four digits and no spaces. You know not to hit back. You know it takes a second to save, so you wait. You know to stay out of the second tab, because the second tab was never finished. None of that knowledge is in the software. It's in you, and it doesn't travel with the laptop.

This isn't a beginner's mistake, either. Every engineer I've worked with has built something that only they could operate, usually while insisting it was nearly done. The difference is that we've been burned enough times to know what the gap is called, and roughly how long it takes to close.

The five things your demo has never had to survive

Real data. Test Test of 123 Test Street is a very polite customer. Real ones have apostrophes in their surnames, two family names, an ampersand in the business name, a PO box instead of a street, a phone number typed with spaces, and an address in Woolloomooloo that runs off the end of your beautifully aligned card. Every one of those is a small crack, and you find them all at once, on the same afternoon, when real people arrive.

Somebody else's data. The moment there are two customers, your software has to answer a question nobody has ever asked it: whose is this? Most weekend builds quietly show everything to everyone, because when you're the only user, everything is yours. That's fine in a demo and genuinely serious the day it's live, especially if you're holding names, addresses or anything a customer would be upset to see land in someone else's account.

Failure states. The card gets declined. The upload times out. Someone loses reception in a lift halfway through a form. The email service has a bad morning. In your demo none of that happens, because you're on your own wifi, doing the thing you designed, at a moment of your choosing. Software for other people spends a surprising amount of its code on what to do when the answer is no.

A person doing it wrong. Double-clicking submit and getting charged twice. Hitting refresh at the wrong moment. Going back after paying. Pasting in a whole paragraph where you expected a word. Uploading a photo straight off an iPhone that's four times bigger than anything you tested with. None of this is malicious. It's just what happens when people who don't know how it was built start using it.

Two people at once. Two customers booking the last spot in the same three seconds. Two staff editing the same record. Your laptop has never had to have an opinion about that, because there has only ever been one of you.

So was building it a waste of time?

The opposite, and this is the part people get wrong when they get embarrassed about their prototype.

You have already answered the questions that normally take the longest and cost the most to get wrong. What does this thing do. What does it look like. What order do the steps go in. What did people say when they saw it. What did they ignore. Which bit made them reach for their wallet.

A written brief guesses at all of that. You have evidence. Most projects that get into trouble do so because nobody could describe what they were building until it was half built, which is a pattern we've written about in why web projects blow up. You skipped that trap by accident.

So the prototype isn't the product. It's the best brief you'll ever hand anyone, and it's worth protecting rather than apologising for.

How do you find out how far off you actually are?

Two tests. Both are free and both take an afternoon.

The stranger test. Find one person who isn't obliged to be nice to you. Not your partner, not the friend who already loves it. Give them the thing on their own phone, tell them what you'd tell a customer, and then sit on your hands. Don't help. Don't touch the screen. Don't explain. Every single time you feel the urge to say "oh, you just have to", write it down instead. That list is your gap, in your own handwriting, and it's usually shorter and more fixable than it feels while you're watching.

The six honest questions. Answer these as they are today, not as you intend them to be.

1. If the whole thing vanished tonight, could you get it back? Not the code, the customer data.
2. If a stranger signed up right now, would you know?
3. If it broke at nine o'clock on a Friday night, would you find out before a customer told you?
4. Is anyone's personal information in there, and can you say where it physically lives?
5. Can anyone other than you change it, or is it one laptop and one head?
6. If somebody paid you money through it today, could you refund them tomorrow?

If most of those answers are no, you're not behind. You're exactly where every prototype sits. That gap is the last ten per cent, and the reason it has its own name is that it reliably takes longer than the ninety per cent you've already done.

What the last stretch usually involves

Less rewriting than people fear, most of the time.

The screens, the flow and the decisions you made are usually worth keeping. What gets added is the unglamorous half: real accounts and permissions, a database that belongs to your business rather than a trial plan, backups you've actually tested restoring, error handling, something watching it that pages a human when it falls over, and a way to change it without holding your breath.

That work is measured in weeks, not weekends, and it's the part that turns a thing you can demo into a thing you can sell. We'll go through what "production ready" means item by item later in this series, and what a stalled build looks like when it's someone else holding the keyboard.

If you'd rather not guess, send it over. We'll tell you what's solid, what has to be replaced, and what genuinely stands between where you are and real customers, whether or not you ever hire us.