A founder asked me a version of this question recently, a little sheepishly, like she felt bad even asking it: "my developer keeps telling me the app is fine, security-wise. Should I just trust that?" She liked the person. She'd worked with them for months. The question felt, to her, like an accusation she didn't want to make.
Trusting a person and verifying a claim are two different things
This is the reframe that actually matters here. Trusting someone's character, their intentions, their general competence, is completely separate from confirming a specific technical claim is true. You can fully trust that your developer isn't lying to you and still reasonably want to see what "it's fine" is actually based on. Those aren't in tension. Doctors get second opinions from doctors they trust completely. Auditors check other auditors' work. Verification isn't an accusation. It's just what "fine" needs to survive contact with, for anyone's peace of mind, including the developer's.
What "it's fine" usually means when you ask what it's based on
Most of the time, "it's fine" means the app has been used a lot, by real people, without anything visibly breaking. That's a genuinely reassuring signal about whether the app functions. It's a much weaker signal about whether it's secure, because most security gaps don't visibly break anything for the people using the app correctly. They only surface when someone specifically tries to misuse it, and "nobody's misused it yet" and "nobody could" are very different claims.
Questions that get you a real answer either way
- "What specifically did you check, and when?" A real answer names something concrete: a scan that ran, a specific test performed, a date. A non-answer restates confidence without specifics.
- "If I log in as one test account, can I see another account's data by changing something in the URL?" This is testable in front of you, in real time, and doesn't require you to understand any of the underlying code.
- "Has anyone other than you tried to break this on purpose?" Being the only person who's ever tested an app, even a very good developer, has a real, well-documented blind spot. It's not a knock on their skill to ask this.
- "What would it take to get an outside pair of eyes on just the security side?" A reasonable developer should be able to answer this without getting defensive. Defensiveness itself is more informative than the answer.
What actually should make you pause
Not a wrong answer. Nobody who built something fast with AI tools catches everything, and admitting a gap exists is a good sign, not a bad one. What's worth pausing on is vagueness that doesn't resolve when you ask a second time, or a shift toward being offended that you asked at all. A developer who welcomes the question, even if the honest answer is "I haven't specifically checked that," is telling you something very different from one who deflects.
You don't need to learn to code to ask these questions, and asking them well is not the same as distrusting someone. It's the difference between hoping something is true and actually knowing it, and for anything holding real user data, that difference is worth a five-minute conversation before you decide which one you're operating on.