Why do you use so few plugins when there is a plugin for everything?

Because every plugin is someone else's code running on your site, with its own update schedule, its own performance cost and its own security history. Twenty plugins means twenty things that can break during an update and twenty places a vulnerability can appear. Before we install one we ask whether the same result can be achieved in about ten minutes without it. Frequently it can, and the site is lighter and safer for the rest of its life.

Can I move to a different host later, or am I locked in?

You can move. WordPress is portable by design and the whole site — files and database — can be migrated to another host. That is one of the genuine advantages of this route over the hosted no-code platforms. What we would ask is that you tell us before moving, because the two things that usually break in a migration are email delivery and redirects, and both are easy to carry across if planned and painful to fix afterwards.

Do I really need a maintenance plan?

WordPress powers an enormous share of the web, which makes it the most-attacked platform on it. Core, themes and plugins all publish security updates, and an unmaintained site accumulates known holes that automated scanners find without any human targeting you. A plan means updates get applied and tested, backups are verified rather than assumed, and someone is watching. If you would rather handle it internally, we will set it up and train your team on exactly what to do.

My hosting is five dollars a month. Is that a problem?

Often it is the ceiling on everything else. On crowded shared hosting the server response time is the largest single number in a speed report, and no amount of image optimisation or caching moves it. We will measure it and tell you plainly. Sometimes the honest answer is that the most valuable thing you could buy is not a redesign but better hosting, and we would rather say that early than take a fee for work the server will undo.

Will a theme update wipe out the custom work you did?

Not the way we build it. Custom functionality goes into a small self-contained plugin rather than being pasted into the theme's functions file, so updating or even replacing the theme leaves it intact. This is a five-minute decision at build time that saves a genuinely expensive afternoon later, and it is one of the more common ways inherited WordPress sites lose functionality without anyone knowing why.

Can we add a shop to it later?

Yes, and it is worth saying up front that adding a store changes the nature of the project. Products, tax, shipping rules, payment, and order management are a substantial piece of work with their own testing burden, and they belong in their own quote rather than being tacked onto a brochure build. If a shop is likely within the year, tell us now so the structure and the hosting are chosen with that in mind.

Web Development & Engineering

A WordPress site your own team can actually run

Theme or custom build, a deliberately short plugin list, sensible hosting, real backups, and training so the site does not need us every time a word changes.

From: $500–$2,500
Typical time: 2–4 weeks
Usually bought by: Local businesses

What this actually solves

People choose WordPress for one of three practical reasons, and none of them is enthusiasm for the software. The first is that they are already on it and moving is a cost with no visible benefit. The second is budget against scope — they need a site plus a blog, plus forms, plus events, plus perhaps a small shop later, and this is the platform where all of that is available without commissioning each piece from scratch. The third is staff: someone in the office already knows WordPress, and retraining a team on an unfamiliar system is its own hidden expense.

The problem being solved is usually not that the site does not exist. It is that the existing one has become something nobody wants to touch. It loads slowly, half the plugins were installed by a developer who is no longer reachable, updates are avoided because the last one broke the layout, and nobody is certain whether the backups work because nobody has ever tried restoring one. The site has quietly become a liability that everyone is managing around.

So the aim of this build is not only a site that looks right on launch day. It is a site that is still fast and still updateable in two years, that your own team can edit without calling anyone, and that has a recovery path when something goes wrong — because on this platform, eventually, something will.

What we do, and in what order

Choose the hosting first. This decision governs the entire life of the site more than any other, which is why it is not left until the end. We check the server response time, whether staging environments are available as a one-click function, what the backup arrangement genuinely is, and what PHP version is running. If your current host is the constraint on everything downstream, we say so here rather than after you have paid for optimisation work it will cancel out. Half a day.
Install, choose the theme, and set the foundations. Clean install, theme selected or purchased, permalinks set to a readable structure before any content exists — changing URL structure after publishing means a redirect map, so it is done on day one. Then the short plugin list: forms, SEO, caching, security, backup, and nothing beyond that without a specific reason recorded. One to two days.
Build the pages, one at a time, checked on a phone. Each page is finished and opened on a real handset before the next is started. Page builders make it very easy to produce something that is immaculate at 1440 pixels and unusable at 375, and the only reliable defence is looking at it. Five to nine days.
Content, forms, and the SEO groundwork. Content loaded, every image compressed before upload rather than uploaded at full camera resolution and scaled down in the browser, alt text written, unique titles and descriptions per page, sitemap generated. Forms are tested by sending a real submission to your real inbox — WordPress mail delivery is a common silent failure and it gets verified, not assumed. Two to three days.
Speed, security and backups. Caching and compression configured, images served at sensible sizes, the login hardened, and an automated backup running to somewhere that is not the same server as the site. Then a restore is actually tested, because an untested backup is a belief rather than a safeguard. One to two days.
Staging review, launch checklist, and training. Your review happens on a staging copy, then one consolidated revision round. The launch checklist runs every time — links clicked for 404s, HTTPS forced, one of www or non-www chosen with the other redirected, the staging search-engine block removed, analytics confirmed receiving real data. Then handover, with a recorded walkthrough made on your own site covering the edits your team will actually be doing. Three to four days.

