What should I ask before hiring anyone to build my website?

Look past the portfolio

A portfolio shows what someone can build. It doesn't show what happens after launch, who owns your accounts once the project ends, or how a problem gets handled six months from now. Those are the questions that actually matter.

A polished portfolio is also, by nature, curated — it shows the best outcomes, not the typical ones. The questions below are harder to prepare a polished answer for, which is exactly what makes them useful.

The five worth asking directly

What happens after launch — is this a one-off build or ongoing care? Who owns the domain, hosting, and credentials once it's done? How are security, backups, and monitoring actually handled? Can you show real, named client work rather than isolated screenshots? And what's the process if something breaks after launch?

Notice that none of these questions are about design taste or technical stack. They're about accountability — who's responsible for what, and for how long. That's usually the part that gets glossed over in an initial pitch and matters most a year later.

What the answers actually reveal

Vague answers to any of these are a signal. Clear, specific answers — especially about what happens after the site goes live — tell you whether you're hiring someone for a single transaction or someone who's going to be accountable for the outcome over time.

What this means for you

Ask these five questions before looking at a single design sample. The answers will tell you more about what it's actually like to work with someone than any portfolio can.

Ask about the platform and why

Every website sits on some kind of platform. WordPress, a page builder, a custom framework. It matters less which one. It matters more whether the person can explain the choice. Ask why they'd build your site this way. A good answer connects the platform to your actual needs.

This is one of the more revealing questions before hiring a web developer. Someone who only knows one tool will always recommend that tool. Someone who's worked across a few platforms can walk you through the tradeoffs. Listen for whether they mention your goals at all. Or just their own habits.

It's also worth asking who else can work on the site later. A platform only one person understands ties you to that person indefinitely. It's fair to ask how replaceable their choice makes you. Not just how fast it lets them build. That's worth raising before hiring a web developer. Even if it feels like a small detail at the time.

Some platforms are easy to hand off to a new developer later. Others are stitched together in ways only the original builder understands. Ask what happens if you need someone else to take over. A confident answer here usually means the build is documented properly, not held together in someone's head.

How they test before launch

A site that looks finished on a laptop can still break somewhere else. Ask what happens between "done" and "live." Do they check it on real phones? Not just a resized browser window. Do they test forms and checkout flows before handing it over?

This question separates people who ship carefully from people who ship fast. There's nothing wrong with speed on its own. But speed without a testing step means you become the tester. Bugs show up after launch. Usually while a customer is trying to use the site.

Ask specifically what a pre-launch checklist looks like for them. If they don't have one, that's an answer too. It's reasonable to want proof that testing is a real step. Not an afterthought squeezed in before the invoice goes out. This is worth confirming before hiring a web developer. It rarely comes up unless you ask directly.

Ask, too, what browsers and devices they actually test on. A site that only gets checked in one browser can look completely different in another. It's a small question with a big payoff. It tells you whether "tested" means a real process or just a quick glance before sending the link.

Who owns the code, domain, and accounts

This is arguably the single most important thing to ask before hiring a web developer. It's also the one people skip. Who holds the domain registration? Who owns the hosting account? Where do the source files actually live once the project wraps?

Some developers build on infrastructure only they control. If they disappear, or you have a falling out, you can lose access to your own website. Ask directly: if we ever part ways, what do I walk away with? A clear answer, in writing, is what you're after here.

It sounds like a small detail early on. It stops being small the day you need to switch developers. And discover you don't actually control your own domain. Get this settled before hiring a web developer. Not after the first invoice clears.

Ask specifically for admin access to your own hosting and domain registrar. Also ask about any third-party tools tied to the site. If a developer resists handing that over, even after launch, treat it as a serious signal. A site you don't control isn't really yours, no matter whose name is on the invoice.

How payment actually works

Payment structure tells you a lot about how a working relationship will go. Is it a flat fee, a deposit plus milestones, or hourly billing? Each has tradeoffs. What matters is whether the structure is clear before any work starts.

Ask when payments are due and what each one covers. A vague answer here is worth pausing on. Something like "we'll figure it out as we go" isn't a real answer. Get the payment schedule in writing, even if it's simple. It protects both sides, not just you.

Scope creep is normal on most projects too. You'll think of things partway through, and that's fine. The real question is how those changes get priced. And whether you'll hear about the cost before the work happens, not after. Ask what counts as in-scope versus a paid add-on.

Extra pages, extra revision rounds, a mid-project redesign. Get specific about each one. This is one of those questions before hiring a web developer that feels unnecessary at first. It stops feeling unnecessary the moment an invoice shows up bigger than expected and nobody can explain why.

What a realistic timeline actually looks like

Every proposal has a timeline. Not every timeline is honest. Ask what could realistically push the date back. Content delays, revision rounds, third-party integrations are common culprits. Someone who's done this before can name them without much hesitation.

