How to Choose a WordPress Developer or Agency: A Hiring Guide

Knowing how to choose a WordPress developer is worth more than any plugin recommendation I could give you, because a good developer makes a hundred correct decisions you will never see, and a bad one leaves you with a site that is slow, fragile and expensive to rescue. I have spent twelve years on the receiving end of hiring conversations – over 500 WordPress projects for small businesses and agencies in Germany, the UK, the US and Australia – and I can usually tell within the first two emails whether a project will go well. Not because of budget, and not because of the country either side sits in, but because of a handful of signals that almost nobody checks.

This guide is my honest attempt to hand those signals over: whether you need a freelancer, an agency or a DIY page builder in the first place; where good developers actually hang out (and the truth about marketplaces); a vetting checklist you can run in half an hour; twelve questions to ask with what a good answer sounds like; the red flags that predict pain; how pricing really works, including my own rate; and how to structure a small paid test, a proper brief and a contract so the relationship survives past launch. I am one of the developers you might evaluate, so I will tell you what I would want a client to check about me.

Table of contents

• Freelancer vs agency vs DIY: which do you actually need?
• Where to find good WordPress developers
• The vetting checklist: 30 minutes that save you months
• 12 questions to ask before hiring (and what good answers sound like)
• Red flags that predict a bad outcome
• How pricing works: hourly vs fixed, offshore vs local
• Run a small paid test project first
• What a good brief looks like
• Contracts, ownership and the boring paperwork that matters
• Onboarding and the long-term relationship
• Frequently asked questions

Freelancer vs agency vs DIY: which do you actually need?

Before you hire anyone, be honest about which of three roads fits your project, because they are genuinely different products at genuinely different prices.

The DIY page builder route

Wix, Squarespace, or WordPress with Elementor or Divi and a template. If your budget is under EUR 500, your site is a simple brochure, and you have the patience to learn a builder, this is a legitimate answer and I say so even though I earn nothing from it. The trade-offs arrive later: slower pages, licence renewals, design compromises, and a ceiling you hit the moment you need something the builder does not do. I wrote a full comparison in custom WordPress development vs page builders if you are weighing this seriously.

The freelancer route

One person, usually a specialist, usually remote. You get direct access to the human who writes the code, lower overheads, and continuity – the person who built your site is the person who maintains it. The risk is concentration: one person can be ill, on holiday or overbooked. You manage that with documented handover, code you own, and realistic timelines, not by avoiding freelancers.

The agency route

A team: project manager, designer, developer, sometimes a strategist. You pay for coordination and redundancy, and for bigger projects – multi-stakeholder corporate sites, large stores, ongoing campaigns – that coordination is worth the money. For a 5-15 page business site or a standard WooCommerce store, you are often paying agency prices for what is, behind the curtain, one developer’s work anyway. Many agencies quietly subcontract the build to people like me – I described that whole model in white-label WordPress development for agencies.

My biased-but-honest summary: most small businesses reading this need a good freelancer; most large organisations need an agency; and the DIY route is fine until the site starts mattering to revenue. If you want to sanity-check the numbers above against a detailed breakdown, see how much a custom WordPress website costs.

Where to find good WordPress developers

Referrals: still the best signal

Ask business owners whose sites you admire who built them, and whether they would hire that person again. A referral answers the two questions a portfolio cannot: did the project finish on budget, and is the developer still answering emails a year later? Almost all of my own work comes this way, which tells you something about how the good end of this market operates – the busiest developers barely advertise.

Portfolios and personal sites

A developer’s own site is evidence you can test. Run it through PageSpeed Insights; if a WordPress specialist’s own homepage scores 60 on mobile, that is the standard they consider acceptable. Look for named technologies (custom themes, WooCommerce, specific APIs) rather than adjectives (“passionate”, “cutting-edge”), and for live links you can click rather than screenshots you cannot verify.

Communities

WordPress-specific spaces produce better matches than generic job boards: local WordPress meetup groups, WordCamp attendee lists, the makers listed on plugin and theme directories, and professional communities like Post Status. People who invest unpaid time in the WordPress ecosystem tend to be in it for the long term.

Marketplaces: the honest take

