You can tell whether a developer will waste your money in one conversation, before any money moves. It takes seven questions, and none of them are technical.
The reason they work is that each one has a boring, specific, correct answer that a person who builds things knows immediately — and no good improvised answer for a person who mainly sells things. You do not need to judge the answer's technical accuracy. You need to notice whether it is specific.
1. "What will exist at the end, as a list?"
A straight answer names pages, functions and states: eight pages, a blog you can post to yourself, an enquiry form that emails you and sends a WhatsApp message, a Google Analytics property, a sitemap submitted to Search Console.
The warning sign is adjectives. "A fully responsive, SEO-optimised, modern website" describes nothing you could ever hold anybody to. Every website built in the last ten years is responsive. "SEO-optimised" without naming what is being done — structured data, page titles, a sitemap, page speed — is a word, not a deliverable.
Get this list in writing before you pay the advance. Not because you expect a dispute, but because writing it down is the moment both of you discover you were imagining different websites.
2. "What do you need from me, and by when?"
A straight answer is uncomfortable, because it puts work on you: your logo files, photographs of the actual premises, the text for the About page, a decision on which three services lead.
The warning sign is "nothing, we handle everything." Nobody can write your About page without talking to you. What "we handle everything" usually means is that placeholder text and stock photos will be used, and the site will be handed over 80% finished, and the last 20% will sit unfinished for a year because it needed you and nobody said so at the start.
Missing content is the single largest cause of delay on every website project we have run. A developer who does not warn you about it has not run many.
3. "Whose name are the domain and hosting in?"
The straight answer is yours, in your account, with your email and your password, from day one.
The warning sign is any version of "we manage all that for you." It is often said with genuinely good intentions — it is less hassle — and it is still the single most expensive convenience in this industry. The bill arrives later, and it arrives at the worst moment: the day you want to change developers, or the day they stop answering.
If a developer registers the domain for you, that is fine. Ask them to transfer it to an account in your name once it is live, and confirm it happened. It takes ten minutes.
4. "What happens if I want to change something in six months?"
A straight answer distinguishes between kinds of change. Editing your own text and photos: you do that yourself, here is how. A new page in the existing design: small job, roughly this much. A new integration or a redesign: that is new work and is quoted separately.
The warning sign is "unlimited changes" or "free lifetime support." Nobody can afford to mean that, so it is either not true or the price already assumes you will never call. Both are worse than a clear hourly rate.
Ask specifically whether you can edit your own content without them. If the answer is no, you have bought a permanent dependency, and every typo is a phone call for the life of the site.
5. "Can I see something you built that is still live?"
A straight answer is two or three URLs you can open right now, ideally for businesses roughly your size. Open them on your phone. Look at whether the contact details are correct and whether the copyright year is current — a portfolio full of sites nobody has touched since 2022 tells you something about how the relationships ended.
The warning sign is screenshots, a PDF, or "we can't share client work." Some work genuinely is confidential — internal tools, apps under NDA — but a web developer with no public website they can point to is an unusual web developer.
While you are there, check whether their own site is any good. It is the one project where they were both the client and the builder.
6. "What is not worth doing in my brief?"
This is the most useful question on the list, and almost nobody asks it.
A straight answer names something and explains why: the animated hero you asked for will cost a quarter of the budget and slow the page on the phones most of your customers use; the blog will sit empty unless somebody is actually going to write it; the fourth service page is describing something you barely sell.
The warning sign is enthusiastic agreement with everything. Every brief has something in it that is a bad idea — ours do too. A developer who cannot find it either has not read the brief carefully or has decided it is easier to agree now and renegotiate after the advance clears.
A person who will argue with you before you pay is a person who will tell you the truth after you pay.
7. "How is payment structured, and what happens if this goes wrong?"
A straight answer is a staged structure — commonly 25% to start and the balance on delivery — with a definition of what "delivery" means that matches the list from question one.
The warning signs point in both directions. Full payment upfront asks you to carry all the risk before anything exists. But zero upfront is not the safe option it looks like: a developer with nothing invested has nothing to lose by going quiet when a better-paying job appears. A stage payment aligns both of you.
Ask where the code will live. "In a repository you have access to" is a good answer, and it means that if the relationship ends badly you still have the thing you paid for.
What none of this protects you from
Being unclear about what you want.
Most website projects that go badly do not go badly because of a bad developer. They go badly because the scope changed four times, content arrived late, three people at the client had different opinions and none of them were in the first meeting. A good developer reduces the damage. None of them can fix it.
Before you talk to anyone, be able to say in one sentence who the website is for and what you want that person to do. If you cannot, the most valuable thing you can buy this month is not a website — and we have written honestly about when not to pay anybody to build one, including us.
If your answers to all seven are ready, the build itself is the easy part; that is exactly the condition under which 48 hours is a real timeline rather than a slogan.
Ask us these seven questions. If our answers do not satisfy you, tell us anyway — a project that starts with doubt does not improve later, and both of us are better off knowing in week zero.