If you're researching questions to ask a web developer, you've probably seen the listicles: "25 Questions to Ask Before Hiring a Web Developer." They cover the basics—timeline, budget, portfolio, process, CMS, and revision handling.
Those questions matter. Ask them.
But here's what we've noticed after fifteen years of supporting WordPress websites: the questions that actually determine whether your project succeeds long-term are the ones almost nobody thinks to ask. They're not about the build. They're about what happens after.
We're a support company. We inherit websites from agencies that moved on, freelancers who disappeared, and internal staff who left. We see what happens when these questions aren't asked.
The build is the easy part. It's the years after launch where things fall apart.
The Standard Questions (Ask These, But Don't Stop Here)
Before we get to what's missing, let's acknowledge the basics. When evaluating a developer, you should understand:
Their Experience and Approach
- How long have they been building websites?
- Have they built features similar to what you need?
That second question matters more than whether they've worked in your industry. A website is a website, but custom event registration or CRM integrations require specific experience.
Ask about their philosophy on plugins versus custom code. A developer who only uses plugins isn't really a developer—they're assembling pre-built pieces. But a developer who refuses to use plugins is reinventing wheels unnecessarily.
Look for balance: someone who can evaluate when a plugin fits and when custom code is the right call.
Who Actually Does the Work
- Will the senior people you're meeting with actually work on your project, or will it be handed to junior developers?
- Do they outsource any development? If so, how long have they worked with that team, and how do they manage quality?
Their Technical Choices
- Do they build custom themes or use commercial themes? Neither is inherently wrong, but when commercial themes are forced to do custom things, they often become unmaintainable messes. Understanding the tradeoffs between custom themes and page builders helps you evaluate their technical recommendations.
- What's their approach to testing? Do they use staging environments?
These are good questions. But most "questions to ask" articles stop here—focused entirely on getting the website built. Nobody talks about what happens on day 31.
The Questions to Ask a Web Developer That Nobody Thinks Of
"What happens after launch?"
This sounds obvious, but you'd be surprised how often it goes unasked. And the answer matters more than almost anything else.
Specifically:
- Who do I contact when something needs to be fixed, updated, or improved after launch?
- What's your response time for support requests?
- What does ongoing support cost?
Many developers—especially freelancers—are optimized for building, not supporting. Support isn't where the money is.
During the sales process, they'll tell you they'll be there for you after launch. And they probably mean it. But six months later, when you need help, and they're deep in another build project, your "quick fix" sits in their inbox for weeks.
This isn't malicious. It's economics. A freelancer juggling multiple projects has to prioritize billable build work over lower-margin support requests. An agency that sold you a fixed-bid project has already allocated its team to the next client.
Ask directly: What does post-launch support look like? Is it included? Billed hourly? Do you have a maintenance retainer? What's realistic to expect? If you're evaluating ongoing development relationships, our guide on why a WordPress retainer makes sense explains the benefits of continuous partnership over project-based work.
"Who handles updates and security?"
WordPress sites need ongoing maintenance. Plugins need updates. PHP versions change. Security vulnerabilities get discovered and patched.
Someone needs to be paying attention.
Ask:
- Who's responsible for keeping the site updated—plugins, themes, WordPress core?
- Do you have an update process, or do you just push updates to production and hope nothing breaks?
- What security measures are in place? Malware scanning? Firewalls? Monitoring?
- If my site gets hacked, what happens? Is cleanup included or an additional cost?
We've seen sites break because the hosting company upgraded PHP, and nobody told the client what that meant. They got notices—technical emails they didn't understand—so they ignored them. Then one day, the site stopped working, and the person who could fix it was long gone.
"What if something breaks at 2 am?"
Not every website needs 24/7 emergency support. A brochure site for a local business can probably wait until morning.
But if your website is mission-critical—if downtime means lost revenue, missed donations, or reputational damage—you need to know the answer to this question before you even ask.
Ask:
- Do you offer emergency support?
- What's considered an emergency versus a normal support request?
- What's the realistic response time if something critical breaks outside business hours?
The honest answer from most freelancers and small agencies is "I'll get to it when I can." That might be fine for your situation. But know that going in.
"Will I get documentation?"
This is the most commonly missed question, and it causes the most pain down the road.
When your developer is available, they're your living documentation. They know where everything is, how it's configured, and why that weird workaround exists.
But when they're gone—whether they quit, got busy, or simply moved on—that knowledge disappears with them.
Ask:
- Will I receive documentation for this website?
- If you disappeared tomorrow, could another developer pick this up?
- Will I have all credentials documented—hosting login, DNS access, WordPress admin, any third-party services?
We regularly work with organizations that don't know where their websites are hosted. They don't know their DNS provider. They don't have admin access to their own site.
The freelancer who built it handled all of that, and now that freelancer is gone.
Getting this documented upfront—while the relationship is good—saves enormous headaches later.
"Do I own the code? Can I take my site elsewhere?"
This should be obvious, but we've seen situations where it wasn't.
Some hosting platforms lock you in. We've encountered sites built on proprietary systems where the code simply couldn't be exported—the client's only option was to rebuild from scratch on a new platform.
That's an expensive surprise.
Ask:
- Do I own the code you're writing for me?
- Is this site portable? Can I move it to a different host if I choose to?
- Will I have file access and database access?
Even if you're not technical, even if you'll never touch a database, it's your data. The answer should be yes—you own it, you can access it, you can take it anywhere.
Also, ask about ongoing licensing:
- Are there premium plugins or themes that require annual licensing fees?
- What happens if I stop paying those fees?
Some "free" features depend on paid plugin licenses. Know what you're committing to.
"What if YOU disappear?"
This is an awkward question, but it encompasses everything else.
If you're working with a freelancer, they might take a full-time job, move on from web development, or simply get too busy for your project. If you're working with an agency, your point of contact might leave. Things change.
Ask:
- If you were no longer available, what happens to my website?
- Is there anyone else at your company familiar with my project?
- Is the site documented well enough that another developer could take over?
A good answer isn't "that won't happen." A good answer acknowledges the question and explains how they've set you up so you won't be stranded.
"Do you test changes before they go live?"
Ask about their deployment process:
- Do you work directly on the live site, or do you use a staging environment?
- Will I get a chance to review and approve changes before they go to production?
- When you deploy to production, is it disruptive? Should it be scheduled for off-hours?
For simple content updates, working on a live site is often fine. But for development work—new features, significant changes—there should be a staging environment to test changes before they affect your live website.
We've seen developers push untested code directly to production, break the site, and then scramble to fix it while the client's customers see error messages.
That's avoidable.
Why These Questions Matter: What We See When We Inherit Sites
We're the company people call when their previous developer situation didn't work out. Here's what we typically find:
The client doesn't know where anything is. They can't tell us who hosts their site. They don't know what DNS is, let alone who controls theirs. We have to do detective work just to figure out the basics.
They can't do simple things. They want to update a paragraph on their homepage but don't know how. Their developer always did that. They don't have admin access—sometimes they don't even know what it is.
Annual features are a mystery. Every year, they host a major fundraiser or event. Someone else always handled the registration system. Now that the person is gone, the event is in 6 weeks, and no one knows how to turn it on.
The site is more fragile than they realized. It ran fine for a year, then something broke, and they don't know why. Often, it's something like a PHP upgrade from the hosting company—routine maintenance that the site wasn't prepared for.
They're locked in. They want to leave their current host but discover the site was built on proprietary infrastructure. Moving means rebuilding—and understanding the difference between a refresh, redesign, and rebuild can save tens of thousands of dollars when that day comes.
All of these situations stem from questions that weren't asked before the contract was signed.
Green Flags: What Good Looks Like
When a prospective client comes to us from a good developer relationship, we can tell. Here's what stands out:
The transition was planned. The previous developer gave advance notice—60 days, 90 days. They didn't just disappear at the end of the month. They gave their client time to find someone new.
The developer is available during handoff. They're willing to share access, answer questions, and provide context. They're not hiding anything.
Documentation exists. Even basic documentation—a list of credentials and notes on how custom features work—makes the transition much smoother.
The client understands their own website. They know what platform it's on, roughly how it's built, and what plugins power key features. Their previous developer took time to explain things.
Standard technology choices. Custom theme with standard plugins. Known frameworks. Not 70 plugins cobbled together, not some obscure system the developer wanted to experiment with.
The developer is proud of their work. They give us admin access immediately. They're not worried about what we'll find when we look under the hood.
When we see these signs, we know the client was well set up. They asked the right questions—or got lucky with a developer who did right by them without being asked.
What does a long-term support relationship actually look like? We've worked with clients like ABFPRS for over a decade—that kind of partnership is what you're really evaluating when you ask these questions.
The Bottom Line
The build phase is important. Ask about experience, process, and approach. Look at portfolios. Understand who's doing the work.
But don't stop there.
Ask about what happens after launch—because that's where most projects eventually struggle. Support, security, documentation, ownership, emergencies. These aren't exciting topics, but they're the questions that determine whether your website will still be serving you well in two years.
A developer who welcomes these questions is thinking long-term. A developer who deflects them, or who hasn't thought about them, is telling you something important about how this relationship will go.
The best questions to ask a web developer aren't about the build—they're about what happens after.
If you're looking for a partner who builds with long-term support in mind, we'd love to talk. Learn about our WordPress support services or see how we approach custom development.