WordPress development and maintenance

Hire WordPress developers who also keep the site running

You have a WordPress site that takes more attention than it earns, or you are about to commission one. From day one, every line of code is your intellectual property.

Tell us about the site

Send the address, or the brief. You get a straight read of what is there, from a software engineer.

How we handle what you send is set out in our privacy notice.

Two situations land here

  • You inherited the site

    The agency that built it moved on, or the developer who knew it did. Updates are overdue because nobody is certain what they will break. A site owner writing on a public developer forum in 2024 put it plainly. 'The WordPress website then languishes when the agency or dev vanishes, WordPress gets hacked, and the client gets charged again.' The harder part is that you chose the last vendor, and defended that choice to people who remember.

  • You are about to commission one

    You have proposals in front of you and no shared basis for reading one against another. The question you keep returning to is who is holding this in year two. Another owner, on the same forum in 2023, described where it ends up. 'I've seen sites with nearly a hundred plugins installed.' Nobody sets out to build that. It arrives one reasonable decision at a time.

The platform is not usually where a WordPress site breaks. What somebody added to it is. Patchstack, in its State of WordPress Security in 2026, counted 11,334 new vulnerabilities disclosed across the WordPress ecosystem during 2025. Six were in WordPress core. The rest sat in the parts a person chose, installed and then stopped thinking about. Patchstack removed 481 components for abandonment in 2023, and 147 in 2022. So the useful question is not whether WordPress is safe. It is which of the add-ons you carry still has somebody behind it.

Show data table
Two shares of one total. Core accounted for 6 of the 11,334, a count rather than a share, so it is not drawn. Patchstack recorded 4,124 of the disclosures, 36 percent, as an actual threat, and 1,966, 17 percent, as high severity. A disclosed vulnerability is not a hacked site, and nothing here counts sites or breaches.
Segment Value (%) Share
Plugins 91 91%
Themes 9 9%
Patchstack, 2025: where 11,334 disclosed WordPress vulnerabilities were found Two shares of one total. Core accounted for 6 of the 11,334, a count rather than a share, so it is not drawn. Patchstack recorded 4,124 of the disclosures, 36 percent, as an actual threat, and 1,966, 17 percent, as high severity. A disclosed vulnerability is not a hacked site, and nothing here counts sites or breaches. Patchstack, State of WordPress Security in 2026, data updated 25 February 2026.

The theme, the plugins and your content emit most of what a page sends to a browser. Each of those was chosen by somebody.

The layers of a WordPress site

  1. 01

    Host and the language runtime

    The machine, web server and PHP version your site runs on.

    Hands upward

    Serves every request the layers above produce.

  2. 02

    WordPress core

    The publishing system, on its own release schedule.

    Hands upward

    Hands each request to a theme and active plugins.

  3. 03

    Theme, bespoke or page builder

    Decides how a page looks, and most of the markup it emits.

    Hands upward

    Hands that markup to the browser, accessibility and all.

  4. 04

    Plugins, including paid extensions

    Anything core does not do. Somebody else's code, on your site.

    Hands upward

    Adds markup, tables and scheduled jobs of its own.

  5. 05

    Custom code written into the theme

    Work done in the theme, not a plugin. This is our layer.

    Hands upward

    We write, review and document it, in your repositories.

We write layer five, and we say so. Four questions apply to the other five layers: who applies updates and how often, what happens when an update breaks something else, who is reachable when it does, and whose account paid extensions renew in.

One more layer runs under all five: the database, your media and your content. Everything published, plus what every layer above wrote. It outlives the rest, so it moves first.

How a WordPress engagement runs, in order

Four steps, the same engineers in all of them, and the estate is looked at before anything is committed.

  1. Assess

    We inventory every plugin and check which still have somebody maintaining them. We check PHP and core versions, theme provenance, and the custom code sitting inside it. Database health comes next, along with whether a backup actually restores. Any documentation we produce is yours to keep. Nobody is asked to commit to a build before anyone has opened the site.

  2. Remediate, or build

    Remediation cannot be scoped honestly until the assessment is done, which is why it is second. A new build starts here instead. Either way, delivery runs against an agreed scope, and a change to that scope flows through a documented change note.

  3. Review, on every change

    Code review by a senior software engineer, every time. Unit tests and integration tests run, and continuous integration gates each merge before anything reaches your site.

  4. Care, with the same people

    The engineers who wrote the code keep it running. Code lives in your repositories, deployments in your cloud accounts, documentation stays current. If you offboard us, you keep all of it, including the runbook.

