Introduction
Most small business WordPress sites are built the same way: install a popular theme, add a page builder, then keep adding plugins until the site does everything it needs to. A slider plugin, a forms plugin, a fonts plugin, a translation plugin, a caching plugin to speed up everything the other plugins slowed down. It works, at first. Then an update breaks the homepage, a plugin gets abandoned by its developer, or the site takes five seconds to load on a phone.
We build differently. In this post we’ll walk through the exact setup behind two real websites. We’ll call them Site A, a bilingual repair and equipment hire business, and Site B, a web design studio. They look nothing alike, but under the bonnet they share the same foundations: local development, version control on GitHub, a modern block theme, and a single library of custom blocks that moves from one project to the next.
You don’t need to understand the technical detail to benefit from it. But if you’re choosing someone to build or look after your website, it’s worth knowing what good foundations look like, and what questions to ask.
Building locally first with LocalWP
The problem. Plenty of websites are edited live. Someone logs into the dashboard, changes a setting or updates a plugin, and hopes for the best. If something breaks, your customers see it before you do.
Our approach. Every site we build starts life on our own computer, using a free tool called LocalWP. Local gives each website its own self-contained copy of WordPress, complete with its own web server, database and PHP version, running privately on our machine. Site A and Site B each have their own separate Local site, so work on one can never affect the other.
This means we can:
- Experiment safely. New layouts, new features and plugin updates are all tested locally first. If something goes wrong, nobody but us ever sees it.
- Work quickly. There’s no waiting for pages to upload to a server; changes appear instantly.
- Back up before every change. Before any update we take a full export of the site, so a problem becomes a one-click restore rather than an afternoon of debugging.
- Let AI work directly on the files. Because the whole site lives on our machine, an AI coding tool like Claude Code can read the theme and blocks, make a change, run the build and check the result, all without going anywhere near the live site.
- Pay nothing per edit. Previewing a page, rebuilding the blocks, comparing two versions or undoing a change costs nothing. There’s no meter running in the background (more on why that matters further down).
Only once something has been built, checked on desktop and mobile, and tested properly does it go anywhere near the live website.
Version control with Git and GitHub
What it is. Git is a tool that records every change made to a set of files: what changed, when, and why. GitHub is where those records are stored safely online. Software developers have worked this way for decades; it’s much rarer on small business websites.
What we track. On each project, the two pieces of code we write ourselves (the theme, which controls how the site looks, and the custom blocks plugin, which provides the building blocks for every page) each live in their own Git repository. Every single change gets its own entry with a plain-English description, such as “Make the navbar logo smaller on mobile” or “Add a colour picker to the Upsells section”. The blocks plugin on our own site has over 500 of these recorded changes.
Why that matters to you:
- Nothing is ever lost. If a design change turns out to be a mistake, we can roll back to exactly how it was before, even months later.
- There’s a clear history. If something behaves oddly, we can see precisely what changed and when, which turns a vague “the site looks wrong” into a fix in minutes.
- Your site isn’t locked to one computer. The code lives safely on GitHub, and on Site A every change is pushed there automatically the moment it’s saved.
WordPress itself and the handful of third-party plugins we use aren’t stored in Git, because their developers already version them. Those are covered by regular backups instead.
A modern block theme, not a page builder
The old way. Page builders let you drag and drop layouts, but they add a heavy layer of extra code on top of WordPress. Pages load slower, content gets locked into the builder’s own format, and switching away later can mean rebuilding every page.
The block theme way. Since WordPress introduced Full Site Editing, a theme can be built entirely from native WordPress blocks. Both of our example sites use a lightweight child theme built on top of Twenty Twenty-Five, WordPress’s own default theme. That gives us a stable, well-maintained foundation from the WordPress team, with only our design choices layered on top. In practice, the theme is a small set of files:
- A settings file (
theme.json) that defines content widths, layout rules and editor settings. - Templates and template parts for the header, footer, blog posts and 404 page.
- One stylesheet holding the site’s design.
Global CSS variables. Every colour, font, font size, spacing value and button style is defined once, in one place, as a named global CSS variable (for example, --clr-brand for the main brand colour). Every part of the site refers to those names rather than to raw colour codes. If a client wants a slightly different blue, we change it once and it updates everywhere, consistently. It also makes accessibility easier to manage: we aim for the strictest WCAG contrast level (AAA) and can check every colour pairing from a single list.
Self-hosted fonts. Rather than loading fonts from Google’s servers, the fonts are stored on the website itself. That’s one less outside service to depend on, slightly faster loading, and no visitor data sent to a third party just to display text, which matters for GDPR compliance for any business serving UK or EU customers.
Custom blocks you can edit like a document
WordPress pages are built from blocks: a heading block, a paragraph block, an image block and so on. The built-in blocks are fine for simple content, but a business website needs more: hero banners, pricing tables, FAQs, service grids, contact sections, testimonials.
Instead of buying a theme or plugin full of hundreds of features you’ll never use, we build our own library of custom blocks, each designed for a specific job. We follow a few strict rules:
- Every piece of visible text is editable. Headings, button labels, descriptions: you click on them in the editor and type, just like a document. You never have to touch code to change your own words.
- Settings live in the sidebar. Images, colours and on/off options sit in the side panel, so the page itself stays clean and easy to edit.
- Old content keeps working. When we improve a block’s design, we include instructions for WordPress to upgrade existing pages automatically, so you never open a page to find a “this block contains unexpected content” warning.
The result is an editing experience tailored to your business. You get exactly the blocks your pages need, and nothing that clutters the editor or slows the site down.
One set of blocks, many websites
This is where the approach really pays off.
It started with Site A. The custom blocks plugin was first built for the repair and hire business: hero banners, services grids, a rental booking form, a route map for finding the workshop, review cards and more.
Then we made it portable. Before reusing it, we reorganised the plugin so that nothing in it was specific to one business. Every default placeholder became generic English (“Your Headline Here”, “[email protected]”) rather than another language or real phone numbers. Anything that only made sense for Site A, such as page IDs, menus, the language setup and the admin site guide, moved out of the plugin and into that site’s own theme.
Then we adapted it. When we built Site B, we brought the same plugin across and adapted it rather than starting from scratch:
- A new look without touching the blocks. The plugin ships with neutral default colours. Each site’s theme overrides them with its own brand variables, so on Site B the brand colour became an accent blue and the fonts switched to Source Serif Pro for headings and Poppins for body text. The blocks themselves didn’t change; they simply picked up the new brand.
- Removing what didn’t apply. The language switcher, essential for Site A’s bilingual audience, was removed from Site B’s navigation.
- Adding what was missing. A web design studio needs different pages to a repair workshop, so we added new blocks for blog posts, a table of contents, pricing tables, case studies and social media graphics. Site A, meanwhile, gained blocks for its world: specification tables for hire equipment, a downloads section and a radial services diagram.
Today, Site A uses 32 custom blocks and Site B uses 62, all from the same shared foundation. Every improvement made for one project, such as a bug fix, an accessibility improvement or a better mobile layout, can be carried across to the next.
What that means for you. Your site is built on components that have already been tested on real, live websites. You benefit from the refinement already done on other projects without paying for it to be reinvented, and your budget goes on what makes your business different.
Fewer plugins, fewer problems
Every plugin is code written by someone else, running on your website. Each one is a potential security weakness, a potential conflict with another plugin, a little extra loading time, and often a yearly licence fee. Popular plugins are also the first place attackers look for vulnerabilities.
So we keep the list short. Each of our two example sites runs just three active plugins:
- Site B: the custom blocks plugin, Yoast SEO, and WPvivid for backups.
- Site A: the custom blocks plugin, Polylang for the two language versions of the site, and WPvivid for backups.
Here’s what we did instead of adding more:
- No page builder. Layouts are built from native WordPress blocks and our own custom blocks.
- No forms plugin. Contact, enquiry, rental booking and emergency repair forms are part of our own code, designed to match the site and sending straight to the business inbox.
- No fonts plugin. Fonts are self-hosted and loaded directly by the theme.
- No slider, gallery or layout add-ons. If a page needs a new kind of section, we build a block for exactly that job.
The benefits add up: faster pages, fewer things to update, fewer security risks, no surprise renewal fees, and a site that’s far less likely to break when WordPress itself updates. If you’d like to understand more about what keeping a site healthy involves, our beginner’s guide to WordPress website maintenance covers it in more detail.
Pro tip: where AI fits in (plus a free template)
We use AI coding tools, including Claude Code, as part of this workflow, but in a deliberately structured way.
- Written rules for every project. Each repository has its own instruction file describing the global CSS variables, naming conventions, accessibility targets and house style (British English, no placeholder content). The AI works within those rules, not around them.
- Small, recorded changes. Every change is committed to Git individually with a clear description, so every AI-assisted edit is visible, reviewable and reversible.
- Checklists and checks. A launch-readiness checklist covers content, SEO, accessibility, performance and security, and content edits are verified automatically after they’re saved to make sure nothing on the page has been corrupted.
For independent, regularly updated coverage of how AI coding tools like Claude Code behave in practice, follow Simon Willison’s writing on Claude Code on his weblog.
AI speeds up the repetitive work. The decisions about what your site should do, how it should look, and whether a change is actually right for your customers stay with a human.
Download our CLAUDE.md template. If you build WordPress sites with Claude Code yourself, you’re welcome to use a generic version of the instruction file behind this setup. It covers local development, the Git workflow, plugin policy, global CSS variables, accessibility, custom block conventions and safe content editing. Drop it into the root of your theme or plugin folder and replace the placeholders in square brackets with your own project details.
Local development vs credit-based AI builders like Lovable
AI website builders such as Lovable let you describe a website in a chat box and watch it appear. For a quick prototype, that’s genuinely impressive, and we’ve written before about where tools like Lovable fit, and where they fall short. The catch is how they’re priced.
Credits, not freedom. Lovable’s plans are sold by credits: a small daily allowance on the free plan, a larger monthly allowance on paid plans, and top-ups when you run out. Every message you send uses credits, and more complex requests use more of them. That includes asking it to fix something it got wrong a moment ago. Run out halfway through a build and you either wait for tomorrow’s allowance, buy more, or upgrade.
Why that matters over the life of a website. A website is never built once and left alone. It’s revised, extended and polished for years: new services, new pages, seasonal offers, a better layout for mobile. Under a credit model, every one of those changes is a metered cost attached to that project. The more a site grows, the more it costs just to keep working on it, and the pressure is always to do less.
It quietly limits creativity. When each attempt has a price, you stop experimenting. Trying three different homepage layouts costs three times as much as trying one, so the tempting choice is to accept the first version that’s good enough. Good design usually comes from the opposite habit: trying ideas, comparing them side by side and throwing most of them away.
How our local workflow is different:
- AI is one tool, not the whole workshop. We use Claude Code inside our local environment, alongside a code editor, Git and a browser. Hand edits, previews, builds, reverting a change, comparing versions: none of that touches an AI allowance at all.
- The only real limit is Claude usage. Our Claude plan is a fixed subscription with a usage allowance measured in tokens (roughly, the amount of text the AI reads and writes), which resets on a rolling basis. It isn’t tied to any one project, so there’s no per-site bill that grows with every revision.
- Good foundations make tokens go further. Because every project has its own CLAUDE.md rules, reusable blocks and global CSS variables, the AI doesn’t have to rediscover how the site works each time. A request like “make the download button match our other buttons” becomes a small, targeted edit rather than regenerating a whole page, which uses a fraction of the tokens.
- Experiments are free to throw away. With Git, we can try an idea on a separate branch, look at it on the local site and discard it in seconds. Because nothing is metered per attempt, we try more ideas, and the finished design is better for it.
- You own the result. The code sits in a Git repository and runs on standard WordPress hosting. You’re never paying a platform’s subscription just to keep being able to edit your own website.
Conclusion & next steps
A website doesn’t have to be a fragile stack of plugins held together by hope. Build it locally, track every change, use a lightweight block theme, reuse well-tested components and let AI speed up the work without a meter running on every idea, and you end up with a site that’s fast, secure, easy to edit and straightforward to look after for years.
That’s the setup behind every site we build, from a repair workshop to a design studio. If you’d like a website built on the same foundations, or you’re worried your current site has become slow and plugin-heavy, get in touch and we’ll take a look.