WordPress portfolio, anonymised case shapes from real engagements

#How this portfolio is structured

This is not a logo wall. Most of our engagements are under NDA, which is normal for B2B WordPress work. Naming clients without written permission would be a small breach with a real cost to them, and we are not interested in that trade.

What you get instead, on this page:

• The shapes of work we actually take on, with the technical decisions called out
• Anonymised case studies with the before/after numbers we are allowed to publish
• An honest description of what we will and will not show on a discovery call

If you need named references, we can arrange them on a per-engagement basis after a discovery call, with the client’s prior consent.

#What we work on

A short, honest list rather than a category brochure:

• WordPress core builds with custom themes, ACF or block bindings, and a CI pipeline that runs PHPCS, theme check and a Lighthouse budget on every PR
• WooCommerce performance rebuilds, including plugin debt audits and replacing recurring functionality with site-specific code the client owns
• Headless WordPress with Astro or Next.js, fed by WP REST or WPGraphQL, deployed on Cloudflare Pages or Vercel
• WP multisite for franchisee networks and corporate intranets, with custom roles and SSO against Azure AD or Google Workspace
• Plugin and API integration work, often shipped as a composer package the client owns at the end of the engagement

#Stack we usually reach for

• WordPress on PHP 8.2 or 8.3, MariaDB, Redis object cache where the host supports it
• Astro and Next.js on the frontend for headless builds; React or Alpine for islands inside classic themes
• Cloudflare Pages, Cloudflare Workers, or Kinsta and Pressable for managed WordPress hosting
• Git workflow with PHPCS, theme check, and Lighthouse budgets enforced on PRs; Playwright for end-to-end where the project warrants it

Start a discovery call →

#The shapes of work we actually do

The first half of this page lists the canonical categories. This section is what those categories look like in real engagements, with the technical decisions called out. Names are removed; everything else is from real projects we shipped or maintain on retainer.

#Custom theme builds on WordPress core

Not block themes assembled from the library, and not a Divi reskin. We build classic or hybrid themes from a brief, with template parts mapped to ACF or block bindings, and a CI pipeline that runs PHPCS, theme check and a Lighthouse budget on every PR. Recent example: a publisher rebuilt from a 2018 custom theme stuck on PHP 7.4 and a deprecated Timber version. We rewrote the theme on PHP 8.3 with native blocks for the editorial team, kept the URL structure 1:1 to preserve SEO equity, and moved LCP from 2.4 s to ~700 ms on the article template.

#WooCommerce performance and plugin-debt rebuilds

The pattern we see most often: a store on 30+ plugins, three of them overlapping (two cache plugins, two image optimisers), checkout TTFB above 1.5 s, and nobody on the team willing to touch it. We audit plugin-by-plugin, move the recurring functionality (custom shipping rules, B2B pricing, EU VAT edge cases) into a small site-specific plugin we own with the client, and rebuild the cart and checkout templates. Anonymised result on the last large rebuild: 30+ plugins down to 12, checkout TTFB 1.8 s to 320 ms, no feature regressions reported in the first 90 days.

#Headless WordPress with Astro or Next.js

WordPress as the editorial backend, Astro or Next.js as the frontend, content fetched through WP REST or WPGraphQL at build time and revalidated on publish. We use this where the site has a content team who like Gutenberg but the marketing team needs a frontend that hits 95+ on Core Web Vitals without a cache plugin doing the heavy lifting. Recent shape: a B2B SaaS marketing site, ~600 pages, Astro on Cloudflare Pages, WordPress on a small managed host, deploys triggered from the WP admin via a webhook.

#Corporate intranets and multisite

WordPress multisite with custom user roles, SSO against Azure AD or Google Workspace, and content scoped per network. We have shipped a multi-tenant landing system on 8 networks of WP multisite for an agency that resells to franchisees, and a B2B intranet using WP REST + a headless React shell with Azure AD SSO and per-department capabilities. These projects are 80% access control and 20% UI; the interesting work is in the role matrix and the audit log.

#Plugin and integration development

Smaller engagements that look like one ticket but are usually three: a WooCommerce extension that pushes orders to a Polish accounting system over SOAP, a Gravity Forms add-on that signs PDFs through a third party API, a Gutenberg block library shared across a client’s three brands. We ship these as composer packages where the client’s stack supports it, and as classic plugins where it does not.