What moves the price

The range is $500–$2,500 over 2–4 weeks, and three things decide where a project lands inside it.

How far the theme is pushed. Using a well-built commercial theme close to how it was designed is quick. Bending it to match a bespoke design is not — every departure is another set of overrides to write and another thing to re-check after each update, and past a certain point building the design properly is cheaper than fighting a theme into it.

How many plugins need configuring rather than installing. Installing a form plugin takes minutes. Configuring a booking system with availability rules, buffers, staff calendars, deposits and confirmation emails takes days, and the difference is invisible in a plugin list. We quote from what each one has to do, not from how many there are.

Who supplies the content. As with any build, arriving with finished copy and prepared images moves a project towards the bottom of the range. Writing the copy, sourcing and preparing images, and migrating old blog posts are each real work with their own line in the proposal.

What usually goes wrong

The plugin pile. Every small requirement gets solved by installing another plugin, until the site is carrying twenty of them. It is slow, every update is a gamble, several of them overlap in what they do, and half of them were installed for a reason nobody can now remember. The discipline that prevents it is one question asked before each install — can this be done without a plugin in about ten minutes? — and the answer is yes more often than people expect.

Custom code pasted into the theme's functions file. It works, right up until the theme updates or gets replaced, at which point the tracking snippet, the custom form handler or the redirect quietly vanishes and nobody connects the two events. Anything custom belongs in its own small plugin, which survives theme changes and can be switched off cleanly when you are diagnosing a problem.

Launching a WordPress site with nothing arranged for maintenance. This is the mistake that produces the phone call six months later. Core and plugin updates stop being applied, a known vulnerability gets found by an automated scanner rather than a person, and the backup that everyone assumed was running turns out to be a checkbox nobody ever verified. Whether the ongoing care is ours or handled by your own team, it is agreed before launch — not after the site is already down.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Why do you use so few plugins when there is a plugin for everything?: Because every plugin is someone else's code running on your site, with its own update schedule, its own performance cost and its own security history. Twenty plugins means twenty things that can break during an update and twenty places a vulnerability can appear. Before we install one we ask whether the same result can be achieved in about ten minutes without it. Frequently it can, and the site is lighter and safer for the rest of its life.
Can I move to a different host later, or am I locked in?: You can move. WordPress is portable by design and the whole site — files and database — can be migrated to another host. That is one of the genuine advantages of this route over the hosted no-code platforms. What we would ask is that you tell us before moving, because the two things that usually break in a migration are email delivery and redirects, and both are easy to carry across if planned and painful to fix afterwards.
Do I really need a maintenance plan?: WordPress powers an enormous share of the web, which makes it the most-attacked platform on it. Core, themes and plugins all publish security updates, and an unmaintained site accumulates known holes that automated scanners find without any human targeting you. A plan means updates get applied and tested, backups are verified rather than assumed, and someone is watching. If you would rather handle it internally, we will set it up and train your team on exactly what to do.
My hosting is five dollars a month. Is that a problem?: Often it is the ceiling on everything else. On crowded shared hosting the server response time is the largest single number in a speed report, and no amount of image optimisation or caching moves it. We will measure it and tell you plainly. Sometimes the honest answer is that the most valuable thing you could buy is not a redesign but better hosting, and we would rather say that early than take a fee for work the server will undo.
Will a theme update wipe out the custom work you did?: Not the way we build it. Custom functionality goes into a small self-contained plugin rather than being pasted into the theme's functions file, so updating or even replacing the theme leaves it intact. This is a five-minute decision at build time that saves a genuinely expensive afternoon later, and it is one of the more common ways inherited WordPress sites lose functionality without anyone knowing why.
Can we add a shop to it later?: Yes, and it is worth saying up front that adding a store changes the nature of the project. Products, tax, shipping rules, payment, and order management are a substantial piece of work with their own testing burden, and they belong in their own quote rather than being tacked onto a brochure build. If a shop is likely within the year, tell us now so the structure and the hosting are chosen with that in mind.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about WordPress website All Web Development & Engineering services