Hiring development work when you're not technical has a fundamental problem: you can't evaluate the product you're buying. You'll see screens, and screens look fine whether the system underneath is healthy or about to fall apart.
The good news is you don't need to read code. It's enough to ask the right questions and pay attention to how they're answered.
1. "Who owns the code?"
It's the first and most important one. The answer has to be: you, no hedging.
Ask for access to the repository from day one, even if you never plan to open it. Not to control it: so that it exists. If the code only lives on someone's machine, or in an account you can't access, you don't have a system: you have a dependency.
A red flag: being told it'll be handed over "once it's finished." Code gets delivered from day one and grows in plain sight.
2. "What happens if you disappear tomorrow?"
It's not distrust, it's continuity. A serious vendor has already thought about this.
What you want to hear: that there's documentation on how to spin up the project, that credentials and access live somewhere you control, and that another team could pick it up. What you don't want to hear: "don't worry, we're not going anywhere."
A concrete and very revealing test: ask them to explain how another team would go about setting up the project from scratch. If the answer is long, verbal, and full of "and you also have to...", that's your answer.
3. "How do we know it works?"
Ask how what they build gets tested. They won't be able to lie much, because the difference between "we test it by hand before deploying" and "there are automated tests" is huge.
Neither one is inherently wrong: a small, stable project can live with manual testing. But if they tell you there are automated tests, ask to see them run. It takes a minute and tells you a lot.
4. "Where's my data, and who can see it?"
Especially if you handle customer data.
Ask where the database lives, who has access, how often there are backups, and — this is the key one — whether they've ever tested restoring one. A backup that's never been restored isn't a backup: it's a folder.
It's a simple question, and the look on their face already tells you plenty.
5. "What happens when something breaks on a Sunday?"
All software fails. What sets a vendor apart isn't promising it won't happen, it's having a clear answer for what happens when it does.
Do they find out on their own, or do I find out from an angry customer? Is there someone available? How fast? If the answer is "message us on WhatsApp and we'll take a look," that's fine, as long as you know it upfront and it matches what you're paying for.
6. "Why this, and not that?"
Ask why they chose the technologies they chose. Not to judge the technical answer, but to hear whether there's a reason at all.
A good answer mentions your case: the volume you expect, the team that will maintain it, what you already have running. A bad answer only mentions the technology: that it's modern, that it's fast, that it's what's popular.
If they picked something because they like it and not because it serves you, that's going to repeat itself in every decision of the project.
The most reliable signal
After enough years, the signal that works best isn't any of the above: it's whether they ever tell you no.
A vendor who answers "yes, that's possible" to everything you ask is telling you what you want to hear. One who sometimes says "that's possible but not a good idea, and here's why" is thinking about your problem, not the invoice.
Same with timelines. The one who promises half the time everyone else quotes isn't faster: they just haven't thought the problem through yet.
If you're about to start a project and want a second opinion on what's being proposed to you, write to us. Sometimes the best advice we give is not to do it.