Upwork, Fiverr, Freelancer.com. Good developers do exist there – some excellent ones started there, me included, years ago – but the platforms optimise for price competition, so the rankings reward whoever bids lowest and fastest, not whoever builds best. If you use a marketplace, ignore the badges and star averages (nearly everyone has 4.9), read the written reviews for repeat clients, and apply the full vetting checklist below exactly as you would anywhere else. Expect to interview five to get one worth testing. And be aware that at EUR 3 per hour you are not hiring a cheaper version of the same service; you are hiring a different service that will need to be redone.

The vetting checklist: 30 minutes that save you months

Here is what I would check before spending an hour on calls with anyone, in the order I would check it.

1. Portfolio signals (10 minutes)

• Live URLs, not images. Screenshots can be of anything, including other people’s work. Click through to real sites.
• Relevant project types. A developer who has built ten restaurant sites will build your restaurant site faster and better than one who has built ten SaaS dashboards, however talented.
• Recency. Two or three projects from the last year matter more than twenty from 2019.
• Range within a lane. Custom themes, a store, an integration – some variety shows depth; total randomness shows nothing stuck.

2. Live-site checks (10 minutes)

• PageSpeed Insights on two portfolio sites. 85-100 on mobile says the developer cares about performance; 40 says they do not, and no amount of talk changes that. (Score drift happens after handover when clients install plugins, so check two sites, not one, and ask about any outlier.)
• Mobile behaviour. Open the sites on your phone. Tap the menu, fill a form field, rotate the screen. Half the web’s traffic is mobile; a broken hamburger menu on a portfolio piece is a confession.
• Code quality at a glance. View source: is there one reasonable set of stylesheets or forty render-blocking files? Run the homepage through validator.w3.org – a handful of warnings is normal, hundreds of errors is not. Check for a proper heading structure (one H1). You do not need to read PHP to spot chaos.
• Accessibility basics. Tab through a page with the keyboard. If you cannot see where focus is, users with disabilities cannot use the site, and in the EU and UK that is increasingly a legal problem, not just an ethical one.

3. The first email (the most predictive signal of all)

Send a short, real enquiry and read the reply like an examiner. After hundreds of these exchanges from my side of the table, I promise you: how someone handles the first email is how they will handle the project.

• Did they answer within a stated, reasonable time? A day is fine. Nine days is a preview of your launch week.
• Did they ask questions? A quote sent instantly with no questions means the scope was guessed. Good developers ask about goals, content, integrations and hosting before naming a number.
• Is the reply specific? “I would build this as a custom theme with three templates, roughly X hours” beats “yes we can do, best quality, kindly share details”.
• Did they push back on anything? The best early sign is a developer telling you something you proposed is unnecessary. Someone who says yes to everything before understanding anything will say yes right up until the deadline passes.

12 questions to ask before hiring (and what good answers sound like)

1. Can you show me two recent projects similar to mine, with results? Good answer: links plus a concrete outcome – a PageSpeed score, a load-time improvement, a conversion or enquiry increase. Weak answer: a wall of logos.
2. Will you build a custom theme or use a page builder, and why? Good answer: a reasoned recommendation for your case, with trade-offs. I build custom themes for most client work (here is what that theme development service covers), but a developer who sometimes says “a builder is enough for this” is showing judgement, not weakness.
3. Who exactly writes the code? Vital for agencies. Good answer: a name, a person, ideally someone you can talk to. Weak answer: “our team”.
4. What is your process from brief to launch? Good answer: a sequence you can repeat back – discovery, quote, staging build in milestones, review rounds, QA, launch, handover. Weak answer: “we’re flexible”.
5. Will I see the site during development? Good answer: a staging link from week one that you can open whenever you like. “We’ll reveal it when it’s ready” is a red flag dressed as showmanship.
6. How will I edit content after launch? Good answer: a walkthrough or short video showing the actual editing screens, and an offer to record one for your site. If updating a headline will require paying the developer forever, you want to know now.
7. What page speed will the finished site achieve, and how do you get there? Good answer: a number they commit to (I aim for 90+ mobile on standard pages) and mechanisms – image formats, font loading, minimal plugins, caching. Weak answer: “we install a speed plugin at the end”.
8. What happens about security, backups and updates after launch? Good answer: a concrete maintenance offer – update cadence, offsite backups, uptime monitoring, a monthly report – or an honest “I hand over to whoever runs your maintenance and security“. Weak answer: silence, which means the plan is “call me when it’s hacked”.
9. Fixed price or hourly, and how are scope changes handled? Good answer: fixed for defined builds, hourly for open-ended work, and changes priced in writing before they are built. Weak answer: a vague day rate and “we’ll see”.
10. Who owns the code, the design and the accounts? Good answer: “you do – domain, hosting, admin, repository, everything, in writing”. Any hesitation here should end the conversation.
11. What is your availability and response time during and after the project? Good answer: stated working days and a stated response window (mine: within 24 hours, Monday to Saturday). Weak answer: “always available”, which is never true.
12. What would you cut from my brief? My favourite question, and one almost nobody asks. A developer who can name something you do not need – a feature, an animation, a plugin – is optimising for your outcome. A developer who finds your entire wish list essential is optimising for the invoice.

