Hire a WordPress developer when updates scare your team or the layout breaks the moment someone edits a page, and do not hire a person whose plan is a pile of plugins. People usually ask whether they need a WordPress developer after the last freelancer disappears and nobody wants to touch the admin. The useful hire takes structure and leaves the words with the editor, and you can tell by what they agree to show you in the admin.
This guide covers hiring when updates scare the team, hiring when the layout breaks in the editor, why not to hire a pile of plugins, what the editor should keep, what to ask them to show in the admin, and how the work should proceed.
Takeaways
- Hire when the team skips updates, or when a normal edit breaks the layout.
- Do not hire a pile of plugins. Each plugin is a maintenance cost you will still own.
- The editor should keep the words. The developer should take the fields, the guardrails, and the subtraction.
- Ask them to show the editing path in the admin. A promise you cannot click is not a plan.
Hire When Updates Scare the Team
Fear is a practical signal. If the only person willing to click "update" is you, and you have stopped clicking, the site is already in trouble. WordPress, the theme, and the plugins move whether you update them or not, so skipping is not a neutral pause. It is a decision to let the stack get harder to reason about, and that is a reason to hire.
The hire is not "someone to click the button once." A single update without a backup you could restore is a stunt. WordPress Development includes making updates boring: a stack small enough to understand, a backup, and a person who can say what the update touches. If the candidate's first move is to add tools before they subtract, they are enlarging the fear.
Website Maintenance may be the ongoing shape of this hire: updates, backups, and small edits. Development is what you need first if the stack cannot be updated calmly at all. Do not buy a monthly habit for a site that breaks when the habit runs. Fix the break, then keep the habit.
Hire When the Layout Breaks in the Editor
The other clear signal is an edit. Someone changes a headline, or adds a paragraph that is longer than the sample, and the page falls apart. Columns overlap, the next step disappears, and the editor learns not to edit. From then on the site is a brochure, even though it lives in a system that was supposed to be editable.
That break is the developer's job. The editor is part of the product, not an afterthought, and a hire who does not repair the editing path has not touched the reason you called. Ask them to reproduce the break with you watching, then to show the same edit succeeding. A screenshot of a prettier homepage is not the same demonstration.
Sometimes the break is a tool inside a tool. A second page builder dropped on top of a theme that already had an editor gives people two ways to damage the layout and no way to know which screen is true. Hiring someone to add a third surface will not help, so hire someone who will pick one editor and make it safe.
Do Not Hire a Pile of Plugins
Do not hire someone whose plan is a pile of plugins. Plugins are a maintenance cost, not a badge. A proposal that leads with a shopping list of add-ons is telling you the diagnosis happened before they saw your site, and you will pay for the list at install and again every time something must be updated.
Ask what each plugin is for, in one sentence, and what they would remove to make room. A developer who cannot name a removal has not looked at the weight you are already carrying. The last freelancer may have left you a hallway of logos, and the next person should be willing to turn lights off.
There are plugins worth keeping, such as a form that matches the conversation or a backup you have actually restored in a test. Those earn their updates. "It is what we always install" does not. Your site is not their default stack, and your pages have jobs. Tools that do not serve a job are clutter, and clutter is what made updates scary.
If the plan is mostly plugins, you can pause before implementation. Initial Contact can include a list, but the Detailed Discussion should defend it. You are allowed to say that a shorter stack is the outcome you want, even if a longer one would be easier for them to reuse on the next client.
What the Editor Should Keep
Decide what a developer should take over and what the editor should keep. The editor keeps the words: service descriptions, names, the next step, and the sentences that have to stay true all belong to someone who knows the business. The developer takes the fields those words live in, the templates, and the parts of the admin that currently punish a mistake.
This split survives the freelancer disappearing, which is the wound you are hiring to close. If only the developer can change a sentence, you are one absence away from the same stuck site. If the editor can change structure they do not understand, you are one confident afternoon away from a broken layout. The admin should make the split obvious.
Show the split in a table you both agree to before implementation. You do not need a legal exhibit. You need a shared picture.
| The editor keeps | The developer takes | Neither should improvise |
|---|---|---|
| Headlines, body text, names, and images in real fields | The fields themselves, and the layout that must survive a long paragraph | A second editor on top of the one you chose |
| New pages that follow a pattern already on the site | A new pattern, when the job of the page does not fit | A plugin added because a tutorial recommended it |
| The truth of what the firm does | Guardrails so a mistake does not delete the navigation | Promises about traffic or enquiries from the cleanup |
When a request arrives later, point at the column. If it is the editor's, do not open a project. If it is the developer's, do not ask the editor to be brave.
What to Ask Them to Show in the Admin
Ask them to show you in the admin, on your site or on a copy of it, and not on a polished demo that has never met your paragraphs. Watching is the point, and a narrated tour you cannot repeat is a pitch.
Ask them to change a headline and a long paragraph on a service page, then reload the public page. The layout should still explain the work. Ask them to add a page from the pattern you agreed the editor keeps. Ask them to show the backup and say how a restore would go. Ask them to point at a plugin they would remove, and why. None of these requests require you to read code.
Ask them to show who is an administrator and who is an editor. Your business should keep an administrator login in its own name, and a developer who needs access can have a login of their own. A firm that will not share the owner role is not maintaining your site. They are holding it, which is exactly the lesson people learn when a freelancer disappears.
If they cannot show these things because the current site is too brittle, that is still information. The first work is then to make one page safely editable, not to reskin the homepage. You are allowed to sequence the hire that way, because looks are not the emergency. The admin is.
How the Work Should Proceed
Use the same order as any careful hire: Initial Contact, then Detailed Discussion, then Implementation. The order is the work. It is not a guarantee that the site will bring enquiries, rank, or even look different. It is a guarantee you can ask for, in the modest sense that you will not skip straight to a theme.
Initial Contact is the scare and the break. You show them the update you will not run, or the edit that ruins the page, and they tell you whether they start by subtracting. You notice if the answer is a plugin list, which is enough to decide whether a detailed discussion is worth the time.
The Detailed Discussion is the table of who keeps what, plus the list of what they will show in the admin. It is also the moment to say which sentences on the site are no longer true. A developer can rebuild a template around a vague line, and you will have spent the project preserving it. Website Redesign is a different job if the pages themselves no longer say what you do, so do not smuggle that into a maintenance rescue without admitting it.
Implementation follows the list you agreed. You watch the admin, you keep the owner login, and you leave with a stack someone can update and an editor who can change a page. If the freelancer's ghost is gone and the fear is gone, the hire worked. If you have more plugins and the same flinch, it did not.
Bring this to the first conversation:
- The update you are afraid to run, and what happened the last time someone tried.
- The page that breaks when edited, and the paragraph that breaks it.
- A list of plugins you know are installed, even if you do not know why.
- The name of the person who should keep the words, and the login the business must keep.
- Any sentence on the site you already know is untrue.
Questions
Do You Need a Developer Just to Change a Sentence?
Changing a sentence is the editor's job, once the fields are safe. You need a developer when that edit breaks the layout, or when the field does not exist. Hiring someone to type the words for you keeps the site dependent on them, which is the problem you already have.
What If the Last Freelancer Disappeared With the Login?
Regain an owner login before you hire the next person to build anything. The business's name should be on the account, and a new developer can help you recover access and should then use a login of their own. Do not trade one missing freelancer for another person who holds the only key.
Is a Plugin List a Reasonable Proposal?
Only after each plugin has a sentence and something else has been removed. A list by itself is a pile, and a pile is a maintenance cost. Ask what they would uninstall. If the answer is nothing, they have not looked at why updates scare you.
What Should They Show You Before You Call It Done?
A safe edit of a real paragraph, a new page from the pattern the editor keeps, a backup they can describe restoring, and the owner login in the business's name. Those are things you can watch in the admin, and a prettier homepage without those demonstrations is not the finish line.
Does a WordPress Cleanup Promise More Enquiries?
A calmer stack and a working editor make the site possible to keep true, but they do not create traffic or enquiries. The pages still have to explain the work, and a forecast attached to the cleanup is a claim the hire cannot support.
Conclusion
Hire when updates scare the team or the layout breaks when a page is edited, and do not hire someone whose plan is a pile of plugins. Let the editor keep the words, and ask the developer to show the safe path in the admin. Initial Contact, then Detailed Discussion, then Implementation will tell you whether they can.
If you want help deciding what a developer should take over, and what the editor should keep, Speak With Us.