#How a typical engagement runs

No phase diagram and no “discovery to launch” stock copy. The honest version of how the work actually flows.

#Week one is reading, not writing

Before we touch the codebase we read it. PHPCS report, plugin list with last-update dates, hosting plan, current Core Web Vitals from CrUX, and the last 90 days of error logs if we can get them. By the end of week one the client has a written list of what we found and which items are doing the most damage. Sometimes the answer is “your hosting plan is the bottleneck and a code rewrite will not help” and we say that out loud.

#Staging matches production, or we do not deploy

Same PHP version, same MySQL version, same object cache, same WP version, same plugin set. If the client’s hosting cannot support a real staging environment, we set one up on our infrastructure for the duration of the project. Deploys are git-based with a rollback that takes under two minutes.

#Handover is documented in writing

Every project ends with a README in the repository covering: how to run it locally, how to deploy, where the secrets live, which plugins are load-bearing and why, and what to do when the WordPress 6.x update breaks something. Clients on retainer get this kept current. Clients leaving us for an in-house team get it as a parting deliverable so the next developer is not starting blind.

#Anonymised case shapes

Five projects we are allowed to describe without naming the client. The shape of the problem, the technical decision, and the numbers we have permission to publish.

#Publisher: 2018 custom theme rebuilt to a modern stack

A regional news publisher with around 12k articles. The theme was a 2018 build, custom but unmaintained, on PHP 7.4 and an old Timber. Article LCP was 2.4 s on the third-party CrUX percentile, and the editorial team could not embed modern blocks.

We rebuilt the theme on PHP 8.3 with native Gutenberg blocks for the editorial workflow, kept the permalink structure 1:1, and wrote a one-shot redirect map for the handful of taxonomy URLs that did change. Image pipeline moved to AVIF with a WebP fallback. Article LCP dropped to ~700 ms in CrUX after the second crawl cycle. Organic traffic was preserved through the cutover; we did not promise an uplift and did not get one in the first quarter, which is the honest expectation for a like-for-like rebuild.

#WooCommerce: 30+ plugins reduced to 12 plus custom code

A B2B store selling industrial parts across the EU. Checkout TTFB above 1.5 s, two cache plugins fighting each other, and a tax setup that depended on three separate plugins for VAT edge cases.

We audited each plugin, merged the recurring functionality (B2B pricing tiers, EU OSS VAT, country-specific shipping rules) into a single site-specific plugin under the client’s repository. Removed Elementor from the checkout funnel and rebuilt those templates as block patterns. Final state: 30+ plugins down to 12, checkout TTFB from 1.8 s to 320 ms on a fresh request, and a plugin update routine that no longer requires manual regression testing of the cart.

#SaaS: multi-tenant landing system on WP multisite

A SaaS company that wanted franchisees to run their own marketing pages without the head office reviewing every change. We built a WP multisite with 8 networks, a parent theme inherited by all networks, and per-network override capability for hero blocks, testimonials and contact forms. SSO against the central CRM. Each franchisee landing site builds in under 90 s on Cloudflare Pages.

#B2B intranet: WP REST plus headless React with Azure AD SSO

WordPress as the content backend (Gutenberg, custom post types for policies, projects and team directories), a headless React shell on the frontend, Azure AD SSO and per-department capabilities. Around 80% of the engagement was the role and capability matrix and the audit log; the visible UI was the smaller part. Content team kept their familiar editor; security team got the SSO and audit trail they needed for the compliance review.

#Plugin: WooCommerce to Polish accounting system

A small but representative integration: every paid order pushed into a Polish accounting platform over SOAP, with retries, an idempotency key, and an admin screen showing the last 200 sync attempts and their status. Shipped as a composer package the client owns. About three weeks of work, including the edge cases around refunds and partial fulfilment, which are usually where these integrations break in month two.

#What we will and will not show on a sales call

We will share repository access (read-only) for projects where the client has approved it. We will walk through a staging environment for in-flight work. We will name the technologies and the architecture decisions. We will give you references from clients who have agreed to be referenced, on a per-engagement basis.

We will not name clients who have not given written permission, paste screenshots of NDA work into a deck, or quote portfolio-wide averages we cannot back up with the underlying engagements. Pricing is individual to the engagement and we send a written proposal after the discovery call.

Start a discovery call →