We get asked some version of "does it work?" from almost every founder we talk to. It's the wrong question, and we've never found a polite way to say that in a first call, so here's the honest version instead.
The question that actually decides whether a product survives isn't "does it work." It's "what happens when it doesn't?"
Founders are trained to expect success. Users aren't obligated to give it to them.
Most non-technical founders have spent their whole working life using software that already works. They open an app, it does the thing, they move on. Nothing in that experience trains a person to picture the ways it could have failed, because by the time it reaches them, someone already found and fixed those ways.
Building it is the opposite kind of work. A login screen isn't hard because handling a correct password is hard. It's the wrong password, the account that doesn't exist yet, the password reset nobody built, and the session that expires mid-form that actually take the time. A checkout flow isn't hard because charging a working card is hard. It's the declined card, the one that gets flagged after the page already said "success," and the promo code that collides with a discount nobody tested together that take the time. The part a founder sees in a demo is usually the easy 80%. The part that decides whether real strangers can trust the product with their time or their money is the 20% that never shows up unless you go looking for it on purpose.
We get asked some version of "does it work?" from almost every founder we talk to. It's the wrong question, and we've never found a polite way to say that in a first call, so here's the honest version instead.
The question that actually decides whether a product survives isn't "does it work." It's "what happens when it doesn't?"
Founders are trained to expect success. Users aren't obligated to give it to them.
Most non-technical founders have spent their whole working life using software that already works. They open an app, it does the thing, they move on. Nothing in that experience trains a person to picture the ways it could have failed, because by the time it reaches them, someone already found and fixed those ways.
Building it is the opposite kind of work. A login screen isn't hard because handling a correct password is hard. It's the wrong password, the account that doesn't exist yet, the password reset nobody built, and the session that expires mid-form that actually take the time. A checkout flow isn't hard because charging a working card is hard. It's the declined card, the one that gets flagged after the page already said "success," and the promo code that collides with a discount nobody tested together that take the time. The part a founder sees in a demo is usually the easy 80%. The part that decides whether real strangers can trust the product with their time or their money is the 20% that never shows up unless you go looking for it on purpose.
This is exactly why demos lie a little, even honest ones
A demo is a controlled environment. You click the happy path because you already know where it is. Real users don't know where it is, and they won't follow it. They'll double-click a submit button, lose their wifi mid-upload, open the app on a second device, or type an email address with a typo in it, all in the first ten minutes. None of that is bad luck. It's just what a large enough group of ordinary people actually does, and most early products that stall don't fail because the idea was wrong. They fail because the failure paths were never built, and the first real user to wander off the happy path found that out before the founder did.
This gets worse, not better, with how fast products get built now. A one-sentence prompt into an AI app builder can produce something that looks completely finished in an afternoon, because the tools are genuinely good at the visible 80%. They're rarely asked to handle the invisible 20%, because nothing about a fast demo ever forces the question. The gap doesn't announce itself. It just waits for the first real user.
What we actually mean when we say something is "done"
This is close to the standard we hold at EnactOn before we call anything ready: not "does it work when I click it the right way," but "what does it do when someone clicks it the wrong way, on a bad connection, at 2am, using a card that gets declined." A real build process treats that question as part of the work, not as a nice-to-have you get to if there's time left, because there's rarely time left, and the founder is the one standing in front of the user when it shows up unhandled.
None of this means founders need to learn to code. It means the next time something "works" in a demo, the better question to ask isn't "did it work." It's "what did we never actually try to break." A real pre-launch check exists to ask exactly that, on purpose, before a stranger asks it for you.
So, genuinely: what's one thing you wish a founder understood about how software actually gets built?
A demo is a controlled environment. You click the happy path because you already know where it is. Real users don't know where it is, and they won't follow it. They'll double-click a submit button, lose their wifi mid-upload, open the app on a second device, or type an email address with a typo in it, all in the first ten minutes. None of that is bad luck. It's just what a large enough group of ordinary people actually does, and most early products that stall don't fail because the idea was wrong. They fail because the failure paths were never built, and the first real user to wander off the happy path found that out before the founder did.
This gets worse, not better, with how fast products get built now. A one-sentence prompt into an AI app builder can produce something that looks completely finished in an afternoon, because the tools are genuinely good at the visible 80%. They're rarely asked to handle the invisible 20%, because nothing about a fast demo ever forces the question. The gap doesn't announce itself. It just waits for the first real user.
What we actually mean when we say something is "done"
This is close to the standard we hold at EnactOn before we call anything ready: not "does it work when I click it the right way," but "what does it do when someone clicks it the wrong way, on a bad connection, at 2am, using a card that gets declined." A real build process treats that question as part of the work, not as a nice-to-have you get to if there's time left, because there's rarely time left, and the founder is the one standing in front of the user when it shows up unhandled.
None of this means founders need to learn to code. It means the next time something "works" in a demo, the better question to ask isn't "did it work." It's "what did we never actually try to break." A real pre-launch check exists to ask exactly that, on purpose, before a stranger asks it for you.
So, genuinely: what's one thing you wish a founder understood about how software actually gets built?
