The Problem With Vetting a Developer
You’re hiring someone to build a thing you can’t evaluate, using skills you don’t have, and you’ll find out whether it went well roughly a year after you’ve paid. Every other professional service you buy has a shorter feedback loop than this one.
So most people fall back on proxies: the portfolio looks nice, the price is in range, they seemed responsive on the call. Those aren’t useless, but they don’t separate a good build from one that will quietly become expensive.
These twelve questions do. None of them require you to be technical. What matters is less the answer itself than whether the person can answer plainly, without deflecting.
Before You Sign
1. Who specifically is writing the code, and will I talk to them?
Plenty of shops sell with a strategist and build with a subcontractor you’ll never meet. That can work fine. What doesn’t work is finding out in month three, when a question takes four days to round-trip through someone who’s relaying it.
Ask who builds it, where they are, and who you email when something’s broken. A good answer is specific. A bad answer is “our team.”
2. What happens to my site if I stop working with you?
You should be able to leave with a complete export of your files and database, and land somewhere else without a rebuild. Anything else is lock-in.
Watch for two flavors of it: proprietary page builders that store content in a format only their tool reads, and hosting arrangements where the “site” is really a tenant of someone else’s platform. Both are survivable. Both should be disclosed before you sign, not discovered when you try to leave.
3. Are you using a page builder, and which one?
Not a trick question, and not automatically disqualifying. Elementor, Divi, and WPBakery build real sites for real businesses every day.
What you want is a straight answer plus a reason. “We use Elementor because it lets your team edit without us, and here’s what that costs you in page weight” is a fine answer. Evasion is the red flag. So is “we build custom” from someone who then hands you a licensed theme with the demo content swapped. We wrote up the trade-offs in custom WordPress vs. page builders.
4. How will my team update content after launch?
Ask for a demo of the actual editing experience on a site they’ve built — not a slide, the real admin. You’re looking for whether adding a team member or changing a headline requires knowing which of forty nested containers to click into.
This is the single best predictor of whether your site stays current. A site your staff finds intimidating stops getting updated within about four months.
5. What’s included in revisions, and what triggers a new charge?
Get the number of rounds, the definition of a round, and the hourly rate for anything beyond. “A revision is an adjustment to an existing mockup, not a new design direction” is the kind of clarity that prevents an awkward conversation in week eight.
6. Who owns the accounts?
Your domain registrar, your DNS, your hosting, your Google Analytics, your Search Console, your Google Business Profile. All of these should be in accounts you own, with your developer given access — not the reverse.
This is the one that causes the most real damage when it goes wrong. We have onboarded clients who could not move their own domain because it was registered under a former vendor’s account and the vendor had stopped answering email. Ask now.
7. What does the handoff include?
At minimum: a walkthrough of the admin, documentation for anything custom, and a list of what’s where. Ideally recorded, so the person who joins your team next year can watch it.
About the Work Itself
8. How do you handle accessibility?
If the answer is “we install an accessibility plugin,” that’s a problem. Overlay widgets do not make a site accessible and have been the subject of a fair number of lawsuits themselves.
The answer you want involves semantic markup, keyboard navigation, contrast ratios, and alt text as part of the build rather than a bolt-on. If you’re in healthcare, senior living, education, or anything public-sector, this question isn’t optional — we’ve written about why.
9. What’s your plan for the URLs on my current site?
Any rebuild changes some URLs. Without a redirect map, every ranking and backlink pointing at an old URL lands on a 404, and the traffic drop shows up about three weeks after launch when everyone has stopped paying attention.
A developer who brings this up before you do is telling you something good about how they work. If they haven’t mentioned it by the second call, ask directly.
10. How fast will it be, and how will we know?
Ask for the Core Web Vitals of a site they launched recently — a real client URL you can test yourself. Then test it. PageSpeed Insights is free and takes thirty seconds.
You’re not looking for a perfect score. You’re looking for whether they can name the metrics and whether the number they quoted matches the number you get.
11. What structured data will the site have?
Schema markup is how search engines and AI tools understand what your business is rather than guessing from your text. It’s increasingly the difference between being cited by an AI assistant and being invisible to it.
Any competent shop should be able to tell you what schema types your site will carry — organization, service, article, FAQ, whatever fits — without looking it up. More on this in our schema markup guide.
12. What happens after launch?
Ask what the monthly relationship looks like, what it costs, and what’s in it. Then ask the version of the question that actually reveals things: “What did you do for your longest-running client last month?”
A shop with real ongoing relationships will have a concrete answer. A shop that builds and disappears will give you a feature list.
The Answers That Should Worry You
Across a lot of these conversations, a few responses reliably predict trouble:
- “We guarantee first page on Google.” Nobody can guarantee that. It means either dishonesty or a plan to rank you for search terms nobody uses.
- “You won’t need to change anything after launch.” Every site needs changing. This answer means they’re not planning to be around.
- Discomfort with the ownership question. Any hesitation on question six is worth taking seriously.
- A quote with no scope attached. A number without a page list, a functionality list, and a revision policy isn’t a quote, it’s an opening bid.
- A portfolio of sites that are all gone. Click the portfolio links. If half of them 404 or have been rebuilt by someone else, ask why.
One Thing That Isn’t On the List
Company size. A twelve-person agency is not inherently safer than one experienced developer, and it’s often slower and more expensive for the same output. What matters is whether the person doing the work is good, whether you can reach them, and whether they’ll still be there in three years.
Ask for two references from clients who’ve been with them more than two years. The willingness to provide those tells you most of what the other eleven questions are trying to get at.
If you’re working through this list right now and want a second opinion on a quote you’ve received, send it over. We’ll tell you what looks reasonable and what we’d push back on, whether or not you end up working with us.
