Hiring a web developer is one of the more nerve-wracking purchases a business owner makes, because you are buying something you cannot fully evaluate. You cannot read the code, so you are left judging confidence, portfolios, and price. This guide is the filter I would hand a friend who is not technical: the questions that actually separate a good developer from an expensive mistake, none of which require you to understand a line of code.
TL;DR
- Judge a web developer on outcomes and live work, not on the technologies they name.
- Ask for sites they built that are still live, still fast, and tied to a result you can verify.
- Pin down who owns the code, domain, hosting, and analytics. The answer must be you.
- Treat performance and SEO as day-one requirements, not upsells added later.
- The red flags are vagueness about deliverables, ownership, and measurement, and a price quoted without a scope.
Start with outcomes, not technologies
The first mistake non-technical buyers make is letting the conversation run on technology: which framework, which platform, which tools. Those are the developer’s decisions to justify, not yours to evaluate. Your job is to be clear about the outcome. Is this site meant to generate leads, sell products, book appointments, or simply prove the company is real? A developer who works from that outcome will make better technical choices than one who starts from a favorite tool and looks for somewhere to use it. If the answer to “what is this site for” is a list of features rather than a business result, the project is already pointed in the wrong direction. The deeper version of that decision, bespoke versus borrowed, is covered in custom website vs. template.
The portfolio question that actually matters
Anyone can show you screenshots. Ask for live URLs of sites they built, then check three things you do not need to be technical to check: do the sites load fast, are they still online a year or two later, and can the developer name what the site was for and whether it worked. A portfolio of sites that are slow, abandoned, or that the developer describes only in visual terms is telling you something. The work you want is the work that reached production and stayed there, the same standard that separates a real operator from a demo in any field, including how to hire an AI consultant.
Treat performance and SEO as day-one requirements
The most expensive web mistake is bolting speed and search onto a site after it is built. Both are architectural: they come from how the site is constructed, not from a plugin added at the end. Ask, before you sign, how the developer will keep the site fast and how it will be structured for search. A confident, specific answer is a good sign. A wave toward “we can add SEO later” means it was not designed in, and retrofitting it usually means rebuilding. The plain-English version of what to insist on is in Core Web Vitals for business owners.
Ownership: who holds the code, domain, and accounts
This is the check non-technical owners skip and regret. Make sure the domain, the hosting, the analytics, and the source code are registered to you and handed over at the end. Some developers keep these in their own accounts, deliberately or by habit, which turns a finished project into a leash: leave, and you lose the site. Put ownership in writing before work begins. If parting ways would cost you your website, you never owned it.
Red flags in a web proposal
A few warnings are visible before you commit:
- No clear deliverable or success measure. “A beautiful modern website” is not a deliverable. What pages, what function, and how will you both know it worked?
- Silence on performance or SEO. If these are treated as optional extras, they were not designed in.
- Vagueness about ownership. Any hesitation about who holds the code and accounts is a reason to press harder.
- A price with no scope. A number without a defined scope attached will drift, and the drift is rarely in your favor.
- A portfolio of slow or dead sites. The clearest evidence of all, and the easiest to check.
How to run the first conversation
Drive the call. Open with the outcome the site is meant to produce and watch whether the developer works from it or steers back to their toolkit. Ask for two live sites and what each one was for. Ask how they handle speed, search, and handover, and who will own the assets. Close by asking what happens after launch: who maintains it, how changes get made, and when the dependency on them ends. You are not testing their code. You are testing whether they think in terms of your business or their build, and that single signal predicts most of how the project will go. When the work is a serious revenue channel rather than a credential, that is exactly what the custom web development practice is built around.