The demo worked perfectly. It always does.
You watched someone click through it for twenty minutes: a signup screen, a dashboard, a form that saves, a button that sends an email. Every click landed. Nothing spun forever. Nothing threw a red error banner. You said yes because it looked done.
It also had one user, one record, and one path through the app. Nobody logged in twice. Nobody typed something strange into a field. Nobody found out what happens when the internet gets slow, or when two people try to edit the same thing at the same time.
That is the trap. The cost of a demo that looks finished dropped close to zero. The cost of a product that survives real users did not move at all. A polished screen recording does not tell you which one you are looking at, and if you cannot read code, you have no obvious way to find out.
You do not need to read code. You need eight questions.
The Real Problem: You Are Judging the Wrong Thing
Most non-technical founders judge software the way they judge a consumer app: does it look right, does it feel fast, does the flow make sense. That instinct served you fine as a user. It fails you as a buyer, because interface polish is exactly what AI coding tools got good at first. AI writes a screen faster than any human ever could, and speed on the visible layer says nothing about what happened on the invisible one. A convincing screen is now cheap. What still costs real time and real judgment is everything the screen does not show you: how data is stored, who can reach it, what happens when something fails, whether the thing can be changed safely next month.
That gap between what a demo proves and what a product needs is the whole risk of an AI-assisted build. It is not a technical footnote. It is the difference between a company that can raise its next round on a working product and one that spends the round paying to finish the first one.
You cannot close this gap by learning to code before your next demo. You can close most of it by asking questions that test what the screen cannot show you, and by paying close attention to how the answers land.
Eight Questions That Do Not Require Reading Code
Ask these in order, in the room, while the person who built it is still there. Do not accept "we'll follow up on that." A follow-up email is where vague answers go to become permanent.
1. Where does the data live?
You are checking whether there is a real, owned database behind the screen, or whether the builder is not entirely sure.
A good answer sounds like: "It's a hosted database under our own account, not a demo sandbox. Here's where the credentials live and who has access."
A bad answer sounds like: "It's saved somewhere. Don't worry about that part."
2. What happens when two users do this at once?
Every demo has exactly one user. Your product will not. This question tests whether anyone has thought about two people editing the same record, or two requests hitting the same row, at the same moment.
A good answer sounds like: "We tested that. If a second save comes in after the first, the person gets a warning instead of a silent overwrite."
A bad answer sounds like: "That's unlikely to happen at your size for a while."
3. Show me a failed login.
Type the wrong password on purpose. This is the fastest real test in the whole list, and it takes ten seconds.
A good answer sounds like a clear, generic error message, no lockout after one mistake, and nothing on screen that looks like a stack trace or a file path.
A bad answer sounds like a raw error dump, or worse, a login that lets you in anyway.
4. What happens when I paste ten thousand rows?
Demos run on a handful of records. Products run on however many your users bring. This tests whether anyone has thought about scale past the first week.
A good answer sounds like a specific description of the upload path, a stated limit, and what happens past that limit.
A bad answer sounds like the tab freezing, or a shrug.
5. Who can see this record?
This is the permission question, and it is the one that turns into a headline if it is wrong. It is also the finding we see most often when we review an AI-built product, and it sits near the top of the ways AI-built MVPs fail in production: a record that any logged-in user could reach by editing a number in the address bar. It is the same question an investor's advisor will ask in technical due diligence.
A good answer sounds like: "Only your account, and anyone you explicitly invite to this workspace. Here's the rule that enforces it."
A bad answer sounds like: "Technically everyone who's logged in, but nobody would think to look."
6. How do you deploy a change?
This tells you whether shipping is a repeatable process or a person editing a live server by hand.
A good answer sounds like: "We push to a branch, it runs checks, then it deploys. We can roll back a bad change in minutes."
A bad answer sounds like: "I usually just fix it directly on the server when something breaks."
7. What breaks if this service is down?
Every product depends on something outside itself: a hosting provider, a payment processor, an email service. This question tests whether the builder knows what those dependencies are and what happens when one of them has a bad day.
A good answer sounds like a named dependency and a plan: "If that goes down, uploads pause but the rest of the app keeps working."
A bad answer sounds like a blank stare, or "it's never gone down," which is not the same thing as a plan.
8. Can I have the repository?
This is the ownership question, and it matters more than any of the others once money changes hands. You are checking whether the code is actually yours, or whether it lives in an account you do not control, built inside a tool you cannot export from.
A good answer sounds like: "Yes, here's access, and here's how we'd hand off the account if we ever parted ways."
A bad answer sounds like hedging: "We manage that for you," with no path to actually holding it yourself.
How to Run This in Thirty Minutes
Book the review as its own meeting, separate from the pitch. Bring a friend who codes if you have one, or bring a fractional CTO whose only job that day is to ask these questions on your behalf. Go through all eight in order, three minutes each, and write down the answers in your own words immediately after, while you still remember what was actually said.
Do this before you sign a bigger contract, before you tell investors the product is built, and again after any major rebuild. A demo review is not a one-time gate. It is a habit, the same way reading your own signals instead of trusting a status update is a habit for founders who cannot review code themselves.
What We Do Differently
When we sit in on a demo review for a founder, we are not grading the screen. We are grading the answers to these eight questions, plus a ninth thing nobody puts on a list: whether the builder can answer without opening a new tab to check. Confident, specific answers usually mean the work happened. Answers that need research on the spot usually mean it did not, no matter how good the interface looked five minutes earlier.
We run this same review, formally, as part of a technical audit before a Fractional CTO engagement starts. The questions do not change. What changes is that we already know what a good answer looks like for your stack, and which gaps are a weekend fix versus a rebuild.
The Counterintuitive Part
You would expect a defensive answer to be the red flag. It usually is not the worst sign. The worst sign is an answer that is technically true and completely unhelpful: correct words, no substance, delivered fast enough that you almost do not notice nothing was actually said.
A good builder, by contrast, is glad you asked. They will often answer a question you did not ask, because they have already thought about it and have been waiting for someone to bring it up. Competence sounds like specifics. Risk sounds like reassurance.
What to Do Tomorrow
-
Write the eight questions on a card and bring them to your next demo, whether that demo is from a freelancer, an agency, or your own co-founder. Ask them out loud, in the room.
-
Score each answer as specific or vague, not as right or wrong. Vague answers to easy questions are the pattern that matters, more than any single wrong answer.
-
Schedule a formal review before you sign anything larger than what you have already paid, or before you repeat the demo for an investor.
Frequently Asked Questions
Do I need to learn to code to evaluate my own product?
No. Every question here is designed to be asked and understood without reading a line of code. What you need is a habit of asking about the parts a demo does not show, and someone who can translate the answers if the detail gets thick.
What if the builder gets defensive when I ask these questions?
Notice it, but do not treat defensiveness alone as proof of a bad product. Treat vague, generic reassurance as the real signal. A builder who has done the work usually welcomes scrutiny, because the answers make them look good.
Should I ask these questions even if I trust the person building my product?
Especially then. Trust is about intent, not about whether the permission model was configured correctly. These questions are not an accusation. They are due diligence you would run on any vendor, applied to software instead of a contract.
How is this different from a technical due diligence review before fundraising?
It is the same skill at a smaller scale. A pre-raise review covers more ground: repository access, dependency health, team bus factor, and more. This guide is the version you can run yourself, in thirty minutes, any time you are handed a demo and asked to believe it.
If you want someone else in the room asking these questions, a Fractional CTO engagement starts with exactly this kind of review. Schedule a free diagnostic call and bring the next demo with you.