You do not need perfect answers to all twelve. You need specific answers to all twelve. Specificity is the whole game.

Red flags that predict a bad outcome

These come from projects I have been hired to rescue, so they are ranked by how often they appeared in the wreckage.

• A quote with no questions asked. The single most reliable predictor. If nobody asked what the site is for, the number is fiction and the scope fight is pre-booked.
• Vague, bundled pricing. “Complete website: EUR 2,000” with no line items. You cannot compare it, and later you cannot dispute it. Ask for the quote itemised; watch how they react.
• No staging site. Building directly on a live domain, or refusing to show work in progress, means no safety net and no accountability until it is too late to change course.
• “Unlimited revisions”. It sounds generous; it actually signals that nothing is scoped, and in practice it converts into unlimited delay and mounting resentment on both sides. Professionals include one or two defined review rounds and price extra rounds honestly.
• The developer owns your hosting, domain or licences. The classic lock-in. If the site lives on their account and the theme licence is theirs, every future decision requires their permission. Everything should be registered to you from day one.
• No contract, or a one-line invoice instead of one. A contract protects both sides; refusing one protects only one side, and it is not yours.
• Nulled or “free premium” plugins. Pirated plugins are the way malware walks in through the front door. If the quote is impossibly low, this is often where the saving comes from.
• Guaranteed Google rankings. Nobody can guarantee rankings. A developer can guarantee clean markup, speed and correct technical SEO; anyone promising “position 1” is selling weather.
• Pressure to pay everything upfront. A deposit of 30-50% is normal and fair. 100% before any staging link exists is not.

One nuance: a single yellow flag with a good explanation is survivable. Two or more of the above together, walk away – the pattern does not improve after money changes hands.

How pricing works: hourly vs fixed, offshore vs local

Hourly vs fixed price

Fixed pricing suits defined deliverables: a design converted to a theme, a store build, a migration. You know the cost before you commit; the developer carries the estimation risk; changes are priced separately. Hourly suits open-ended work: maintenance, iterative improvements, “we’re not sure yet” projects. The trap is mismatching them – a fixed price on a fuzzy scope produces corner-cutting, and hourly billing on a defined build removes the developer’s incentive to be efficient. A fair pattern for fixed projects is 30-50% deposit, the balance at staging sign-off or launch; for hourly, weekly or fortnightly invoices with time reports.

Offshore vs local rates: the honest version

Rates for the same senior skill level vary enormously by geography: roughly EUR 80-150 per hour for senior freelancers in Germany, the UK or the US, EUR 40-80 in Eastern Europe, and EUR 10-25 for senior developers in India. I will be transparent, since I am asking you to trust this guide: my own rate is EUR 15 per hour, or a fixed price quoted within 24 hours, as a senior developer working offshore from India for European, UK, US and Australian clients. That is not a “cheap” rate for my market; it is a normal senior rate where I live, and the arbitrage is exactly why agencies white-label work to developers like me and resell it at local prices.

