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 — and who keeps it running?
There are two honest models. In one, the developer hands you the source code once it's paid for: you own it — and you also own the hosting, the security patches, and finding someone to maintain it. In the other, the developer keeps ownership, licenses it to you, and keeps it running: hosting, fixes, and security updates are their job while you're a client.
Neither is a trick. Owning means more independence and more chores; licensing hands the chores to the builder for a monthly fee. Either way, your data should stay yours.
A good answer: which model they use, what the monthly cost covers (or what you'll cover yourself), and written terms for getting your data back.
2. Fixed price or hourly?
Either can be fair; what matters is who carries the risk. Hourly billing with no estimate and no written approval before work starts puts it all on you — especially if 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 written quote before work starts, bug fixes on their dime, and a plain-English process for changes — estimated, then approved by you in writing before they're billed.
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: either a monthly fee that covers hosting, security updates, and bug fixes, or a defined warranty window for bugs followed by 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: changes written up, priced or estimated, and approved by you in writing 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 — where it's hosted, encrypted storage, access limited to the people who need it, and a plain statement that the data is yours, not theirs.
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: a notice period in writing, your data made available in a common format with a set window to take it, and transition help at a stated rate — no ransom fees.
One honest disclosure
We publish this list because we like how we score on it. For the record, on question one: we own and maintain the software and license it to you, with hosting, security updates, and bug fixes included. Your data is yours: when the agreement ends, it's made available to you in a common format, and you have 30 days to take 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?
Who owns the code, and who keeps it running. If you'll own it, you also own the hosting, the security patches, and the job of finding someone to maintain it. If the developer owns it and licenses it to you, keeping it running should be their job. Either way, your data should be yours, with the export terms in writing.
What are red flags when hiring a software developer?
Vague timelines, hourly billing with no estimate and no written approval before work starts, reluctance to share references, no written terms for getting your data back, 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.