Blog · WordPress

Hiring WordPress Help: Agencies, Freelancers, and Red Flags

Most WordPress hiring problems start before any code gets written. The client doesn’t know exactly what they need, the vendor doesn’t ask enough questions, and six months later nobody can agree on what was promised. Here’s how to scope the work, evaluate who you’re hiring, and structure the relationship so you keep control of your own site no matter what happens next.

Scope the work before you shop for help

Write down what you actually need in plain language. “Redesign” and “fix performance” mean different things to different people, and vague requests invite vague quotes. A good scope answers:

  • Is this a one-time project (build, migration, redesign) or ongoing work (maintenance, content, growth)?
  • What plugins, integrations, or custom functionality are non-negotiable?
  • Who owns hosting, domain, and email after the project ends?
  • What does “done” look like? A launched site, a passing Core Web Vitals report, a training session for your team?

If you can’t answer these yet, that’s fine, but say so up front. A competent agency or freelancer will help you scope during a discovery call rather than quoting blind. If they quote a fixed price without asking a single question about your goals, that’s worth noting.

Reading a portfolio the right way

Portfolios are marketing. Treat them as a starting point, not proof. A few things actually tell you something:

  • Load the sites they show you. Check them on a phone, on a slow connection if you can simulate one. A portfolio full of screenshots but sluggish live sites tells you design was prioritized over performance.
  • Ask about the stack, not just the look. What theme or page builder did they use, is it still maintained, did they build custom functionality as a plugin (portable) or hardcode it into a theme (not portable)?
  • Look for longevity. Sites launched years ago that are still online and updated suggest the vendor built something maintainable, not just something that survived the launch demo.
  • Ask for a client you can actually contact. Not a testimonial quote, a real person you can email with two or three questions about responsiveness and problem-solving.

Technical fluency also shows up in small ways during conversation. Someone who talks comfortably about caching layers, PHP versions, or how they’d structure a staging-to-production workflow is speaking from experience. Someone who can only describe things in marketing language (“we make your site blazing fast”) without specifics is worth probing further.

Freelancer or agency: different tradeoffs, not a rank order

Neither is automatically better. Freelancers tend to be cheaper, more flexible, and give you direct access to the person doing the work, but they’re a single point of failure if they get sick, get busy, or move on. Agencies offer redundancy and process (project managers, QA, documented handoffs) at a higher price, but you may end up talking to an account manager rather than the developer who actually knows your code.

For small, well-defined projects, a good freelancer is often the faster and cheaper path. For ongoing, business-critical sites, especially ones with custom functionality or compliance requirements, the redundancy an agency provides can be worth the premium. Match the structure to the stakes, not to habit.

Red flags worth walking away from

  • They want your login before any agreement exists. Reasonable due diligence (a read-only look, a staging clone) is fine. Full admin access before a signed scope or contract is not.
  • They’re vague about who owns what. Ask directly: do I own the domain, the hosting account, the theme license, the plugin licenses? If the answer is evasive, that’s a flag.
  • No documentation habit. If they can’t describe how they’ll hand off credentials, document customizations, or explain what they changed and why, expect problems later.
  • Pressure to sign a long maintenance contract immediately after the build. Good maintenance relationships are earned after a project goes well, not bundled in as a condition of doing the work at all.
  • Unwillingness to work within your existing hosting setup. A vendor insisting you must move hosting to “their” reseller account, with no separate login for you, is a control grab. You should always have direct access to your own hosting account, even if they manage it day to day.

What a fair maintenance contract looks like

Ongoing maintenance is legitimate work, WordPress core, themes, and plugins all need regular updates, and someone needs to watch for conflicts, broken updates, and security patches. A reasonable contract should spell out:

  • Update cadence (weekly is common) and what’s covered (core, themes, plugins, PHP version bumps).
  • Backup frequency and where backups are stored, ideally offsite from the primary host.
  • Response time commitments if something breaks.
  • What’s included versus billed separately (new features, content changes, design work).
  • An exit clause: what happens, and how quickly, if you want to leave.

Note that some of this overlaps with what a managed host handles automatically. ServerBorn, for instance, takes care of server-level backups, PHP version management, and caching configuration as part of hosting, which means a maintenance contract with your developer can focus narrowly on plugin updates, code changes, and support rather than duplicating infrastructure work you’re already paying for elsewhere.

The handover checklist

Whether the relationship ends amicably or not, insist on a clean handover. At minimum, you should end up with:

  1. Full admin access to WordPress, hosting control panel, domain registrar, and DNS (Cloudflare or otherwise), all under accounts you control, not the vendor’s.
  2. A list of all plugins and themes used, including any premium licenses and where they were purchased, so you can renew them yourself.
  3. Documentation of custom code: any custom plugin, theme child, or functions.php changes, with a plain-language note on what each piece does.
  4. A recent full backup (files and database) stored somewhere you control, separate from the host.
  5. Server and CLI access details if applicable, including any wp-cli scripts or cron jobs they set up on your behalf.
  6. A written summary of known issues, pending work, or technical debt, so the next person doesn’t start from zero.

Get this in writing as part of the original agreement, not as a favor requested after things go sideways. A vendor who resists documenting the handover terms before starting work is telling you something about how the relationship will end.

The takeaway

Good WordPress help is out there in both freelance and agency form, but the burden is on you to scope clearly, verify claims against live sites and real references, and lock in ownership and handover terms before work begins. Do that up front, and the rest of the relationship, whether it lasts one project or five years, stays on your terms.