The honest caveats cut both ways. Offshore is not automatically good value: the marketplace race to the bottom is real, and a EUR 3 per hour build that takes 100 hours and then needs rebuilding costs more than a EUR 15 per hour build that takes 60 and lasts five years. Equally, local is not automatically better quality: you are partly paying for timezone overlap, same-language calls and local invoicing, which are genuinely worth money to some businesses and irrelevant to others. What actually predicts quality is everything in the vetting section above – portfolio evidence, live-site scores, and how the first email reads – none of which correlates with the country in the address. Judge the evidence, then let the rate be a pleasant surprise or a deliberate premium, whichever you prefer.

For context on total project budgets rather than rates, the ranges in the comparison table earlier line up with what I quote for custom WordPress development: simple business sites at the low end, stores and integration-heavy builds higher.

Run a small paid test project first

The best hiring decision is not made in an interview; it is made after a small, real, paid project. I recommend this to prospective clients even though it slows down my own sales, because it protects both of us.

How to structure it

1. Pick something real and bounded: a landing page from a design, a speed optimisation pass on your current site, one template, one small plugin or integration. Budget EUR 100-500, timeline under two weeks.
2. Write a mini-brief (see the next section) exactly as you would for the big project. Half of what you are testing is how they respond to your brief.
3. Pay properly. Never ask for free “sample work” – good developers decline it, so free tests select for the desperate. The test costs you a few hundred euros; a bad main-project hire costs you thousands plus months.
4. Agree the definition of done up front: for a landing page, for example – matches the design at three breakpoints, 90+ mobile PageSpeed, editable text and images, delivered on staging with a walkthrough.

What to evaluate

• Process, not just output. Did questions come before work? Did a staging link appear early? Were problems raised when found, or hidden until delivery?
• The result against the agreed definition – measured, not felt. Run PageSpeed yourself; open it on your phone yourself.
• Communication under mild pressure. Change one requirement midway (politely). The reaction – a priced options email vs sulking vs silent scope absorption that resurfaces later as resentment – tells you everything about the year ahead.
• The handover. Did you receive access, files and a short explanation without asking twice?

If the test goes well, you have a developer, a working relationship and a finished landing page. If it goes badly, you have lost EUR 300 and gained certainty – the cheapest lesson in this entire process.

What a good brief looks like

Half of “bad developer” stories I get called into are really bad brief stories. You do not need a 20-page requirements document; you need one page that answers what every developer will otherwise guess:

• Business context: what the company does, who visits the site, and the one action a visitor should take (call, buy, book, enquire).
• Scope: the page list, and for each page the sections you expect. If a design exists (Figma, XD, even a sketch), link it – and if you want to see how a designed file becomes a theme, I walked through it in Figma to WordPress.
• Functionality: forms, booking, payments, shop, multilingual, member areas, integrations with named tools (“syncs with our HubSpot” beats “CRM integration”).
• Content status: who writes the text, who supplies the photos, and what exists today. Late content is the number one cause of late launches – not development.
• Constraints: budget range, deadline and why it exists, hosting preferences, brand guidelines.
• Examples: two or three sites you like, with a sentence on what specifically you like about each.
• Definition of done: the measurable bar – performance score, browsers and devices, editability, training or documentation.

Sharing a budget range feels like giving away negotiating leverage; it is actually how you get a useful proposal. “EUR 3,000-4,000, what can you do well within that?” produces a shaped, honest answer. Hiding the number produces a guess, and the guessing costs you a week of back-and-forth.

Contracts, ownership and the boring paperwork that matters

You do not need a lawyer for a EUR 3,000 website, but you do need these points in writing – an email both sides confirm is enough at small scale:

• Scope: the deliverables list, attached to the quote. Everything not listed is a change request, priced before it is built. This one line prevents most disputes on both sides.
• Ownership: on final payment, you own the code, the design and the content. Domain and hosting accounts are registered in your name from day one, with the developer added as a collaborator – never the reverse.
• Licences: any premium theme or plugin licences are bought under your account, listed with renewal costs, so year two holds no surprises.
• Payment schedule: deposit, milestones, final payment, and what triggers each (staging sign-off, launch).
• Timeline with dependencies: the launch date and what you must deliver for it to hold (content by X, feedback within Y days). Fair contracts bind both sides.
• Warranty: a defined period – 30 days is common – in which defects are fixed free. New ideas are new work; broken features are not.
• Credentials and data: everything handed over via a password manager at launch; if the developer touches customer personal data, a simple data-processing note keeps EU and UK clients compliant.
• Exit clause: what happens if either side walks away mid-project – typically you pay for work done and receive the code as-is. Nobody plans to use it; its presence keeps everyone professional.

