What to Ask a Web Developer Before You Hire One (2026)

Most people hire a web developer the way they hire a contractor: they ask what it costs and how long it takes. Those are the two questions that matter least. The questions below are the ones that decide whether you own your website in two years or find yourself stuck paying someone to keep it alive.

I’m a developer on Long Island, and I’ve been called in to clean up a lot of sites built by someone else. Almost every mess traces back to a question nobody asked up front. Here’s what to ask, why it matters, and what a good answer sounds like.

1. Who owns the code and the accounts?

This is the big one. Ask it first.

If the developer builds your site on their own hosting account, registers your domain under their name, or keeps the source code on their laptop, you don’t own your website. You’re renting it. When the relationship ends (and eventually it will, for one reason or another), you can lose the domain, the content, and the ability to make changes.

A good answer: you own everything. The domain is registered in your name with your email as the admin contact. The hosting account is yours. The code lives in a Git repository you have access to. The developer works inside your accounts, not theirs.

Get this in writing in the contract. Verbal assurances don’t help when someone stops returning calls.

2. What happens if I want to leave?

Follow-up question, and it’s revealing. Ask directly: “If I wanted to move this site to another developer next month, what would that involve?”

If the answer is a clear explanation of how you’d export the database, get the files, and hand off credentials, that’s a professional. If the answer is vague, or involves a “migration fee,” or a long pause, that’s a warning sign. A developer who does good work doesn’t need to trap you.

3. What platform are you building on, and why?

There’s no single right answer here, but there is a wrong one: “whatever I always use.”

The platform should match the job. A five-page brochure site for a local business is a different problem than a customer portal with logins and payments.

• WordPress: still the most common choice for content-heavy sites in 2026. Enormous plugin ecosystem, easy for non-technical staff to edit, and plenty of developers know it. The tradeoff is maintenance. Plugins need updates, and outdated plugins are the single most common way WordPress sites get hacked.
• Static site generators (Astro, Eleventy, Hugo): fast, cheap to host, almost nothing to break. Great for marketing sites that don’t change daily. Less great if you want a client to log in and edit pages without touching code.
• Next.js or another full framework: appropriate when you need real application logic, user accounts, or heavy interactivity. Overkill and expensive to maintain for a simple brochure site.
• Shopify, Squarespace, Wix: fine for many small businesses, especially retail. You’re renting the platform, which is a real tradeoff, but the tradeoff is sometimes worth it.

Ask why they picked what they picked. If they can’t explain the tradeoffs, they didn’t think about it.

4. How will the site perform on mobile and on slow connections?

More than half of your visitors are on a phone, often on mediocre cellular signal. A site that takes six seconds to load on a phone is losing you customers before they read a word.

Ask what they do about it. Good answers include: compressing and resizing images, lazy-loading below-the-fold content, limiting third-party scripts, and actually testing on a real phone rather than just resizing a desktop browser window.

You can check any live site yourself. Google’s PageSpeed Insights gives you real numbers, and Core Web Vitals are still a ranking factor in 2026. If a developer doesn’t know what Core Web Vitals are, that tells you something.

5. How do you handle security and updates?

Websites aren’t set-and-forget. Software has bugs, and bugs get exploited. Ask:

• Who applies security updates, and how often?
• Is there a backup system, and where do the backups live?
• Have you ever had to restore a site from backup? (The answer should be yes. Everyone who’s been doing this a while has.)
• Is there an SSL certificate, and who renews it?

If the site handles payments or stores customer data, the questions get more serious. Ask about PCI compliance if you’re taking cards. Ask where data is stored and who can access it. If the developer waves this off, walk away.

6. What does “done” mean, and what does maintenance cost after that?

Every project has a launch date and then a long tail of work after it. Get both numbers up front.

Ask for a written scope: what pages, what features, what’s explicitly not included. “We’ll build you a website” is not a scope. Then ask what ongoing maintenance costs per month or per year, and what it covers. Some developers include updates and backups in a monthly retainer. Some charge hourly. Some don’t offer maintenance at all, which means you’ll need to find someone who does.

7. Can you show me a site you built that I can test?

Not a screenshot. Not a portfolio thumbnail. A live URL you can open on your own phone and click around.

Then actually test it. Load it on cellular data with wifi off. Try the contact form. Check whether it looks right on your phone. Open the browser’s developer tools and look at the console for errors, or just run it through PageSpeed Insights. Ten minutes of testing tells you more than an hour of conversation.

