Skip to content
Question Vault?
Free to readNo accountNo email wallNo invented statisticsNo partial listsCopy or print any set and take it with you

Questions to Ask a Web Developer

For a small business owner, a nonprofit or anyone else about to pay a freelancer or an agency to build or rebuild a website. The questions follow the order the decision usually takes: their past work, how the site will be built and whether you can edit it yourself, what the quote covers, the timeline, who owns the domain, the code and the logins, and what happens after launch. Each has a note on what a good or a worrying answer sounds like and what to do with it.

51 questions

Want questions from the whole vault instead? Try the random question generator.

The questions

Each question, and why to ask it

Past work

Can you show me three websites you built that are live right now?

Why ask it

Open each one on your phone while you talk, because many of your own visitors will arrive that way. A good sign is a developer who sends links at once and says what each business asked for. Be wary of a portfolio that is all mockups, or of sites that have since been rebuilt by someone else.

Which parts of the sites in your portfolio did you do yourself: the design, the build or the writing?

Why ask it

A finished site can be the work of four people or of one person and a bought theme. Neither is a problem, but you need to know which of those skills you are hiring. The design you admired may have come from an outside designer, in which case find out whether that person would work on yours.

Have you built a site that had to do the same job as mine?

Why ask it

The job matters more than the industry: taking bookings, selling a few products, collecting donations, getting the phone to ring. Someone who has done it before will bring up the awkward parts without being prompted. A first-timer is not ruled out, but find out what they would have to learn and who pays for the learning.

Can I speak to two past clients, including one whose site has been live for more than a year?

Why ask it

A client from last month can only tell you about the build. One from a year or more ago can tell you whether emails still get answered, what the upkeep really costs and whether anything broke. Ask that client what they would do differently if they were hiring again.

Who will actually build my site, and who will I be talking to from week to week?

Why ask it

With a freelancer the answer is usually one person. With an agency, the person in the sales meeting may hand you to a project manager and a developer you never meet. Either can work, but you should be told plainly if part of the job is passed to someone outside the firm.

What would you change first about the site I have now, and what would you keep?

Why ask it

For a rebuild only. It shows whether they looked at your site before the call and whether they can tell what is already working. Someone who wants to throw everything out, including the pages that bring in customers, is selling a fresh start more than solving your problem.

The build

Which platform would you build this on, and why is it the right one for my business?

Why ask it

WordPress, Shopify, Squarespace, Wix, Webflow and hand-written code all suit different sites. A good answer starts from what you told them: how often you will update it, whether you sell online, what you can spend each year. If the only reason given is that it is the one they always use, ask what it does badly.

Once the site is live, can I change text, swap a photo and add a page without calling you?

Why ask it

Have them open the editing screen of a site they built and change a sentence while you watch. If it looks like filling in a form, you will manage it. If every edit has to go through them, find out what each one costs and how long it waits.

Is this a design made for me, or a template you will adapt?

Why ask it

Both are legitimate, and an adapted template is often the sensible choice on a small budget. The price should match, though: a quote for custom design that turns out to be a purchased theme with your logo on it is a bad deal. Ask to see the template before it is changed, so you know what you are paying to have altered.

How will the site work on a phone, and when do I get to see that version?

Why ask it

You want to hear that the phone layout is designed alongside the desktop one and that you will review both. A worrying answer treats mobile as something the theme takes care of. Ask to see the menu, a form and the checkout or booking step on a small screen before you approve anything.

If I want to add a shop, online booking or a members area later, can this site take it?

Why ask it

Name the one addition you think is likely, not every one you can imagine. A useful answer says which additions the platform handles with a plugin or a plan upgrade and which would mean rebuilding, with a rough idea of the cost. Paying now for features you may never use is a waste, and so is a platform that rules out the one you are fairly sure of.

What do you do for search engines as part of the build?

Why ask it

Listen for the basics that belong to any build: a clear title and description for every page, sensible headings, descriptions on images, a sitemap, and a search console account opened in your name. Nobody controls where a site ranks, so treat a promise of a first-page position as a reason to keep looking.