A developer who resists writing these down is telling you how the ambiguity will be used. A good one has a template ready, because this list protects them too.

Onboarding and the long-term relationship

The hire is not finished at the signature; the first two weeks set the pattern for everything after.

Onboarding well

1. One channel, one contact. Pick email, Slack or a project board and put every decision there. Three stakeholders sending conflicting WhatsApp messages is how projects drown.
2. Front-load the materials: brand assets, content, credentials (via a password manager), and access to anything the developer will integrate with.
3. Agree the rhythm: a weekly update – written or a short call – plus the always-open staging link. Then resist the urge to check in daily; you hired a professional, not a progress bar.
4. Give feedback in consolidated rounds: one numbered list per review, marked “must fix” vs “nice to have”, from one sender. This single habit compresses review cycles from weeks to days.

After launch: the relationship that pays for itself

The cheapest developer you will ever hire is the one who already knows your site. A developer with context fixes in one hour what would take a stranger a day of archaeology, quotes new features accurately because they wrote the foundations, and notices problems before you do. So keep the relationship warm: put a maintenance arrangement in place (monthly updates, backups, monitoring and small fixes – whether with your developer or a dedicated maintenance and security plan), batch small improvements quarterly instead of drip-feeding one-hour tasks, and ask for advice before committing to new tools – a developer who has shipped 500 projects has usually seen your next idea tried five ways and can tell you which one worked. Clients I have worked with for five or more years get faster turnarounds and better prices than new ones, for the unromantic reason that their projects carry no unknowns. That compounding is the real return on choosing carefully the first time.

Need help with your WordPress project?

If you are vetting developers right now, feel free to run every check in this guide on me: the custom WordPress development page explains how I work, the portfolio has live sites you can put through PageSpeed, and you can send me a message with a small test project or a one-page brief – I reply within 24 hours with questions first and a fixed quote after.

Frequently asked questions

How do I choose a WordPress developer?

Check live portfolio sites with PageSpeed and on your phone, ask the twelve questions in this guide and listen for specific answers, then run a small paid test project (EUR 100-500) before committing to the full build. The first email exchange predicts the whole project.

How much does it cost to hire a WordPress developer?

Senior hourly rates run roughly EUR 80-150 in Western Europe and the US, EUR 40-80 in Eastern Europe and EUR 10-25 offshore in India (mine is EUR 15). Typical custom business sites land between EUR 800 and 6,000 with a freelancer, and EUR 5,000-30,000+ with an agency.

Should I hire a freelancer or an agency?

For most small business sites and stores, a vetted senior freelancer offers better value and direct communication; agencies earn their premium on large, multi-stakeholder projects that need coordinated teams. Many agencies subcontract the actual build to freelancers anyway.

Are offshore WordPress developers any good?

The good ones are excellent and the bad ones are terrible – exactly like local developers. Judge evidence (live sites, scores, communication quality), not geography; the vetting checklist works identically at EUR 15 per hour and EUR 150 per hour.

What questions should I ask before hiring a WordPress developer?

The essentials: who writes the code, custom theme or page builder and why, will I see staging throughout, what PageSpeed score will the site achieve, who owns the code and accounts, and how are scope changes priced. Specific answers matter more than perfect ones.

What are the biggest red flags when hiring a WordPress developer?

A quote sent without a single question asked, no staging site, “unlimited revisions”, the developer owning your hosting or licences, no written contract, and demands for full payment upfront. Two or more together, walk away.

Is a paid test project really necessary?

It is the highest-value step in the whole process: a EUR 300 landing page or speed pass reveals process, communication and quality far better than any interview, and a bad outcome costs you a fraction of a failed main project.