All posts

Questions to Ask a Web Developer Before Hiring

By Erin Kerr ·

The short answer

Before you hire a web developer, ask to see live work you can open yourself, what the first step is before any code gets written, how often you will see progress, what happens when the scope changes, who owns what at the end, and who looks after it after launch. Get every answer in writing.

I've been on the building side of every product on this site, so I know which questions make a developer slow down and think, and which ones get a rehearsed answer. The lists that rank for this search mostly ask about experience, price, timeline and references. Those are fine, but they're easy to answer well without showing you anything. These are the ones I'd ask, with what a good answer sounds like and a way to check it.

Think of it like hiring someone to renovate your kitchen

You wouldn't hand over the keys because someone said "I've done lots of kitchens." You'd want to walk through one they finished, hear how the week will go, and know what happens when you open the wall and find something unexpected. Building a website or an app is the same, except you can't see the wall. So the questions below are all ways of making the work visible before you commit.

Eight questions, and what a good answer sounds like

1. Can I open something you've built?

A good answer is a link or an App Store listing you can use right now, not a screenshot. When you open it, try it on your phone, and ask what the developer did on it versus what someone else did.

That's the standard I hold us to. You can open the iPhone apps I shipped, Gin Score Tracker, Hearts Score Tracker and Desk Yoga, and the web app Group Sing Along, without asking me for anything. Every one of those is my own product, not a client job, and I'd rather say that than let you assume otherwise. A developer who shows you their own work and tells you plainly whose it is has told you something useful already.

2. What happens before you write any code?

A good answer describes a step where they ask about your goals, your users and your limits, and end up with something written down. If the first thing you hear is a price or a start date, nobody has scoped anything yet.

Ours is the first step on the Cyber Goose process: we start by understanding your goals, users and constraints, and you get a scoped brief before a single line of code is written.

3. Will I approve the plan before you build?

A good answer is yes, and you can see what you're approving: wireframes, the main decisions and a clear timeline. It should be a document or a design you can read, not a call where you nod along.

Our second step works this way: wireframes, architecture decisions and a timeline, and you approve the plan before we build anything.

4. How often will I see progress?

A good answer is a regular rhythm, with something you can click each time. "We'll keep you posted" is not a rhythm. If you only see the site at the end, you find out about misunderstandings at the end.

We build iteratively, with weekly demos.

5. What happens when I change my mind halfway through?

Everyone changes their mind, so this is really a question about how the developer handles it. A good answer explains how a change is written down, what it touches, and whether it moves the plan you approved. A bad answer is "no problem" with no process behind it.

6. Who owns the site, the domain and the code at the end?

Ask this one directly and ask for the answer in writing. A good answer names who holds the domain registration, the hosting account, the design files and the code, and says what you'll be handed. If the answer is vague now, it will be harder to sort out later.

I'm not going to tell you any particular studio's policy here, ours included, because that belongs in your agreement and not in a blog post. Get it written before you sign.

7. What does launch day look like, and what comes after?

A good answer covers more than flipping the switch. Who deploys it, who watches it afterwards, and who you contact when something breaks on a Tuesday night. The last step of our process is exactly this: deployment, monitoring and ongoing support.

If it's an iPhone app, ask about the App Store side too. The developer should be able to tell you what the account costs and who holds it. Apple lists the Developer Program at $99 a year, and App Store Connect requires a support URL that leads to real contact information, so someone has to build and host that page too. If you're still deciding between the two, I wrote about whether to build an app or a website first.

8. Who will actually do the work?

A good answer tells you who designs and who builds, and whether that's the same person or a handoff between people. Many projects need both skills, so ask how the two fit together. Cyber Goose does design and development under one roof, and each case study shows the palette and typography next to the stack so you can see the two working together.

How to check the answers

You don't have to be technical to check any of this:

  1. Open the work they showed you on your own phone.
  2. Ask for the scope, the plan and the ownership answers in an email, so you have them in writing.
  3. Ask what the first demo will look like and when you'll see it.
  4. Compare two developers on the same questions, not on the quote alone.

What about price and timeline?

The top results for this search all tell you to ask about both, and that's good advice. I'm leaving numbers out on purpose, though. Any figure I gave you would be a guess about a project I haven't scoped. The honest way to get a number is the scoped brief from question 2, and a developer who quotes before that is guessing too.

Questions people ask

Should I ask a web developer for references?

It doesn't hurt, but a live product you can open and use tells you more than a phone call with someone chosen for you. If they have both, ask for both.

What are red flags when hiring a web developer?

A price before any questions about your goals, work you can't open, no written scope, no plan you get to approve, and vague answers about ownership. Any one of those is worth a follow-up question before you sign.

Do I need to know how websites are built to hire someone?

No. You need to know what the thing has to do and who it's for, and a good developer will help you write that down. If you can describe it to a friend, you can start.

If you're about to hire someone and want a second pair of eyes on the questions, or you'd like us to be one of the studios you ask, send a note to hello@cybergoose.org with what you want built and who it's for. You can read more about how we work on the Cyber Goose homepage.

Let's work together.

hello@cybergoose.org