What to Ask a Web Developer Before You Hire Them
AI-assisted writing with some human love from Madison, MS. Trust me, it’s a lot more readable that way. :-)
Before you hire someone to build your website, ask what you’ll be able to do with it when the work is finished. Can customers reach you? Can you change your own information? Can another developer take over if you need them to?
A small-business Reddit discussion about questions to ask before paying for a website prompted this guide. One developer’s reply covered ownership, ongoing costs, revisions, content, and support. Those are useful starting points. Here’s how I’d turn them into a conversation with someone you’re considering hiring.
Download the web developer hiring checklist (PDF). The four-page worksheet includes extra checks for replacing an existing site and keeping control of subscriptions. Print one copy per developer and keep their answers beside the proposal.
1. Who controls the accounts, and can I move the site?
Your business should control its domain account, including the email used to recover access. The domain is your website’s address. Give the developer their own access instead of sharing your password.
Hosting can be in your account or part of a managed service. Either way, ask what happens when you leave. Will you receive the pages, images, database, and code needed to run the site elsewhere? Which paid tools or images need a new license? What does the transfer cost?
Ask them to describe an actual handover. Some website platforms let you export only part of a site. Knowing that before you buy helps you decide whether the convenience is worth the limits.
If you take payments or sell subscriptions, include those accounts in the conversation. Ask to see how you’ll issue a refund or cancel a recurring payment using safe test data. Agree on who handles the old billing system if you move the website.
2. What is included, and what will I pay after launch?
Ask for the costs in four groups: one-time work, monthly fees, annual renewals, and optional extras. Hosting, your domain, paid plugins, and maintenance can each have a separate bill. A plugin is an add-on that gives the site another feature.
Have the developer explain what stops working if you cancel a subscription. Also ask who receives renewal notices. You don’t want an important account tied to an inbox nobody checks.
A useful proposal lets you work out the first year’s cost and the next year’s cost. If a price can change, ask when you’ll hear about it.
3. What does “finished” mean?
Agree on the pages and the things a visitor must be able to do. “Five-page website” doesn’t tell you whether appointment booking or a quote form is included.
Write down who supplies the words and photos, who approves them, and when they’re due. Then define a revision round. For example, does one round mean one collected list of changes? What happens if you request a new page after approving the design?
Ask for a short acceptance list you can both check before launch. “A customer can request a quote on their phone, and I receive it” is something you can test.
Break the project into steps you can review: an approved design, a working preview, and the launch checks. Agree which payment is due at each step, how often you’ll get an update, and what happens if a deadline is missed or either side needs to stop. A deposit can be reasonable; the next payment should have a clear reason behind it.
4. Can you show me comparable work that still works?
Look at an older live site as well as the newest portfolio piece. Try finding a service and a phone number on your own phone. Ask what the developer actually did on that project.
With permission, speak to a past client. Ask what happened when they needed a change after launch. Was the cost clear? Could they get help? Did they receive the access they expected?
Browse those examples without sending test enquiries to someone else’s business. Save form testing for your own project and an agreed test inbox.
5. How will you prove my customers can use it?
Ask to watch the main customer journey on a phone and a computer. Can someone open the menu, understand the service, and take the next step?
Also try the keyboard, increase the text size, and check that forms have clear labels. When you press Tab, you should be able to see which link or button is selected. These checks help reveal barriers a screenshot won’t show.
For a contact form, send a clearly marked test and confirm it reaches the agreed inbox. A thank-you message alone doesn’t prove you received the enquiry.
6. What happens after launch when something breaks?
Get the support contact, working hours, and urgent-help process in writing. Ask what “response within one business day” means. A reply acknowledging the problem and a completed repair are different things.
Find out who handles updates, backups, and restoring the site. Ask how they check an update worked and whether they’ve tested restoring a backup.
If maintenance is optional, have them explain what becomes your responsibility without it. You need to know who will act when a form fails or the site goes offline.
7. Which changes can I make myself?
Ask for a demonstration using changes you’ll actually make: business hours, a service description, or your phone number. Then try it yourself.
A short recording gives you something to follow later. Ask for your own account with the access you need, and keep the developer’s account separate. Set up two-factor authentication where available; that adds a second sign-in check alongside your password.
If an edit needs the developer, ask how to request it and how it’s charged.
8. How will we know whether the site helps the business?
Choose a useful result to track, such as relevant enquiries or completed bookings. Visitor counts can provide context, but they don’t tell you whether the right people contacted you.
Agree on a starting point and a review date. Ask who can access the reports, how customer privacy is handled, and how your local business profile connects people to the site.
Discuss what the developer can measure and influence. Sales also depend on your offer, reputation, and follow-up. A website proposal shouldn’t leave you guessing which results it actually covers.
9. What stays working when the new site goes live?
If you already have a website, ask for a written move plan. List the important existing page addresses and where each will lead on the new site. A redirect forwards an old address to its replacement, so an existing link can still take someone to the right page.
Ask who checks those links, business email, forms, bookings, and payments after the switch. Keep an accessible backup and agree when the old hosting can be closed. Record enquiries and search traffic before the move, then set a follow-up date to compare them. Google’s site-move guidance recommends mapping old addresses to new ones, testing the move, and monitoring traffic. Rankings can fluctuate during a move; nobody should promise otherwise.
Before you pay a deposit
Keep the written answers with the proposal. Mark anything that still needs a decision, especially ongoing costs, account access, the launch checklist, and support.
You don’t need to understand every technical detail. You do need answers clear enough to explain what you’re buying and who does what next.
What can go wrong without a clear plan?
These are public Reddit accounts, including one from someone helping a client. I haven’t independently verified their claims. They show why it’s worth asking specific questions before you hand over money or access.
You’ve paid, but the launch date passes without a finished site
One owner reported paying $1,000 toward a website with a December 12, 2022 launch date. They said the first draft didn’t arrive until January and the design still wasn’t what they wanted. In a follow-up, they decided to keep working with the agency to finish it.
Ask to approve the design before the rest of the build, and connect payments to work you can review. Put update dates and the process for delays or cancellation in writing. A final deadline alone doesn’t tell you whether the project is on track.
A small change turns into weeks of chasing someone
Another owner described repeated promises to add a tracking tag, software used to measure visits. They said weeks passed, a promised call never came, and a request for a quote on two extra pages went unanswered.
Ask how support requests are handled and what happens when the developer is unavailable. Make sure another person could get the access and files needed to help. Having to start over shouldn’t be your only way to get a small change made.
The new address goes live, but the enquiries stop
A business owner reported losing search traffic and Google enquiries after changing their domain and business name. The business had been running for ten years. The poster wasn’t sure whether the address change, changes to the homepage, or something else explained the loss.
That thread doesn’t establish the technical cause. The useful question is how your developer will protect and check the things that already work. Get the old-to-new page list, a backup, and a plan to compare enquiries after launch. A new design isn’t the whole job when you’re replacing a working site.
You leave the old site, but its subscriptions keep charging
In a more serious account, someone helping a client reported that access to an old site had been revoked. The business moved its domain to a new site, but the poster said subscriptions on the old site kept charging customers. They described making refunds by bank transfer because the client couldn’t manage them through the old account.
Ask who can cancel subscriptions, issue refunds, and close out old billing before you sell anything. Include those steps in a move plan. Keep access to the records you need, and use the payment provider’s supported process for any transfer. Don’t assume moving the website also settles every service connected to it.
Planning can’t prevent every bad experience. Clear checkpoints, usable account access, and a way to hand the work over give you more options when something goes wrong.
Download the web developer hiring checklist (PDF) to record those answers. If you’re considering my WordPress website services, bring the same questions to me.