If this replaces an old site, what happens to the old page addresses?

Why ask it

Pages that move without a forwarding address leave old links and search listings pointing at nothing. A careful developer lists the old addresses and points each one at its new page, which is called a redirect. A puzzled look means you raise it again before launch, because the job is much easier on the day than a month later.

How do you make the site usable for someone with a screen reader, or someone who cannot use a mouse?

Why ask it

Good answers are specific: readable color contrast, descriptions on images, labels on form fields, a site you can move through with the keyboard alone, and often a named standard such as WCAG. A widget bolted on at the end is not the same as building it in. Whether a legal standard applies to you depends on where you are and what kind of organization you run, so ask how it works there and confirm it with someone qualified.

How fast will the pages load, and how do you test that?

Why ask it

Have them run a speed test on one of their finished sites while you watch, then try that site yourself on mobile data, away from the office wifi. Listen for talk of image sizes and of keeping add-ons to a minimum. A developer who has never tried their own work on an ordinary phone will be finding out along with your customers.

Which plugins, apps or outside services will the site rely on, and which ones charge a fee?

Why ask it

Booking tools, form builders, payment providers, email services and premium plugins often bill monthly or yearly, and the bill may go to the developer's card or to yours. Get the list in writing with a price beside each. A long list is also a list of things that will need updating.

What do you set up for the privacy notice, cookie consent and any terms pages?

Why ask it

The rules on these depend on where you trade and where your visitors live, and a developer is not the person to tell you what the law requires. A sound answer covers what they will build, such as the pages and a consent banner if one is needed, and says the wording has to come from you or your adviser. Be careful with anyone who says none of it applies to a small site.

The quote

What exactly does the quote cover, page by page and feature by feature?

Why ask it

A quote that says 'five-page website' can mean five designed pages or one layout repeated five times. Ask for the pages by name, plus every feature you mentioned: the form, the gallery, the booking calendar, the map. Whatever is not written down is a future argument about whether it was included.

Who writes the words and supplies the photos?

Why ask it

Many developers expect finished text and images from the client, and many clients assume the developer will handle it. Settle it now. When the writing is yours to do, a page-by-page list with rough word counts shows how big the job is before you agree to it.

What will I still have to pay for that is not in this quote?

Why ask it

Common extras are the domain, hosting, stock photos, a paid theme or plugins, copywriting, a logo and setting up business email. A developer who lists them without being pushed is doing you a favor. If the answer is 'nothing', read the list back one item at a time and see whether it holds.

Is this one fixed price, or will you bill for the hours it takes?

Why ask it

A fixed price protects your budget, but only for the scope as written, so ask what happens when the scope grows. Hourly billing is flexible and can drift: ask for an estimate, a ceiling they will not pass without checking with you, and the hours listed on every invoice.

What is the payment schedule, and what does each payment depend on?

Why ask it

A deposit to start is common. After that, look for payments tied to things you can see, such as an approved design or a working test site, with the last one due at launch or handover. Paying the whole amount before any work exists leaves you with no leverage if the project stalls.

If I think of something new halfway through, how is it priced and approved?

Why ask it

You will think of something. The good version is a short written note saying what the change is, what it costs and what it does to the date, which you approve before any work starts. Additions that are simply done and billed later turn the final invoice into a surprise.

What will this site cost me each year once it is built?

Why ask it

Add up hosting, the domain renewal, licenses, any care plan and a guess at small changes. The build is paid once and this number is paid for as long as the site exists, so it belongs next to the quote when you compare developers. Prices change with the provider, so ask which figures are fixed and which are only today's rates.

Will there be a written agreement, and can I read it before I pay a deposit?

Why ask it

Look for the scope, the price, the dates, who owns what, and what happens if either side walks away. An emailed quote that you accept in writing can serve for a small job, as long as those points are in it. Have someone qualified read any term that matters a great deal to you, because what a clause means depends on where you are.

