Picking the wrong WordPress developer is one of the more expensive small mistakes a business can make. The site gets built. It looks fine. The bills get paid. Then twelve months later the developer has stopped responding, the site has started rotting, and the cost of fixing the situation dwarfs whatever the build cost in the first place.
This is not because developers are bad people. It is because the incentive structure of cheap project-based work pushes everyone toward the same pattern: build, invoice, move on, hope nothing breaks. Picking a developer who breaks that pattern requires asking different questions.
Here is what to actually look for.
The five questions that matter most
1. Will the same person who builds it also maintain it?
The single most predictive question. Builds that get handed off to a different team six weeks after launch get neglected, rot quietly, and become someone else's problem to inherit. Developers who keep maintaining the sites they build make different decisions during the build because they know they will live with those decisions.
If the answer is "we build, you go find a hosting company afterwards," that is your answer. If the answer is "we build, host, and keep maintaining it as one engagement," that is a different model and usually a better one.
2. What stack will you use, and why?
Watch for vague answers. "We use WordPress" is not enough. "We use a Bootstrap-based starter theme with Elementor and a custom dashboard plugin we built" tells you a lot.
The stack determines portability, performance, maintainability, and your ability to leave if you ever want to. We covered our default stack and why we picked it in why we still build WordPress sites by hand. If a developer's stack starts with a builder you have not heard of and a marketplace theme, ask harder questions about why.
3. How do you handle performance, SEO, and accessibility?
These are the three areas that distinguish a competent build from a cheap one. None of them are visible at the launch demo. All of them affect the business 12 months in.
A good developer will have specific answers: image strategy, caching approach, Core Web Vitals targets, structured data approach, accessibility standard targeted (WCAG 2.1 AA is the modern baseline), how they test on real mobile devices.
A weak answer here is a leading indicator of a weak build. Core Web Vitals in the AI era covers why this matters more than it used to.
4. What does the engagement look like after launch?
The build is the small part of a site's life. The years after launch are when the real value (and cost) accrues.
Ask: who handles updates? Who is on the hook if something breaks? Who tests changes before they go live? What is the response time when there is a real problem? Is there a structured ongoing relationship, or is it "email us if anything comes up"?
The "email us if anything comes up" model usually fails not because the developer is unwilling, but because they are busy with other paying work. By the time you email, the developer has six other live projects they are juggling. Your urgent issue becomes a "we'll look at it next week" — and your business pays the difference.
5. Can you show me work that is two or three years old?
Anyone can show a launch portfolio of sites that look great on day one. The harder question is which of those sites still look great today. Which of them still load fast. Which of them have been kept current with security updates. Which of them still match the brand they were built for.
A developer with a portfolio of well-maintained 3-year-old work is showing you something different than a developer with a portfolio of beautiful launches that, when you look them up, are now slow, broken, or replaced.
Five things that are not as important as people think
The portfolio aesthetic. Beautiful screenshots in a portfolio mostly tell you that the designer can compose beautiful screenshots. They tell you less about whether the developer can build a site that works, performs, and lasts. Aesthetic is a filter, not a decision.
Local versus remote. The right developer in another city is much better than the wrong developer in yours. Modern remote tooling makes the geography largely irrelevant. The exception is regulated industries where local accountability matters.
Agency size. A 40-person agency does not necessarily mean better outcomes than a 2-person team. Larger agencies have more process and more accountability; smaller teams often have more skin in the game. Both shapes work. The shape matters less than the specific people doing the work.
Number of years in business. Useful as a tiebreaker, weak as a primary signal. There are excellent five-year-old shops and mediocre twenty-year-old ones.
Hourly rate. A more expensive developer is not automatically better. A cheaper one is not automatically worse. What matters is whether the price reflects work you actually need, done well. Cheap work that needs to be redone is expensive. Premium work that includes the wrong things is wasteful.
Where cheap usually goes wrong
The very cheap end of the market — sub-$2,000 builds, $50/hr fixed-quote shops, offshore template-based work — operates on a different economic model than custom development. It has to. The math does not work otherwise.
What gets cut: discovery, real strategy, performance, SEO basics, accessibility, editorial workflow, post-launch support. The real cost of a cheap redesign covers this in more detail.
This is not a moral judgment. There are legitimate use cases for cheap work — early-stage businesses, internal tools, temporary brands. It just is not a fit for a business website that needs to perform and last.
Where premium usually goes wrong
The very expensive end has its own failure modes. Large agencies that subcontract the actual development work to people you never meet. Strategy decks that look impressive and translate poorly into the build. Hand-off problems between design, development, and maintenance teams within the same agency. Senior people who sold the project and junior people who execute it.
The honest middle — a small team or boutique shop that does the work directly, picks a maintainable stack, builds with the long-term in mind, and keeps the relationship after launch — usually offers the best ratio of outcome to cost.
How to evaluate the conversation, not just the deliverables
The most useful signals come from the discovery conversation itself.
Are they asking real questions about your business, your customers, your conversion path, your editorial workflow? Or are they asking "what do you want it to look like" and "can we use your existing logo"?
Do they push back on requests that do not make sense? Or do they agree to everything? Agreement feels nice during the sale. It usually means an inexperienced developer or one who plans to bill change orders heavily later.
Are they honest about what they do not do? A developer who tries to be everything to everyone is usually trying to be too many things to do any of them well.
Do they explain trade-offs in plain English? Or do they hide behind jargon? The ones who explain trade-offs clearly tend to be the ones who actually understand them.
The Hosterr take
We built our Design & Development service around the model we think actually works: the same small team that builds the site is the team that hosts and maintains it. That alignment changes the incentives during the build, and it removes the handoff problem after launch.
Whether you talk to us or to someone else, the questions above are the ones we would ask. If a developer answers them well — and is honest when the answer is "we are not the right fit for this" — they are likely a good partner. If they cannot answer them, or answer them with confidence that does not survive a follow-up question, keep looking.
If you want a read on a project you are scoping, tell us about it. We will give you an honest take, including who else you might want to talk to.
