Hiring a software builder is a strange purchase: you're buying something you can't inspect, in a language you don't speak, from someone whose main evidence is screenshots of work you can't verify. The portfolios all look good. The promises all sound the same. And the price of choosing wrong isn't just the fee, it's the year you lose finding out.
But here's what levels the field: you don't need technical knowledge to detect technical seriousness. You need the right questions, because serious builders and risky ones answer them differently, and the difference is audible to anyone. Here are the seven we'd want asked of us, why each works, and the answers that should end the meeting.
1. "Who owns the code, the accounts, and the data, in writing?"
The question that prevents the most common disaster in this industry. The right answer is immediate and unhesitating: you own everything, source code in a repository under your business's control, hosting and domain in your name, transfer language in the contract.
The tell: hesitation, or "don't worry, that's all handled on our side." That sentence is the opening scene of a story we've written in full, what happens when developers disappear, and you do not want a speaking role in it.
2. "Show me something you built that's over a year old, still running."
Portfolios show launch-day screenshots; launch day is when everything looks good. What you're actually buying is how the work ages, and a builder proud of a system that's survived a year of real users, real data, and real platform updates is showing you the only evidence that can't be staged.
The tell: everything shown is recent, or "clients don't let us share." One live, aging reference exists in every serious portfolio. Zero is an answer.
3. "What happens after launch, and what does it cost?"
Software is never finished, only launched; why maintenance isn't optional deserves its own article and got one. The serious builder raises this before you do, a maintenance plan, named response times, transparent pricing for the years that follow.
The tell: "we can discuss that later" or a quote conspicuously silent about year two. That silence isn't a discount. It's a bill with a delayed delivery date.
4. "Walk me through how you'd handle my payment flow failing halfway."
You don't need to understand the answer technically, you're listening for whether one exists. The invisible layer (failed payments, security, data permissions, backups) is where cheap builds quietly cut, and where real businesses later bleed. Naming a concrete scenario forces the layer into the open. Bonus signal: serious builders reference actual security standards, OWASP is the industry's baseline, without being fished for it.
The tell: breezy confidence without specifics. "That won't happen" is not an architecture.
5. "What questions do you have for me?"
The stealth question, you're not gathering information, you're measuring their hunger for it. A builder about to construct your business's tool should be interrogating you: what problem does this solve, who uses it, what does success look like, what's the process today? The quality of a builder is visible in the quality of their curiosity before money moves.
The tell: they can quote you without understanding you. A price produced from a feature list alone means they're pricing typing, not thinking, and you'll pay for the thinking later, as change requests.
6. "What would you cut from my idea?"
Hand them your full vision and ask what they'd remove from version one. The serious builder engages instantly, this is the MVP conversation, and they've been quietly editing your list since you started talking. Their cuts, and the reasoning behind each, show you exactly how they think.
The tell: "we can build all of it!" Of course they can. Enthusiasm for your entire feature list isn't service, it's a builder who bills by the feature meeting a client who hasn't been told no yet. The word "no," early and reasoned, is the cheapest quality signal in this entire industry.
7. "If we part ways in two years, what does handover look like?"
The ending question, asked at the beginning, deliberately, because it's the only time it's free. You're listening for a system: documented code, a written map of services and credentials, a handover any competent successor can pick up. Builders who've done clean exits describe them concretely; builders who haven't get vague or vaguely offended.
The tell: offense. A professional knows every engagement ends eventually and builds for it. Someone threatened by the question is telling you what their exits look like.
How to read the whole interview
No single stumble is fatal, builders are human, meetings are imperfect. What you're scoring is the pattern: ownership instincts, evidence that ages, honesty about the unglamorous parts, curiosity about your business, and the willingness to say no.
Notice what all seven questions have in common: none require you to know software. They require the builder to demonstrate knowing it, in front of you, on the record, before the deposit. Print the list, take it to every meeting, including one with us. Especially one with us, we wrote it, so we'd better survive it.