Timeline

When would the site go live, and what are the stages between now and then?

Why ask it

A date alone is a hope. Ask for the stages, such as content gathered, design approved, build finished and testing done, with a rough date on each. Then the first slipped stage tells you early that the launch date is moving.

How soon could you start, and how many other sites will you be building at the same time?

Why ask it

A wait is not a mark against them, since a developer in demand is usually booked ahead. What you need is a real start date and a plain account of how your site would share the week with the others. Find out whether the deposit holds your place, and use any wait to get your text and photos together.

What will you be waiting on me for, and by which dates?

Why ask it

Text, photos, logo files, logins and decisions all come from you, and a developer who has been through this will hand you a list with deadlines. Put those dates in your own calendar. Find out too what happens to the schedule if you are a week late, since some developers move on to the next client and come back when they can.

How many rounds of revisions are included, and what counts as a round?

Why ask it

Quotes often cap the rounds at the design stage, and the number matters less than the definition. One round should mean all your comments gathered and sent together, not each separate email. Knowing what an extra round costs lets you decide whether a late change is worth it.

At what points do I see the work and sign it off?

Why ask it

You should approve the design before it is built, and see the built site at a private test address before it replaces anything. Moving things around in a mockup is quick, and doing it after the build is paid work. If the first thing you would see is the finished site, ask for an earlier checkpoint.

How often will I hear from you during the build, and where: email, calls or a shared board?

Why ask it

A weekly note saying what was done, what comes next and what they need from you is plenty for a small site. Agree on one place for requests as well, because changes scattered across texts, emails and voicemail are the ones that get missed. How quickly and clearly they have replied to you so far is the pace you are signing up for.

What usually makes your projects run late?

Why ask it

Expect to hear 'waiting for content', and accept it, because it is often true. The better answers also own something on their side: an underestimate, a plugin that misbehaved, too many projects at once. A developer for whom lateness is always the client's doing will say the same about you.

If I have to be live by a fixed date, what would have to go right to make it?

Why ask it

Name your date and the reason for it, whether that is a trade show, a season or a lease. You are listening for conditions: content by this day, one round of changes, no new features. An easy yes with nothing attached is less reassuring than a careful maybe.

Who tests the site before launch, and what gets tested?

Why ask it

A real answer is a checklist: every link, every form sent and received, the main browsers, a couple of phones, the page a visitor gets for a broken link, the spelling. Ask to be sent it. Plan an hour to click through everything yourself as well, since nobody knows your prices and opening hours as well as you do.

What happens on launch day, and will my email keep working?

Why ask it

Pointing a domain at a new site can interrupt email that runs on the same domain if the mail settings are not carried across. Someone who has done this often will mention checking those settings first and choosing a quiet time of day. Ask how long the changeover takes and who is on hand if something looks wrong that evening.

Ownership

Whose name and account will the domain be registered under?

Why ask it

The answer you want is 'yours'. The domain is the address every customer, email and printed card points to, and whoever holds the registrar account controls it. If the developer offers to register it for you, have them do it inside an account you open and pay for, with their access added to it.

Where will the site be hosted, and who holds that account?

Why ask it

Hosting in your own account means you can change developers without moving the site. Hosting resold by the developer can be perfectly good and often comes with support, but ask what it costs, what it includes, such as the security certificate and backups, and how you would get a full copy of the site out. Vague answers about where the site lives are a reason to slow down.

Will I have an administrator login to the site, the hosting, the domain and the analytics?

Why ask it

Ask for full administrator access, not an editor account that can change text and nothing else. Then keep the logins somewhere that does not depend on one person's memory. When one person holds the only master key 'to keep things safe', that person is also the only one who can open the door.

When someone fills in the contact form or pays online, where does the message or the money go?

Why ask it

Trace one inquiry from the button to your inbox. You should hear which address receives it, whether a copy is kept on the site in case the email fails, and whose name is on the payment account. A payment account in the developer's name means your sales pass through someone else first, so ask for it to be yours.

