I get a lot of "are you available for freelance work?" emails. Maybe one in three describes a project I can actually scope from the message. The other two — and this isn't a complaint, it's a pattern — are missing the things a good freelancer needs to give you a useful reply.
This is the post I wish I could send back. It's a practical guide for hiring a freelance WordPress plugin or WooCommerce developer in 2026 — what to look for, what to ignore, and how to write a brief that gets you the right person fast.
1. What "WordPress developer" actually means
The term is dangerously broad. A WordPress developer can be:
- A theme builder who configures Elementor or Bricks for marketing sites.
- A plugin developer who writes PHP, registers custom post types, builds Gutenberg blocks, and ships extensions to wordpress.org.
- A WooCommerce engineer who lives inside checkout flows, payment gateways, subscriptions, and tax logic.
- A platform engineer who scales WordPress for 100K+ users — caching, queries, infrastructure, observability.
These are different people. Hiring a theme builder for a payment gateway project is going to end badly for everyone. The first question to answer — for yourself, before you brief anyone — is: what kind of work is this, really?
2. The five questions a good brief answers
If your initial outreach answers these, you'll get a thoughtful, scoped reply within a day. If it doesn't, you'll get either silence or a generic "let's hop on a call" that wastes both of our time.
- What does the plugin / store do today, and what should it do after? One paragraph each. Not a pitch — a description.
- Where does it live? WordPress.com vs self-hosted. Multisite or single. Existing stack (theme, page builder, hosting).
- How many users / orders / SKUs? This drives every architecture decision.
- What's the timeline and budget range? "Flexible" is not a budget. A range is fine — "$5K–$10K" or "4–6 weeks" is enough.
- What's already been tried? If you've worked with a previous developer, what worked, what didn't, why are you switching.
You don't need a spec. You need context. The spec is what we'll build together.
3. What to look for in a portfolio
Most portfolios are decorative. The signals that actually predict whether someone can ship for you:
- Public code. GitHub or wordpress.org — somewhere you can read what they've shipped. Stars and download counts are nice but secondary; the actual code quality is what matters.
- Production traffic. "Used by 100K stores" is a dramatically different signal than "personal project". Scale forces discipline.
- Writing. Engineers who write about their work tend to think about their work. Look for blog posts, talks, or detailed README files that explain the why.
- Maintenance behavior. Look at their open-source projects' issue trackers. Do they reply? Do they ship security patches? Or have the issues been open for two years?
4. Red flags
Things that should make you slow down:
- No tests, no CI, no version control hygiene. "I'll add tests later" usually means "I won't add tests".
- Estimates without questions. A freelancer who quotes you in the first reply hasn't read your brief. They're billing for time, not outcome.
- No deprecation discipline. Ask: "How do you handle a database schema change in a plugin with 50K active installs?" If they look confused, walk away. The right answer involves option versioning, reversible migrations, and backwards-compatible aliases — none of which are intuitive until you've been burned by a bad upgrade.
- All-or-nothing pricing. A senior freelancer can break work into milestones. Insist on it — it protects both sides.
5. Green flags
Things that correlate strongly with good outcomes:
- They ask about your end-users, not just your stack.
- They volunteer scope-shrinking ideas — "do you actually need X, or could we do Y for half the time?"
- They have opinions about your existing code, your hosting, your roadmap. Even if you disagree, opinion is a sign of someone who's seen this before.
- They write down decisions. Async-first, decision-log culture beats hour-long Zoom calls every time.
6. WooCommerce vs Shopify: a quick decision tree
Half the briefs I see are tagged "WordPress" but really mean "ecommerce" — and half of those would be better off on Shopify. A rough decision tree:
- Pick WooCommerce if you already run on WordPress, want full control of the data, need deep customization (custom checkout flows, multivendor, complex tax / B2B / subscriptions), and can handle the hosting and security responsibility.
- Pick Shopify if you want a managed checkout, plug-and-play payments globally, and you don't have a strong reason to own the database. The trade-off: less freedom, recurring per-transaction fees, app ecosystem lock-in.
- Pick something headless (SureCart, Shopify Storefront API, Saleor) if you want the marketing site on WordPress / Next.js but don't want to run Woo.
I've shipped all three. There's no universal right answer — the right answer depends on who's going to maintain it and what your actual growth path looks like.
7. How to start small
If you've never worked with a freelancer before, don't start with a six-month build. Start with a paid two-hour audit — a code review, an architecture review, or a performance audit. You learn how they think, they learn how you brief, and at the end you both have data to decide whether to go bigger.
Most freelancers worth hiring will agree to this. The ones who won't are usually trying to lock you into a retainer before you've seen them work.
If you're putting a brief together for a freelance WordPress, WooCommerce, or ecommerce project — drop me a line or book a 30-minute intro call. Even if I'm not the right fit, I'm happy to point you at someone who is.