If they can’t or won’t share live examples, that’s your answer.

8. How do you handle accessibility?

Accessibility is not a nice-to-have. It’s a legal exposure in many industries and it’s just good work. Roughly one in four adults has some form of disability, and a site that ignores them is a site that ignores a quarter of its potential customers.

Ask whether they test with a keyboard, whether images have alt text, whether color contrast meets WCAG AA, and whether forms have proper labels. A developer who knows what WCAG is will answer without hesitating. A developer who doesn’t will change the subject.

If you want to see what it looks like in practice, semantic HTML is the foundation:

<!-- Bad: a div that looks like a button but isn't one -->
<div class="btn" onclick="submitForm()">Send</div>

<!-- Good: a real button, keyboard accessible for free -->
<button type="submit">Send</button>

<!-- Bad: image with no description -->
<img src="team-photo.jpg">

<!-- Good: meaningful alt text -->
<img src="team-photo.jpg" alt="Our three-person team at the Commack office">

Small things. They add up across a whole site.

9. What’s your process for changes after launch?

You will want changes. A phone number changes, a service gets added, a photo looks dated. Ask how that works before you need it.

Good answers: you can log in and edit content yourself, or there’s a clear request process with a stated turnaround and rate. Bad answers: “just text me” with no rate mentioned, or a CMS so locked down you can’t fix a typo without paying someone.

10. Do you use AI to generate the code, and how do you review it?

This question didn’t exist five years ago. In 2026 it matters.

Most developers use AI tools now, and that’s fine. What matters is what happens after. AI-generated code can be subtly wrong, can pull in outdated patterns, can introduce security holes nobody notices, and can be confidently incorrect in ways that are hard to spot.

A good answer sounds like: “Yes, I use AI tools to speed up boilerplate, but I review and test everything before it ships, and I don’t ship code I don’t understand.” A bad answer is either “never touch the stuff” (probably not true) or “yeah, it writes the whole thing” (a problem, unless someone is reviewing carefully).

What you’re really asking is: does a human understand the code running your business?

11. What’s the payment schedule?

Standard practice is a deposit up front, often 30 to 50 percent, with the balance due at launch. Milestone payments for larger projects are normal and fair to both sides.

Be cautious of anyone who wants the full amount before starting, or who asks for payment in a way that leaves no paper trail. Also ask whether the price is fixed or hourly, and what happens if the scope changes. Good developers will tell you that changes cost extra rather than quietly eating the cost and resenting you for it.

12. Can I talk to a current client?

References are the fastest way to learn what someone is actually like to work with. Not whether they can code (the portfolio answers that) but whether they answer emails, hit deadlines, and tell you the truth when a request is a bad idea.

Ask for two references, ideally from clients whose projects resemble yours. If a developer can’t produce any, that’s meaningful.

Red flags worth walking away from

• They register your domain under their own name or their company’s name.
• They won’t put ownership terms in writing.
• They can’t show you a live site you can test.
• They quote a price before asking anything about your business or goals.
• They get defensive when you ask about security, backups, or accessibility.
• They promise page-one Google rankings. Nobody can promise that.
• They pressure you to sign today.

What a good developer actually does

A good developer asks you questions first. What does the business do, who are the customers, what’s the site supposed to accomplish, what’s the budget, what’s the deadline. If someone starts quoting prices in the first five minutes, they’re selling a template, not solving your problem.

If you want to see how I approach custom web development, that page lays out the process. But whoever you hire, ask the questions above. The developer who answers them clearly and without flinching is the one you want. The one who dodges is the one you’ll be paying to clean up after in two years.

FAQ

How much should a small business website cost in 2026?

For a straightforward five to ten page site with a CMS, expect somewhere in the low thousands to the mid five figures depending on custom design, integrations, and content work. Anyone quoting a few hundred dollars is either using a template you could buy yourself or cutting corners you’ll pay for later. Anyone quoting six figures for a brochure site is overselling.

Should I own my domain and hosting, or let the developer handle it?

You should own both. The domain should be registered in your name with your email as the admin contact, and the hosting account should be yours even if the developer manages it day to day. This costs you nothing and protects you completely if the relationship ends.

How long should a website build take?

A simple site is usually two to six weeks. Something with custom functionality, integrations, or a lot of content is more like two to four months. If a developer promises a complex site in a week, ask what’s being skipped. Content is usually the slow part, and it’s usually on your side, not theirs.