Once I have paid in full, what do I own outright and what is only licensed to me?

Why ask it

Your text, photos and logo should be yours without question. Themes, plugins, fonts and stock images are usually licensed, so ask whose name each license is in and whether it renews. How ownership of the design and code passes to you is set by the agreement and by local law, so ask to see the sentence that covers it.

If I moved to another developer in two years, could they take the site over as it is, and what would you hand them?

Why ask it

On a widely used platform the first half should be a plain yes, while a site on the developer's own in-house system, or on a page builder only they hold the license for, means starting over if you leave. For the second half, listen for a copy of the files and the database, the logins and the license details within a stated time. A fee for the transfer is reasonable when you know it in advance.

Will you put your own credit link in the footer or show my site in your portfolio?

Why ask it

A small 'site by' link is a common habit and plenty of owners do not mind it. It is still your site, so you can ask for it to be left off or kept discreet. The way they take a small request like this is a preview of how larger ones will be received.

After launch

If something breaks in the first weeks after launch, is fixing it included?

Why ask it

Many developers fix faults in their own work for a set period at no charge, and the length varies, so get the number of days. Ask how they tell a fault from a new request: a form that stops sending is a fault, and wanting another field on it is not. With no fix period at all, every problem starts with a quote.

Who keeps the platform, theme and plugins updated, and what does that cost?

Why ask it

Sites built on software such as WordPress need regular updates, while hosted builders handle more of that for you. Someone has to do it: a paid care plan, you after a lesson, or nobody, and a neglected site is the kind that gets broken into. Ask which of the three their quote assumes.

What do you do to keep the site from being hacked, and what happens if it is?

Why ask it

Concrete habits are what to listen for: a security certificate so the address shows https, a second login step for administrators, no more plugins than the job needs, and a clean backup to go back to. Nobody can promise that a site will never be broken into, so the second half counts as much: who cleans it up, how fast, and whether that is covered or billed by the hour.

How often is the site backed up, where are the copies kept, and when did you last restore one?

Why ask it

The third part is the test. Plenty of people set up backups and never check that one can be put back. You are hoping for automatic copies kept somewhere other than the server the site runs on, and a story about a restore that worked.

If the site goes down on a weekend, who do I contact and how soon would I hear back?

Why ask it

A solo developer cannot promise an answer at all hours and should not pretend to. What matters is that the limits are stated: the hours they cover, the fastest way to reach them, and whether the hosting company's own support can help in the meantime. Weigh the answer against what an afternoon offline would cost you.

What do you charge for small changes later, and how quickly are they done?

Why ask it

New opening hours, a staff photo, a price list: these come up every few months. Get the hourly rate, the smallest amount they bill and the usual wait. With the editing access you asked about earlier, most of these never need to reach the developer at all.

Will you teach me and my staff to use the site, and leave something written or recorded?

Why ask it

An hour of training on your own site, recorded so a future employee can watch it, is worth more than a generic manual. Check that it is in the quote. If the reply is that the site is 'very intuitive', ask to try an edit yourself during the meeting.

How will I be able to tell whether the site is bringing in business?

Why ask it

Before launch, agree on what counts: calls, forms sent, bookings, sales. Then find out how each one will be counted and whether the analytics account will be opened under your email. It is a good sign when the developer asks what a new customer is worth to you.

What happens to my site if you close the business, fall ill or take a full-time job?

Why ask it

Mostly a question for a freelancer, and a fair one to ask kindly. With your own logins, hosting and domain, the honest answer is that the site carries on and you find someone new. If the honest answer is that everything stops, go back to the ownership questions before you sign.

How to interview a web developer before you sign

Practical guidance for the conversation itself

Before the first call

Write down what the site has to do

One paragraph is enough: who visits, what you want them to do next, and what you need to change yourself each month. 'People find us, see the menu and book a table, and I update the specials on Fridays' gives a developer more to price than 'a modern, clean website'. Every question under The build is easier to judge once you have this.

