Before You Hire a Web Developer: Questions That Protect Your Budget

A website quote can sound simple and still leave the most important things unsaid. The difference between a project that runs smoothly and one that quietly drains your budget is usually decided before any work starts — in the questions you ask first.

Hiring a web developer is an unusual purchase: you pay for something you cannot inspect until it exists. So most owners compare quotes by the one part that looks concrete — the final number. But two quotes for "a website" can describe very different amounts of work, very different ownership terms, and very different relationships once the site is live. The cheaper-looking quote is sometimes simply the one that says less.

You do not need technical knowledge to protect yourself. You need clear answers to a handful of plain questions, asked before you agree to anything — and, wherever possible, answered in writing. Here they are.

1. Scope: what exactly is included — and what is not?

Start with the most basic question of all: what, precisely, does this price cover? Ask for the list. Which pages? Which features? Is the contact form part of it? Who writes the text — you, or them? Who provides the images? Is setting up the domain and hosting included, or assumed to be your problem? Are the basics a visitor never sees — the site working properly on phones, pages set up so search engines can find them — part of the job or extras?

Then ask the mirror question: what is not included? The exclusions matter as much as the inclusions. A quote is not necessarily dishonest because it covers less — but you deserve to know that before comparing it with one that covers more. A useful follow-up: "If I ask for this later, is it included or extra?" Finally, ask what "done" looks like.

2. Ownership: who owns what when it is finished?

Owners often skip this section. It matters most later. When the project ends, what is yours, and where does it live?

• The domain. Registered in your name, on an account you control. It should never belong to someone else.
• The hosting and the site files. Whose account does the site live on? Will you receive the site itself — the files and access another developer would need if you ever chose to switch?
• The content. Your text, images, logo and brand files are your business assets. Confirm they are treated that way.
• The accounts around the site. Forms, analytics and the other services the site depends on — set up under your accounts, or the developer's?

A developer having admin access to help you is normal. That is different from the developer owning everything: if every door is registered in someone else's name, leaving one day becomes a negotiation instead of a decision. The healthy pattern is simple — things set up under your ownership, handed over properly, and help that continues because you want it, not because you are stuck.

3. Revisions: how do changes work?

Every website project involves changes. You will see the work and react to it — that is not a failure of planning, it is the process working. What matters is agreeing how changes are handled before they happen.

Ask how revisions fit into the work: when you give feedback, what happens next? What counts as a small revision, and what counts as new work? And the reverse: if the developer discovers midway that something is bigger than expected, how will that be raised with you? The answer you want is that surprises are discussed and agreed before extra work is done — so the first time you hear about a change is never on an invoice.

4. Communication: how does the work actually run?

A website is built through dozens of small exchanges, so ask how those will work. Who is your point of contact? How will progress be shared, and how will you know what stage things are at? What will the developer need from you — content, feedback, decisions — and what happens while the project waits on those things? Projects stall on unanswered feedback as often as on unfinished building. And ask the uncomfortable question while things are still friendly: if something goes wrong, or you disagree, how is that handled? A calm, specific answer tells you a lot.

5. After launch: fixes, updates and handover

Launch day is the middle of the story, not the end. Ask what happens next. If something breaks shortly after launch, who fixes it — and how do you both decide whether it is a fault to be put right or a new request? Who handles small updates afterwards: text changes, new images, an extra page? Will you be shown how to make simple changes yourself, with the logins and notes you would need? If you want ongoing help, what does that arrangement look like?

Listen for the handover. A developer who hands over a clear picture — where everything lives, which accounts matter, how to get help — expects you to stay because the work is good. One who keeps everything vague is making themselves impossible to leave: a different business model entirely.

6. Warning signs: answers that should make you pause

A good developer will answer all of these easily. Slow down if you meet the opposite:

• Vague scope. "We will handle everything" with no list attached. If it is not written down, it is not agreed.
• Everything is easy. Every request gets an instant yes, with no questions about your goals or your customers. Real projects involve trade-offs; someone who never mentions one is not looking closely.
• No written agreement. A clear summary of scope, ownership and how payment is staged protects both sides. Resistance to writing anything down is itself an answer.
• Hostage-style ownership. Reluctance to register your domain in your name, or to hand over access to your own site. There is no good reason for it, and it never gets easier to fix later.
• Pressure. Questions treated as an inconvenience, or a decision demanded before you have thought it through. A developer who resents your questions is telling you how the project will feel.

7. Comparing two quotes fairly

Once you have answers, comparing quotes stops being a guessing game. Lay both side by side on the same list: scope, exclusions, ownership, revisions, communication, after-launch care. Often the lower number simply excludes things the other includes — content help, room for revisions, fixes after launch — and is not cheaper at all once the same work is compared.

Weigh clarity itself as evidence: the quote that explains the work in plain words is usually a preview of the project that will keep you informed. The real question is not "which of these is cheapest?" but "which of these do I actually understand — and what am I still unsure about?" Anything you are unsure about is one more question to ask before you sign, not after.

Ask before you sign

These are the ordinary questions of a careful buyer, and a good developer will recognise them as the start of a well-run project. The worst time to learn what your quote did not include is after the work has begun.

If you are still deciding what your site should contain, start one step earlier with our guide to what a business website actually needs — it helps you define the scope before you ask anyone to price it. For the bigger picture, see how a small business grows online. Ask the questions first. The budget you protect is your own.

Read next: The Website Launch Checklist: What to Check Before You Go Live →