How to Hire a Web Developer Without Getting Burned

A meaningful share of my work is rescuing projects someone else abandoned. The pattern is consistent enough to be predictable: no written scope, no milestones, full payment made too early, and no access to the code. The developer was not usually malicious. The arrangement was just built to fail.

Here is how to structure it so it does not.

Before you contact anyone

Write one page containing:

• What your business does and who your customers are
• What you want a visitor to actually do — buy, book, enquire, read
• The pages or features you think you need
• Two or three sites you like, and specifically what you like about each
• Your budget range and your deadline

This document does more for quote quality than anything else. Without it, every developer is guessing at a different project and the quotes will be incomparable.

How to evaluate a portfolio

Do not just look at screenshots. Open the live sites and check:

1. Do the URLs still work? Dead links mean the client left or the work was never deployed.
2. How fast does it load on your phone, on mobile data?
3. Does it look different from the other projects in the portfolio, or are they all the same template?
4. Is there real content, or is it still filled with placeholder text?
5. View the page source. Is there a title, a description, structured data — or nothing?

Questions worth asking

Technical

• "What will you build this in, and why that choice for my project?" — you are testing whether they can justify a decision, not the answer itself.
• "Will I be able to edit content myself?" — get specifics on what is editable and what is not.
• "How will you handle SEO?" — a vague "we do SEO" answer means no. A good answer mentions metadata, sitemaps, structured data and performance.
• "What happens if it gets slow or breaks after launch?"

Commercial

• "Who owns the code and the accounts when we finish?" — the answer must be you, in writing.
• "How many revision rounds are included?" — a specific number is a good sign; "unlimited" is not.
• "What is not included in this quote?" — the most informative question you can ask.
• "Can I speak to a past client?" — a real developer will have someone.

Structuring payment

Never pay in full up front. Never expect a developer to work for free either. A structure that protects both sides:

• 30 percent to start
• 30 percent at an agreed midpoint — usually design approved and core pages built
• 30 percent when the site is complete on a staging URL
• 10 percent after launch and a short bug-fix window

Tie each payment to something you can see, not to a date. "Milestone 2: all pages built and reviewable at a staging link" is verifiable; "Milestone 2: 50 percent complete" is not.

What the written agreement must contain

1. A specific list of pages and features — not "a website"
2. Who provides content, text and images
3. Number of revision rounds and what counts as a revision versus a new request
4. Timeline with milestone dates
5. Ownership of code, domain, hosting and all accounts
6. What post-launch support is included, and for how long
7. What happens if either side wants to stop

This does not need a lawyer. A clear email that both parties confirm is enormously better than nothing, which is what most projects run on.

Warning signs during the project

• You cannot see anything until "it is finished"
• Messages take days to answer, with no explanation
• Scope quietly shrinks and nobody mentions it
• You are asked for the full remaining payment before you have seen the work
• They will not give you access to the repository or hosting

Ask for a staging link in week one and expect it to be updated regularly. Continuous visibility prevents almost every dispute that reaches me later.

Freelancer, agency, or in-house?

• Freelancer — best value, direct communication, but a single point of failure. Right for most small business sites.
• Agency — more expensive, more process, survives one person leaving. Right when the project is business-critical.
• In-house — only worth it when you need continuous development, not a one-off build.

The handover checklist

Before you make the final payment, confirm you have:

• Admin access to the domain registrar
• Admin access to hosting
• The source code, in a repository you own
• Any CMS or admin login
• Google Analytics and Search Console added to your account, not theirs
• A short document explaining how to update content

Getting these after final payment is much harder than getting them before. Make it part of the last milestone.