Short version: the ten questions below protect the four things buyers get burned on when hiring a developer — ownership, money, support, and the exit. Ask all ten before you sign anything, and listen for specifics. Vague answers to precise questions are the oldest warning sign in this business.
Hiring a developer is a trust purchase. You can't inspect code the way you'd inspect a kitchen remodel, so the interview is the inspection. Here's what to ask, why it matters, and what a good answer sounds like.
1. Who owns the code?
Some shops keep ownership and license the software back to you — meaning you're renting your own product. If you ever want to switch developers, extend the system, or sell your business, you'll be negotiating for something you already paid for.
A good answer: "You do. Source code, hosting, domain — everything transfers on final payment, and it's written into the contract."
2. Fixed price or hourly?
Hourly billing puts the project risk on you: an estimate isn't a price, and the meter keeps running while the developer fixes their own bugs. Whatever number you're quoted, sanity-check it against our cost breakdown.
A good answer: a fixed number tied to a written scope, with a plain-English process for changes.
3. What happens after launch?
Software needs a home after launch day — bug fixes, security updates, hosting, small tweaks. If your developer hasn't thought past the ribbon-cutting, congratulations: you're the maintenance plan. What good support looks like is covered in our guide to software maintenance after launch.
A good answer: a defined warranty window for bugs, then a clear ongoing option with a price on it.
4. Can I talk to a past client?
A portfolio shows the launch-day photos. A past client tells you what months two through six were like — response times, surprise invoices, how problems actually got handled. Five minutes on the phone beats fifty screenshots.
A good answer: "Sure, here are two." Hesitation is also an answer.
5. Who actually does the work?
At plenty of agencies, the person who wins your business never touches your project — it goes to whoever's available, sometimes on another continent. That's not automatically bad, but you deserve to know who you're really hiring.
A good answer: named humans. If anything is subcontracted, they volunteer it and explain who checks the work.
6. What's your typical timeline?
"It depends" usually translates to "we're overbooked" or "we're guessing." Modern builds are measured in weeks, not quarters — see how long custom software takes in 2026 — so a competent shop can commit to a range.
A good answer: a specific range with milestones, plus the one or two things that could move it.
7. What do you need from me?
Projects don't only stall on the developer's side — they stall waiting on your logo, your decisions, your feedback. A builder who says "nothing, we've got it" isn't planning to check in until it's too late to steer.
A good answer: a short list — decisions up front, examples of what you like, feedback within a few days at set checkpoints.
8. What if I want changes mid-project?
You will want changes. Everyone does once real screens appear. Change handling is where budgets blow up and relationships turn frosty, so learn the process before you're inside it.
A good answer: small tweaks absorbed, genuine scope changes written up and priced before they're built — never discovered on an invoice.
9. How do you handle my data?
Your customer list, quotes, and payment records will live inside this system. You want to know where they're stored, who can see them, and what protects them if a laptop walks off a job site.
A good answer: specifics — accounts in your name, encrypted storage, access limited to the people who need it.
10. What happens if we part ways?
Exit terms are where lock-in hides. Some shops make leaving so painful that staying becomes the product. Oddly, the developers who make leaving easy are the ones you'll actually want to stay with.
A good answer: you keep everything you've paid for, handoff notes included, no ransom fees — question one's answer, holding up under pressure.
One honest disclosure
We publish this list because we like how we score on it. Revenant answers all ten in writing before you commit a dollar — and any developer worth hiring will happily do the same. The point isn't to hire us; it's to make whoever you hire show their work.
Frequently asked questions
What is the most important question to ask a software developer?
Ownership. If you don't own the code, accounts, and data outright on final payment, every other answer matters less — you can't switch developers, and you're effectively renting your own product.
What are red flags when hiring a software developer?
Vague timelines, hourly billing with no cap, reluctance to share references, hosting and accounts kept in the developer's name, and no written process for changes. Any one is a caution; two or more is a pattern.
Do these questions apply to freelancers and agencies both?
Yes. Freelancers and agencies tend to fail differently — freelancers vanish, agencies bury you in process and invoices — but the same ten questions expose both. Good answers sound the same at any size.
