Blog / web
Choosing a web developer without getting burned
How to vet a web developer: verify the portfolio, keep ownership of domain and hosting, pin down maintenance, and start with a small scope.
I get called in to untangle web projects far more often than I get called in to start them. The pattern is depressingly consistent: a small business hires a developer on the strength of a nice portfolio and a friendly first meeting, and eighteen months later they discover they do not own their own domain, cannot log in to their own hosting, and the developer has stopped answering email. None of this requires bad intent. Most of it is preventable in the first two conversations.
Verify the portfolio, do not just admire it
A portfolio tells you what a developer claims. Verification tells you what they did. Pick two or three sites from the portfolio and actually visit them. Are they still online? Do they work on a phone? Then, and almost nobody does this, contact the business and ask two questions: did this person actually build it, and what happened after launch when you needed changes?
That second question matters more than the first. Building a site is a project; the relationship you are buying is what happens in year two. You are listening for "responds within a few days and bills fairly" versus a long pause.
Be alert to portfolios where every site shares one template with different colours. That may be fine at the right price, but it should be priced as configuration, not custom work.
Ownership: the part that actually burns people
Here is the rule, and I would put it in writing before any work starts: the domain is registered in your name, in a registrar account you control. The hosting account is yours, with the bill going to your credit card, and the developer gets a login to it. The code and content are yours, delivered somewhere you can reach.
Every horror story I untangle violates one of those. The developer who registered the domain "to keep things simple" and now effectively holds the business's name. The site hosted on the developer's reseller account, unreachable when they retire, get sick, or fall out with you. The custom code that exists only on their laptop.
A good developer will not resist any of this; the good ones prefer it, because being the accidental landlord of a client's domain is a liability for them too. If a candidate pushes back on you owning your own domain and hosting, that is your answer about the whole relationship.
While you are setting up hosting in your own name, ask the same questions of the host you would ask any vendor. I keep a list in what to ask before signing a hosting quote, and it takes twenty minutes to work through.
Pin down maintenance before launch, not after
A website is not a finished object. Software underneath it needs updates, things break, and you will want changes. So before signing, get plain answers in writing: who applies updates, and how often? What does an hour of post-launch work cost? What is the expected response time when the site is down versus when you want a wording change? What happens if you and the developer part ways: what do they hand over, and in what form?
The absence of a maintenance answer is itself an answer. It means every future request will be negotiated from scratch, at whatever the market will bear, with your site as the hostage. The same fine-print discipline applies here as anywhere: promises that are not written down are moods, not terms. And make sure backups of the site are part of someone's written job; the questions in a backup strategy an owner can actually audit apply to your website exactly as much as to your file server.
Start with a small scope on purpose
Do not make your first project with a new developer the big one. Carve off something real but bounded: a landing page, a redesign of one section, a fix-and-tidy of the existing site. A small scope tests everything that matters: estimation, communication, invoicing, how they handle a change request, what their handover looks like. It costs you hundreds to low thousands of dollars to learn what would otherwise cost you the whole project to learn.
If the small project goes well, scale up with confidence. If it goes badly, you have lost a month, not a year. Developers who refuse small first engagements and insist on the full commitment up front are asking you to take on all the relationship risk. You do not have to.
The short version
Check the portfolio by talking to past clients. Own your domain, your hosting, and your code, in writing, from day one. Get maintenance terms before launch. Start small.
None of this requires technical knowledge, just the willingness to ask ordinary business questions about an area where people are strangely shy to ask them. If you would rather have someone technical sit beside you while you compare candidates or review a proposal, that is a small hourly engagement for me, described on my second opinion page. I do not build websites, so I have no horse in the race.