Questions to ask a developer before hiring them, and what to listen for

Before hiring a developer, five questions tell you the most: what similar work they've done and whether you can open it, how you'll see progress, what happens when you want changes, what ends up in your name and what happens after launch. The answer matters, but so does how they give it.

I covered the general criteria (portfolio, clear communication, realistic timelines, red flags) in how to choose a web developer. This piece is the practical version: the actual questions to bring to the first call, and what to listen for in each answer.

About their past work

• “Can you show me something similar that's live right now?” Ideally a link you can open on your phone, not a screenshot. If there's nothing from your industry, ask for something that solved a similar problem and how it relates.
• “Which part of that project did you do?” It's a fair question. A clear, specific answer builds far more trust than a vague one.
• “What was the hardest part?” Someone who really built it has a story to tell. Someone who didn't stays general.
• “Is the client still using it today?” A delivered project and a project that works day to day aren't the same thing.

About how the project will run

• “How often will I see progress, and in what form?” A good answer includes something you can open and click around in, not just status updates. I send progress as a link you can check on your phone, for example.
• “Who's actually doing the work?” If you're hiring one person, ask whether anyone else is involved. If you're hiring a team, ask who your day-to-day contact will be.
• “How do we stay in touch, and during what hours?” WhatsApp, email, video calls: any channel works as long as it's agreed up front. If you're in another time zone, ask about overlap.
• “What do you need from me, and when?” Copy, photos, logins, approvals. Plenty of projects stall waiting on something the client didn't know they had to send.

About changes, ownership and life after launch

• “What happens if I see it and want to change something?” It's reasonable to have some revisions included, and to know what counts as a new request.
• “Whose name will the domain, accounts and data be under?” The reassuring answer is “yours.” I go deeper in who owns your website code.
• “If something breaks after launch, what happens?” Find out whether there's a period of included fixes and what comes after it.
• “What would maintenance cover, if I need it?” Not every project needs the same; what website maintenance includes breaks down what's in and what isn't.
• “What happens if we stop working together someday?” Awkward, but worth asking. The answer tells you whether someone else could pick it up without starting over.

The questions they should be asking you

Pay as much attention to what a developer asks as to what they answer. Someone who understands business wants to know how you work today, who your customers are, what costs you time or sales and how you'll know the project worked. They also ask what you already have, so they don't rebuild something that's fine.

If the whole call goes by without a single question about your business, straight into screens and features, you might end up with something polished that doesn't fix what you needed. I made the same point for a different industry in what to look for in a 3D walkthrough demo: what matters is whether the tool answers your buyer's questions.

Using this list without turning it into an interrogation

You don't need to ask everything on the first call. Pick the four or five that worry you most and save the rest for when the written proposal arrives, since many get answered there. If you're talking to more than one developer, ask everyone the same questions; how to request a software quote explains how to compare afterward.

And write the answers down. It sounds obvious, but a week later every call blurs together.

Frequently asked questions