The assessment is the first real step. Send us the site and you get a read of what is in it.

What working with us commits us to, before you have spoken to anyone

All of it is checkable against whatever you are later sent.

  • Delivery runs against an agreed scope. A change to that scope flows through a documented change note. That holds during the build, and afterwards on an ongoing-care arrangement.
  • A core team assigned only to your project, with a lead software engineer you can talk to directly. No rotation, no context-switching, no handoffs you did not agree to.
  • Documentation starts on day one and stays current through delivery.
  • Code lives in your repositories, and deployments in your cloud accounts. Any documentation we produce is yours to keep.
  • If you offboard us, you keep everything, including the operational runbook. The handoff is a process, not a hostage situation.
  • Every change goes through code review by a senior software engineer. Tests and continuous integration gate every merge.

We are not putting a WordPress client outcome in front of you. We do not have one we can publish and stand behind. Saying so is cheaper than dressing up something adjacent. What we can hand you is our own WordPress engineering writing. Five pieces carry the WordPress category in our index. A sixth compares WordPress with another stack and is filed elsewhere, so it is linked and not counted. Four of those five are below. The fifth, why WordPress still uses serialization and not JSON, is an 11 min read on a decision inside core and what it costs your data. The sixth is WordPress compared with Laravel in 2026, an 8 min read.

What we can show you

WebAIM, the accessibility centre at Utah State University, crawled one million home pages in February 2026

It counted detected failures against the Web Content Accessibility Guidelines, version 2, including the quarter of that sample running WordPress.

95.9%of the 1,000,000 home pages had detected WCAG 2 failures

WebAIM Million, February 2026

56.1detected errors per page, across all 1,000,000

WebAIM Million, February 2026

52.8detected errors per page, across the 252,302 running WordPress

WebAIM Million, February 2026

*Disclaimer: Detection is a floor, not a verdict: automated tools cannot find every conformance failure, and a page with no detected errors is not thereby accessible or conformant. WebAIM publishes no failure rate by content management system, and none of these rows attributes a cause.

We build front ends that meet WCAG 2.2 by default. That is the World Wide Web Consortium recommendation of 5 October 2023, revised 12 December 2024. Higher compliance targets are supported on request.

Four shapes of WordPress work

Four shapes, so you can find yours. The last row is what moves the size, and it is what has to be looked at first.

Four shapes of WordPress work, compared across what you get, what is excluded, and what moves the size
AssessmentRemediationBuildOngoing care
What comes out of itA written read of the estate, yours to keep.A site patched, tested and documented.A new site, against an agreed scope.The same engineers, keeping it running.
What is not in itNo code changes yet, and no commitment to a build.Not a redesign, and not a rebuild renamed.Not content writing, unless the agreed scope says so.No contractual response time or uptime figure. We do not publish one.
What moves the sizePlugin count, and how much custom code sits in the theme.Commerce, membership or learning management, and how far behind the versions sit.Bespoke theme or page-builder pile, and whether content is migrated.How much is bespoke, and how many paid extensions are in play.

Whether existing content is migrated, and by whom, is part of the agreed scope, in or out. Any change to it flows through a documented change note. Ask for that same line, in that same form, from everyone else bidding.

Before weighing this against hiring somebody, look at what the hire costs. In the United States the median annual wage for web developers was $92,650 in May 2025. The Bureau of Labor Statistics publishes that figure. About 86,000 people were in employment. Benefits and employer taxes are not in that figure.