Collect what you already hold

Find out where your domain is registered, where the current site is hosted and who has the logins. Many owners discover at this point that a former employee or a previous developer holds one of them. Sorting that out before you hire anyone is far simpler than doing it in the middle of a build.

Know your budget and your date

Decide the range you can spend on the build and, separately, what you can spend each year to keep the site running. Decide whether your launch date is fixed or only preferred. A developer can design to a number and a date. Without them, you get a quote for the site they would like to build.

Talk to more than one developer

Put the same questions to two or three developers, including at least one freelancer and one small agency if your budget allows both. The differences between their answers teach you more than any single answer does, especially on platform, yearly cost and who holds the accounts.

In the conversation

Ask to be shown

A web developer's work is on a screen, so most answers can be demonstrated. Ask to see a live site on a phone, the editing screen behind it, a test checklist, a sample quote. Whatever is shown is something they already do. Whatever is only described may be something they intend to do.

Ask for plain words

If an answer arrives full of terms you do not know, say so and ask for it again in ordinary language. Someone who can explain hosting or redirects to a client without impatience will also explain the invoice, the delay and the problem at launch. Someone who cannot is hard to work with for months.

Say your budget out loud

Owners often hide the number for fear the quote will rise to meet it. It often works the other way: the developer picks a platform and a scope that fit, and tells you what your budget will not buy. If a quote lands exactly on your figure with no explanation of what it covers, the questions under The quote will show whether it was priced or matched.

Do not skip Ownership because the call is going well

The questions about the domain, the hosting and the logins can feel like planning for a breakup with someone you have only just met. Ask them anyway, and say why: 'I ask everyone this so that I am never locked out of my own site.' A developer who works in the open will have the answers ready.

Change the emphasis for a freelancer or an agency

With a freelancer, spend longer on how much time they have, who covers when they are away and what happens if they stop. With an agency, spend longer on who does the work, who your contact is and what the monthly charges are after launch. The rest of the list applies to both.

Comparing the quotes

Line them up item by item

Put the quotes side by side and list what each includes: number of designed pages, who writes the content, rounds of revisions, phone layout, search basics, training, the fix period after launch. A lower total often turns out to be a shorter list. Ask the cheaper developer to price the missing lines before you decide.

Compare three years, not the build

Add the build price to three years of hosting, domain, licenses and upkeep for each quote. A site that costs less to build but carries a high monthly fee can cost more over that time than the one that looked expensive, and the reverse is true as well. Ask each developer to confirm the yearly figures so you are not guessing.

Weigh how they answered as well as what they said

You will be writing to this person for months, and probably years. Notice who replied when they said they would, who asked about your business before talking about design, and who was straightforward about limits. Those habits tend to carry into the project.

Check one reference properly

Call the client whose site has been live the longest. Ask whether the site launched on time, whether the final bill matched the quote, and whether they can update the site themselves today. Three short questions to a real client tell you more than a page of testimonials.

Before you sign

Get the answers in writing

Whatever you were told on the call about scope, revisions, dates and ownership should appear in the quote or the agreement. If it is missing, send a short email listing what you understood and ask them to confirm it. People forget what they said in a friendly first meeting, on both sides.

Check the names on the accounts

Before work starts, confirm that the domain, the hosting and the analytics will be opened in your name with your email address, and that you will be given administrator access to the site itself. It takes a few minutes at the start and can be very hard to untangle later.

Agree on what finished means

Decide together what has to be true for the final payment to be due: the site live on your domain, the forms tested, the old addresses redirected, the logins handed over, the training done. A short written list protects the developer from endless extra requests as much as it protects you from an unfinished site.

Know when to bring in someone else

A developer can tell you how a site is built, hosted and kept up. Questions about what a contract clause means, what your privacy notice has to say or whether an accessibility law applies to you depend on where you are, so take those to someone qualified there and give the developer the answer to build from.

More on this topic