Most failed web projects do not fail technically. They fail because expectations were never written down, and both sides discovered the mismatch in week six.
These twelve questions surface that mismatch before you pay anything. Ask them by email, so the answers exist in writing.
Ownership and access
1. Who owns the code when the project ends?
You should. Get it in writing. Some developers retain ownership and licence the site to you, which becomes a serious problem the day you want to move on.
2. Whose accounts are the hosting and domain in?
Yours, with the developer given access — never the reverse. Domains registered in a developer’s account are the most common way businesses lose control of their own website.
3. Can another developer take this over?
A good answer describes documented, conventional code. A bad answer is defensive. You are testing whether you will be locked in.
Scope and money
4. What is explicitly NOT included?
The most revealing question on this list. A developer who has thought about delivery can list exclusions immediately. One who cannot is quoting on hope.
5. What happens when I change my mind mid-project?
You will. Ask how changes are priced and approved. “We’ll sort it out” means an awkward conversation later, at your expense.
6. What is the payment schedule tied to?
Milestones tied to deliverables protect both sides. Fully upfront favours them; fully on completion favours you and few good developers will accept it.
The part everyone forgets
7. What can I edit myself without calling you?
Ask for specifics — not “you can edit everything”, but which pages, which sections, which images. This determines your ongoing cost more than anything else in the quote.
8. Will you train my team, and is documentation included?
An hour of handover saves months of support tickets. If it is not in the quote, it usually does not happen.
9. What does support look like after launch?
How long are bugs fixed free? What is the response time? What does ongoing maintenance cost? Sites need updating; decide now who does it.
Quality and risk
10. How will you handle performance and SEO?
You want specifics — Core Web Vitals, structured data, redirect handling on migrations. “We follow best practice” is not an answer.
11. Will there be a staging site?
If changes are made directly on the live site, you will eventually see a broken homepage during business hours.
12. Can I speak to a client from a project like mine?
Portfolios show finished work. A reference tells you what the developer was like to work with in week five, which is what you are actually buying.
Warning signs
- A quote with no written scope.
- A price dramatically below every other quote — usually a scope misunderstanding that surfaces later.
- Reluctance to name the technology, or to explain a decision in plain language.
- No questions asked about your business before quoting.
- Pressure to decide immediately.
What good looks like
A developer worth hiring will ask you more questions than you ask them, tell you when something is a bad idea, put the scope in writing, and be comfortable explaining trade-offs without jargon.
For what it is worth, this is how I work: a written scope, a fixed price, and a clear list of what is not included. You can see the projects on my portfolio, and if you want a proposal, send a short brief — you will get a plan, timeline and price back within 24 hours.