Picking the wrong WordPress developer is one of the more expensive small mistakes a business can make. The site gets built, it looks fine and 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.
Most developers mean well, but cheap project-based work pushes everyone toward the same pattern: build, invoice, move on, hope nothing breaks. Finding a developer who breaks that pattern means asking different questions.
These are the ones we'd start with.
Five questions to ask first
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 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 they say "we build, you go find a hosting company afterwards," that is your answer. If they say "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 about image handling, caching and Core Web Vitals targets. They should also be able to tell you how they handle structured data, which accessibility standard they build to (WCAG 2.1 AA is the modern baseline), and how they test on real mobile devices.
A weak answer here usually means a weak build. Our post on Core Web Vitals covers why performance counts for 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 even when the developer means well, 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 "we'll look at it next week," and the problem sits on your live site until then.
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: whether they still load fast, have been kept current with security updates, and 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. Use the look of the portfolio to narrow the list, then decide on the other questions.
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 having someone local can carry more weight.
Agency size. A 40-person agency does not necessarily mean better outcomes than a 2-person team. Larger agencies have more process and more oversight; smaller teams often have more skin in the game. Either can work. The specific people doing the work make more difference than the size of the shop.
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 isn't automatically better, and a cheaper one isn't automatically worse. Look at whether the price covers work you need, done well. Cheap work that has to be redone ends up expensive, and premium work that includes the wrong things is wasted money.
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) runs on a different economic model than custom development, because the math doesn't work any other way.
What gets cut is mostly the work that doesn't show in a launch demo: discovery, performance, SEO basics and post-launch support. The real cost of a cheap redesign covers this in more detail.
That's not a moral judgment. Cheap work makes sense for early-stage businesses, internal tools and temporary brands. It's just a poor 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 sometimes subcontract the development work to people you never meet, or produce strategy decks that look impressive and translate poorly into the build. Work gets handed off between design, development and maintenance teams inside the same agency, and the senior people who sold the project are often not the junior people who execute it.
The honest middle is 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. That usually gives the best ratio of outcome to cost.
What the first conversation tells you
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 understand them.
The Hosterr take
We built our Design & Development service around the model we think works: the developer who builds the site is the one who 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 willing to say "we are not the right fit for this" when that's true, they are likely a good choice. 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.
