Why this list matters
Hiring a developer is one of the more opaque purchases a business can make. The deliverable (a website, an integration, a plugin) is technical, the work is mostly invisible until it's finished, and the difference between a good outcome and a bad one is usually determined long before any code is written.
Most clients ask about cost and timeline. Those matter, but they're trailing indicators. The questions below are leading ones. They tell you what the working relationship will actually feel like once the proposals are signed and the kickoff call is booked.
A handful of these questions will be uncomfortable for the developer. That's fine. The good ones will answer them happily; the answers themselves will tell you who you're working with.
1. "Who actually does the work?"
Sounds like a strange question. It isn't.
A surprisingly common pattern: a developer or agency wins the project, takes the deposit, then hands the actual building to a junior, an offshore team, or a freelancer they've subcontracted. The person you spoke to in the sales call is not the person who'll be writing your code.
This isn't always a bad thing. Some agencies are genuinely good at scoping and project management, and the technical work being done by someone else is structurally fine if the chain of accountability is clear.
What you're looking for in the answer:
- Who specifically will be writing the code? If it's not the person you're talking to, ask to meet them.
- Who'll be your point of contact? A project manager who can translate between you and the developer can be useful, but a project manager who blocks communication with the developer is a red flag.
- What happens if the developer leaves the agency mid-project? Most agencies have an answer to this; what matters is whether the answer is convincing.
If the developer is a one-person operation, this question is short: "I do." That's usually the simplest possible answer to give a client, and it removes a lot of the failure modes above.
2. "How do you charge, and why?"
The honest answer to this question tells you almost everything about how the developer thinks.
Hourly billing with a transparent log: the developer is comfortable with you seeing how long things take. They're confident enough in their estimates not to need a fixed price as a hedge. They expect mid-project changes to be a normal conversation, not a contractual fight.
Fixed-price project quotes: the developer is taking on the risk of misestimation, which is fair, but they've also priced that risk into the quote. Fixed prices typically include a 30 to 50 percent buffer for "unknowns," which means you're paying for protection against scope creep whether or not it happens. Fixed-price quotes also create incentives to skimp on the parts of the work that nobody will notice.
Retainers for ongoing work: fine for maintenance, less fine for project work, where they can blur the line between "agreed-upon hours" and "additional work."
Equity, royalties, or revenue share: rarely a good idea on either side. If a developer suggests this, ask why.
There's no single right answer. What matters is whether the developer has thought about why they charge the way they do, and whether the structure aligns with how the work is likely to evolve.
I've written more about why I personally bill hourly in this post if the topic interests you.
3. "What happens to the work if I want to leave?"
The single most important question for a long-term relationship, and the one most clients don't think to ask.
The answers to listen for:
- You own all the code. WordPress is open-source software, your site is yours, and there should be no proprietary lock-in to a developer or platform.
- You have access to the hosting account, the domain registrar, and the database. Not via the developer; in your own name.
- The codebase is in version control (Git, usually GitHub or Bitbucket) and you have access to the repository.
- The site is documented well enough that another developer could pick it up. Not necessarily a 200-page manual, but a clear README, a sensible folder structure, and meaningful commit history.
The bad versions:
- The developer holds the hosting account, the domain, and the credentials, and "you can transfer them when the contract ends." Avoid.
- The site is built on a custom plugin or framework that only this developer can maintain. Avoid.
- The code lives on the developer's local machine and gets uploaded via FTP. Avoid.
- The developer suggests an NDA for portfolio purposes that, on inspection, prevents you from sharing your own site's code with another developer. Read carefully.
A good developer expects to lose clients to retirement, change of scope, or the natural ending of a project. They build with that in mind. A developer who structures the relationship to make leaving difficult is signalling something important about how they think about the work.
4. "What's outside your scope?"
A working developer should be able to answer this one immediately. Anyone who claims they can do everything is either inexperienced, dishonest, or both.
The honest answers cluster around a few themes:
- Design: most developers can implement designs but can't produce them from scratch. Some can; most can't. Worth knowing which.
- Copywriting: same.
- SEO strategy: technical SEO (page speed, semantic markup, sitemaps) is fair game. Strategic SEO (keyword research, content planning, link building) is a different discipline.
- Marketing strategy, advertising, social media: not a developer's job, even if some developers will take it on.
- Customer support after launch: this should be defined before the contract starts, not after.
A developer who lists their limits clearly is comfortable saying no, which is the same skill that makes them comfortable saying "this isn't worth doing" during the build itself. A developer who claims to do everything will usually do most of it badly.
5. "How do you handle change requests?"
Every project has changes. The question is what happens when they arrive.
The conversation to listen for:
- Changes are normal, not an exception, and the developer expects them
- The estimate or scope is adjusted openly, not buried in the next invoice
- Small changes are handled within the existing engagement, not turned into separate billable conversations
- Significant changes are flagged early, with the cost implications surfaced before the work starts
The bad version is the developer who treats every change as a violation of the contract, slows the work down to negotiate, and turns a normal collaborative project into a defensive standoff. This pattern usually surfaces because the underlying engagement model (typically a fixed-price quote with no clear handling of scope changes) is wrong.
If the developer's answer to this question is some version of "any changes will require a change order," you're looking at a relationship that's structurally combative. Worth knowing before signing.
6. "What does ongoing maintenance look like?"
Most WordPress sites need somebody maintaining them after launch. Updates, backups, security monitoring, and the occasional fix when something behaves unexpectedly. The question is who that person is and what the arrangement looks like.
The good answers:
- The developer offers an ongoing maintenance arrangement, usually a small monthly retainer
- They're clear about what's included (updates, backups, security, response time) and what isn't (new features, redesigns, large changes)
- Cancellation is straightforward; you're not locked in
- The maintenance work is documented enough that someone else could take it over if the relationship ends
The bad answers:
- "I don't do maintenance." (You'll be hiring two developers.)
- "Maintenance is built into our hosting fees." (Bundled fees usually mean someone is being overcharged for hosting and undercharged for maintenance, or vice versa.)
- "Updates are automatic, you don't need to worry about it." (Automatic updates without a human looking at the result are a known cause of broken sites.)
7. "How long are your typical client relationships?"
A revealing question, and one most developers won't have a polished answer to.
The good answer: years. Long-term relationships in this industry are the strongest signal of a developer worth working with. They mean the developer ships work that lasts, communicates well, and adjusts as their clients' needs change. They also mean the developer isn't constantly in sales mode, which usually translates into more attention for actual work.
The neutral answer: project-based. Some developers genuinely prefer one-off engagements, and that can be the right fit for some kinds of work. Worth knowing if that's the structure.
The bad answer: silence, deflection, or a story about how the developer "graduated" past their old clients. Most clients leave for a reason, and the reason matters.
A short summary
The seven questions, condensed:
- Who actually does the work?
- How do you charge, and why?
- What happens to the work if I want to leave?
- What's outside your scope?
- How do you handle change requests?
- What does ongoing maintenance look like?
- How long are your typical client relationships?
If you ask all seven and the answers are clear, confident, and consistent with how the developer behaves in the conversation itself, you're probably in good hands. If any of them produces evasion, defensiveness, or marketing-speak, listen carefully to what's being avoided.
A note on the people who do this work well
The developers I most respect in this industry are the ones who'd answer all seven of these questions with a quiet, direct version of the truth, and who'd thank you for asking.
If you're at the stage of looking for a WordPress developer and these questions are the conversation you'd like to have, my services page covers what I do, my about page covers who I am, and you can get in touch any time. There's no expectation that an enquiry leads to a project.
If you'd rather work with someone else, the questions above still apply. Worth asking them.