Be wary of a timeline that sounds perfect, with no room for anything to slip. Real projects hit real snags. What matters more than the date itself is how delays get communicated. Do you find out immediately? Or does the deadline just quietly pass without a word?

It's also fair to ask what a typical week looks like during the build. Will you see progress along the way? Or only a finished product at the end? Knowing how visible the process will be tells you how much you'll be kept in the loop. That's worth asking before hiring a web developer commits you to months of silence.

Ask what happens if you're slow to provide content or feedback on your end. A good developer has a plan for that too. It shouldn't just quietly reset the whole timeline without anyone flagging it.

Reading how someone answers, not just what they say

The content of an answer matters. So does how it's delivered. A confident, specific answer, even to an uncomfortable question, is a good sign. A vague answer, or a slightly defensive one, tells you something too.

Watch for questions that get deflected back onto you. Something like "well, what's your budget?" instead of a direct answer. That's not automatically a red flag on its own. But paired with vagueness about ownership or process, it starts to build a pattern. Trust the pattern more than any single answer.

This is really what asking questions before hiring a web developer is for. It's not a checklist to tick off and forget. It's a way to see how someone communicates under a slightly awkward question. That's exactly what you'll need from them later when something actually goes wrong.

Notice, too, whether they ask you any questions back. A one-way pitch, with no curiosity about your business, is a quieter warning sign. It's still worth noticing, even if it's less obvious than an outright bad answer. The best working relationships start as a conversation. Not a monologue with a price tag attached at the end.

What a good discovery conversation feels like

Before any contract, there's usually a first conversation. Pay attention to what it feels like. Not just what gets said. A good discovery call asks about your business before it starts pitching a solution. It should feel like they're trying to understand a problem.

A weak discovery call skips straight to features and price. It treats your business like every other project that came before it. If nobody asks what your customers actually do on your site, that's a gap worth noticing. Same goes if nobody asks what frustrates you about the current one.

Pay attention to whether they push back on anything you say. A developer who agrees with every idea, without question, isn't necessarily being helpful. Sometimes the more useful answer is a respectful pushback. Something like "that might not work as well as you think." That's a sign of someone thinking with you. It's worth noticing before hiring a web developer turns into a signed contract you can't easily undo.

Checking references properly

A portfolio page shows finished screenshots. It doesn't show what the relationship was actually like day to day. If a developer offers references, take them up on it. A short call with a past client tells you more than an hour of browsing their site.

Ask former clients specific things. Did the project finish close to the original timeline? Did costs stay close to the quote? Did they respond quickly when something broke after launch? Would they hire this person again for a second project? That last question usually gets you the most honest answer.

If a developer can't produce a single reachable former client, that's worth noting. It doesn't automatically mean something's wrong. Some people work mostly under NDAs or agency contracts. But between two similar options, the one with named clients is the safer bet. That's especially true before hiring a web developer for something your business depends on.

It's also worth asking a former client one blunt question. What would you tell them to do differently next time? Nobody's process is perfect. Someone who genuinely served their clients well tends to have an answer that sounds like ordinary growing pains. Not a serious complaint that got glossed over.

What proven experience actually looks like

Longevity is a real signal, but it needs context to mean anything. A developer who's cleaned or built thousands of sites has seen more mistakes. Including the ones that don't show up until year two. That kind of pattern recognition is hard to fake in a single conversation.

For what it's worth, work that's touched over 10,000 WordPress sites tends to surface something different. Same goes for work that's secured 573-plus businesses. It's a different kind of answer to these questions. One shaped by having watched things go wrong before. Not just having built things that look right at launch.

Ask how many clients stick around for future work. A high return rate says more about trust than any single testimonial does. Something like a 96% return rate is hard to fake. People don't come back to someone who dropped the ball the first time.

Experience alone isn't the whole story though. Someone newer to the field can still be a great fit. Especially if their answers to everything above are clear and specific. Years in business is one data point. It's not a substitute for actually asking. Before hiring a web developer, find out if this specific person is right for this specific project.

Before you sign anything

Pull it together into a short list you can actually use. Who owns the domain and code after launch? What's the payment schedule, in writing? What counts as in-scope versus extra? What's the realistic timeline, including likely delays? Can you actually reach a past client?

None of these questions require technical knowledge to ask. They just require asking them early. Not after a deposit has already changed hands. Businesses that get this step right tend to end up in long-term working relationships. Not one-off transactions that quietly go quiet.

If you only remember one thing from this list, make it this: ask about ownership. And ask about what happens after launch. Everything else is negotiable. Those two things determine whether you're stuck if the relationship doesn't work out.

Write the answers down as you go, even in a simple note. It's easy to remember a good feeling from a call and forget the specifics that produced it. A quick record makes it much easier to compare candidates fairly. That's true once you've had a few of these calls. Especially the ones you have before hiring a web developer for the job.