12 Questions to Ask Before Hiring a Software Developer

Hiring a software developer feels impossible when you can't evaluate the actual work. You're trusting someone with a lot of money on a thing you can't inspect. But here's the good news: you don't need to read code to hire well. You need to ask the right questions and pay close attention to how they answer. A developer who explains things clearly, pushes back honestly, and puts the important stuff in writing is showing you exactly how the whole project will go.

Here are the twelve questions worth asking, grouped by what they protect. Under the ones that matter most, we've added what a good answer actually sounds like, so you can tell a real one from a rehearsed one.

Questions about ownership and lock-in

1. 1Who owns the code when it's finished? The answer you want is 'you do.' In US law, absent a written assignment, the developer can retain ownership of what they build, so this must be spelled out in the contract, not just promised.
2. 2Do I get the source code and all the accounts? You want everything: source code, hosting, domain, and every login in your name. If any critical piece stays under their account, you're not really the owner.
3. 3If I leave, can another developer take over cleanly? A good answer describes documentation and a normal handoff. A bad one makes it sound difficult, which is often the point.

Questions about price and scope

1. 1How do you price, fixed or hourly, and why? Either can be honest. What matters is that they explain it and you understand what you're on the hook for.
2. 2What happens when I want to change something mid-project? You want a clear change-order process, not a shrug. Scope will change. How they handle it is what separates a partner from a surprise invoice.
3. 3What's NOT included in this quote? The most useful question on the list. Good developers will happily name the boundaries. Vague ones leave the gaps for later billing.
4. 4Can you break this into phases so I can spend less to start? A developer who's on your side will often suggest building the core first and seeing if you even need the rest.

Questions about the work and the people

1. 1Can I talk to two past clients? Then actually call them. Ask about budget, communication, and whether they'd hire again.
2. 2Who's actually doing the work, and will that person change? Especially with larger firms, make sure the people you meet are the people who build.
3. 3How often will I hear from you, and how? Set the communication expectation now. Slow replies during sales predict slow replies later.
4. 4Who fixes it after launch, and what does that cost? Software isn't done at launch. Get the maintenance answer before you're depending on them.
5. 5What's the most likely way this project goes wrong? The best question of all. A seasoned developer will answer honestly, because they've seen it. Someone who says 'nothing will go wrong' hasn't shipped much.

That last one is a quiet lie detector. Real answers sound like: "Scope creep is the usual culprit, so we'll agree on what version one is and hold the line," or "The risk is your data being messier than expected, so we'll look at it early." Honest people name real risks. For more on the warning signs to watch across all of this, see software developer red flags before you hire.

How to actually use these

You don't need all twelve in one sitting, and you don't need to interrogate anyone. Work them into the conversation naturally and pay attention to the texture of the answers. Are they clear or evasive? Do they add friction that protects you, or agree to everything to close the deal? Do they put the ownership and price answers in writing without you having to push? That pattern tells you more than any line of code could.

How we like to be asked these

We're a Seattle-area studio, and we'd genuinely rather you ask us all twelve. Our answers don't change: after a scoping call we quote a fixed price, you own all the code and data outright, changes get priced and approved before we build them, and we'll happily point you to an off-the-shelf tool if it does the job cheaper than a custom build. That's how we run every custom software and AI project. If a developer gets cagey when you ask these questions, that reluctance is your answer, whether it's us or anyone else.