Show data table
The wage line and the benefit share each come from a named agency. The total does not: about $132,500 is our arithmetic over their two figures. The 30.1 percent benefit share is an economy-wide average across civilian workers. Neither agency publishes it for web developers alone. Neither publishes a WordPress-specific wage either, and the occupation is wider than WordPress work. The Office for National Statistics gives a United Kingdom equivalent: £43,821 median gross annual pay, April 2024, across about 12,000 full-time jobs. Employer National Insurance adds roughly £5,823 a year. The Office for National Statistics classes that median as acceptable rather than precise.
Item US dollars
Median annual wage, web developers, May 2025 92,650
Wage plus employer benefits and taxes, about 43 percent on top of the wage 132,545
Bureau of Labor Statistics data, United States: what one salaried web developer costs an employer The wage line and the benefit share each come from a named agency. The total does not: about $132,500 is our arithmetic over their two figures. The 30.1 percent benefit share is an economy-wide average across civilian workers. Neither agency publishes it for web developers alone. Neither publishes a WordPress-specific wage either, and the occupation is wider than WordPress work. The Office for National Statistics gives a United Kingdom equivalent: £43,821 median gross annual pay, April 2024, across about 12,000 full-time jobs. Employer National Insurance adds roughly £5,823 a year. The Office for National Statistics classes that median as acceptable rather than precise. Wages: US Bureau of Labor Statistics, May 2025, and the Office for National Statistics Annual Survey of Hours and Earnings, April 2024. Benefit share: Employer Costs for Employee Compensation, March 2026. Employer National Insurance: GOV.UK, 2026-27.

We would rather lose this now than in month four. Here are the situations where we are not the answer, and where to look instead.

When we are the wrong call

  • Most engagements continue past launch as ongoing maintenance and growth work. Our longest active partnership has run more than a decade.

  • Overlap commitments are agreed at scoping, so expectations are clear from day one.

  • The engineers who wrote your code are the ones who keep it running.

Better places to look

Four facts, in the order they are asked

Whoever approves this will ask four things, roughly in this order, and none of the answers needs them to read anything else.

Forward this part

What to tell whoever signs

  • What we own at the end You do. Code in your repositories, deployments in your cloud accounts, keys handed over, documentation yours to keep. If we part company you keep all of it, runbook included.
  • How scope is handled Delivery runs against an agreed scope. Any change to it flows through a documented change note. That holds during the build and afterwards, on an ongoing-care arrangement.
  • How the size gets decided The estate is assessed first. What moves the size: plugin count, custom code in the theme, whether commerce or membership is involved, and whether content is migrated.
  • What the alternative costs One salaried web developer in the United States: a $92,650 median wage in May 2025, from the Bureau of Labor Statistics. About $132,500 once employer benefits and taxes are added, which is our arithmetic.

Send us the site or the brief

Hiring WordPress developers: the questions, answered

The six that arrive first, answered before the call.

Do you write custom code, or assemble plugins?
We write custom code: themes, plugins and headless builds. A maintained plugin gets used where it does the job. Everything we add is reviewed by a senior software engineer before it merges.

How we structure a large WordPress codebase

What is not included, and is content migration in it?
Content migration is part of the agreed scope, in or out. Any change to it flows through a documented change note. Ask for that same line, in that same form, from everyone else bidding.

Content platform builds

What happens when a plugin we depend on is abandoned?
A plugin pulled from the directory is closed rather than deleted. That is the wordpress.org plugin directory's own published policy. Downloads stop and the source stays readable, so the code can be forked. The reason is withheld for sixty days, then shown only as a broad category. The assessment checks maintenance status.

How plugins hook into a request

Who is at the keyboard, and what if that person leaves?
A core team assigned only to your project, with a lead software engineer you can talk to directly. Nobody rotates off it, and no handoff happens that you have not agreed to. Every change is reviewed by a senior software engineer.

What ongoing support covers

What happens when an update breaks the site?
Every change goes through code review by a senior software engineer. Unit tests, integration tests and continuous integration gate the merge. We publish no repair window, and will not pretend to one.

How we handle security work

What do we own, and can we take it elsewhere?
From day one, every line of code is your intellectual property. Code sits in your repositories and deployments in your cloud accounts. Where we set those up, the keys are handed over. If you offboard us you keep everything, including the runbook.

How a build runs

Still holding a question this did not answer?

Send us the site, or the brief

Two things get you a straight answer. The address of the site you already have, or a description of the one you want built.

You get a read of what is actually there, from a software engineer who has opened it. Then either a plan, or a clear no. Both are useful; only one takes more of your time.

Tirth Bodawala
  • Any documentation we produce is yours to keep.
  • From day one, every line of code is your intellectual property.
  • Where we set up your repositories or cloud accounts, the keys are yours.

Tell us the site or the brief, and what is going wrong.

How we handle what you send is set out in our privacy notice.