Short answer: the questions that protect a small business are not about whether the developer can code. They are about how the engagement will run: what is in scope, how you will see progress, who owns what, and what happens after launch. Below are the twelve I would want a client to ask me, and the one-page brief that makes the answers useful.
Why skill questions are not enough
Every list of "interview questions for freelance developers" asks about languages, experience and communication. Fine, but a skilled developer with a vague scope still delivers the wrong thing, late. The failures I have seen on small projects were almost never technical. They were scope that drifted, milestones that were never defined, staging links that never existed, and handovers that never happened.
Scope
1. "Will you write the scope down before quoting, and what will it contain?" You want a written brief with the user types, the main flows, what is explicitly out of scope, and acceptance criteria per milestone. If the quote arrives before the scope, the quote is a guess.
2. "What would you leave out of version one?" A good developer has an opinion about what to cut. If the answer is "nothing, we can do it all", you are talking to someone who has not scoped many projects.
3. "What is the expensive part of my project, and is there a cheaper version of it?" This question separates people who have built similar things from people who have not.
Money
4. "Fixed price per milestone, or hourly? Why?" Fixed price per milestone with written acceptance criteria protects both sides on a defined build. Hourly fits open-ended support or research. Be wary of hourly for a defined build with no cap. More on this below.
5. "What is the payment schedule and what triggers each payment?" Payments should follow accepted milestones, not calendar dates.
6. "Which costs are mine and recurring?" Hosting, database, messaging per message, payment fees, domains, third-party APIs. Ask for them as a separate list.
Build
7. "How will I see progress?" The answer should include a live staging link you can open any day, and a regular demo. "I will send screenshots" is not the same thing.
8. "How will you test, and against what data?" Against your real data, not samples, with every acceptance criterion checked. On the Dashcam Library build, every criterion was tested on the client's own footage before handover (/work/dashcam-library).
9. "What happens when I ask for a change mid-build?" Changes happen. You want a process: write it down, estimate it, agree whether it replaces something or adds to the price, then do it.
Ownership
10. "Who owns the code, the accounts and the data, and from when?" The repository, the hosting account, the database, the domain and every third-party account should be in your name from day one, with the developer added as a collaborator. Not the other way round.
11. "What does handover include?" A written handover document, a walkthrough call, environment variables and secrets transferred securely, and access removed for the developer when you choose.
After launch
12. "What support exists after launch, and what does it cost?" A defined period of bug fixes included, then an optional retainer with a response time. Ask what counts as a bug versus a change.
Fixed price vs hourly
| Situation | Better fit | Why |
|---|---|---|
| Defined build with a written scope | Fixed price per milestone | Both sides know what "done" means and what it costs |
| Ongoing support or small changes | Hourly or a monthly retainer | The work cannot be scoped in advance |
| Research or a prototype to learn from | Capped hourly | You pay for time, with a ceiling |
| Migration of a live product | Fixed price per milestone with a parity list | The existing app defines the scope (see /work/clinical-stack) |
The one-page brief to bring to the first call
You do not need a specification. You need one page that lets a developer ask good questions.
- The problem in one sentence. "Our three clinics build rotas in spreadsheets and chase cover in a group chat."
- Who uses it. List the user types and how many of each. "Two admins, forty staff, one owner."
- The three things it must do. Not features, outcomes. "Publish a valid rota in under an hour. Fill a sick call without the manager phoning anyone. Give me hour totals at month end."
- The rules you already know. "No one over 40 hours. Procedure rooms need a credentialed nurse."
- What it must talk to. Payments, messaging, calendars, accounting.
- What is out of scope for now. "Patient booking. A native app."
- Timing and budget band. A deadline if there is one, and a range you are comfortable with. Developers scope to the band; hiding it wastes everyone's first week.
- How you will judge success. "Managers stop using the spreadsheet within a month."
Bring this page and the twelve questions, and the first call becomes a scoping session rather than a sales pitch.
Red flags
- A quote before a written scope.
- No staging link, ever.
- Accounts in the developer's name.
- "Trust me" instead of acceptance criteria.
- A refusal to say what they would cut.
Want to see the answers before you ask?
My answers to all twelve are written down at /how-i-work. If you have a one-page brief, send it through /contact and I will reply with what I would scope first and what I would leave out of version one.