Technical capabilities

Three kinds of project, all of them cases where a stock theme or a plugin stack stops being enough: commerce with non-standard logic, sites with accounts and restricted access, and multilingual corporate sites with real integrations.

Custom e-commerce and large catalogues

• WooCommerce with non-standard logic: tiered and conditional discounts, B2B accounts, wholesale pricing, customer-specific price lists.
• Catalogues in the thousands of products with faceted filters that return results without a page reload.
• Order and stock synchronisation with the systems the business already runs, over REST APIs.

Membership, courses and client portals

• Restricted-access sites built on MemberPress or Paid Memberships Pro.
• Course platforms, personal accounts, booking and scheduling systems.

Service sites and corporate portals

• Multilingual sites on WPML or Polylang, with content management that does not require a developer.
• Interactive pricing calculators and multi-step application forms wired to an API.

PHP 8.4 and MySQL 8.4 LTS on the server, modern JavaScript with SCSS and Vite in the browser, Docker locally, Git with feature branches. Versions matter here: PHP 8.1 stopped receiving security patches on 31 December 2025 and MySQL 8.0 reached end of life on 30 April 2026, so neither belongs under a site launched today.

Backend and WordPress

• PHP 8.4, object-oriented and strictly typed.
• WordPress with custom themes and plugins, custom post types and the REST API.
• WooCommerce with custom cart, checkout and pricing logic.
• MySQL 8.4 LTS, with indexing and query optimisation on catalogues that need it.

Frontend

• Modern JavaScript (ES modules) and SCSS.
• Vite for bundling, minification and asset optimisation.
• React for admin interfaces, where a manager needs a working screen rather than a form.

Environments and delivery

• Docker for local environments, so the site behaves the same on every machine.
• PowerShell and Bash automation for deployment, backups and synchronisation.
• Git with a feature-branch flow.

Integrations

• We support integrations with Shopify, HubSpot, Salesforce, Stripe, Zapier and Make.
• Beyond those, any service that exposes a REST API.

We build to the three Core Web Vitals thresholds Google publishes, and you can verify them yourself in PageSpeed Insights or Search Console: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1.

INP replaced FID in Core Web Vitals on 12 March 2024. It is the stricter measure: FID only timed the delay before the first interaction was handled, while INP watches every interaction through to the next frame on screen. Any technical document still written around FID predates that change.

How we get there

• Object and page caching, with Redis where the hosting supports it.
• Query profiling and rewriting, rather than caching a slow query and hoping.
• Modern image formats and deferred loading for everything outside the first screen.
• Third-party scripts kept out of the critical path, because chat widgets and pixels are the usual reason an otherwise fast page fails INP.

We deliver to WCAG 2.2 level AA, the current W3C recommendation published in October 2023. For anyone selling to consumers in the European Union this stopped being optional on 28 June 2025, when the European Accessibility Act came into force.

The Act applies by market, not by registration: a business outside the EU that sells to EU consumers is covered. The exemption is narrow and needs both conditions at once, fewer than 10 staff and under 2 million euro turnover. Services already on the market have until 2030, but a new site or a redesign is a new service and has to comply from the day it launches.

What that means in every build

• Full keyboard operation, with a logical tab order.
• A visible focus indicator that sticky headers and banners do not cover.
• Contrast of 4.5:1 for body text and 3:1 for large text and interface controls.
• Pointer targets of at least 24 by 24 CSS pixels, the WCAG 2.2 minimum.
• Labels on every form field, and errors written in plain language next to the field rather than signalled by colour alone.
• Meaningful alternative text, correct heading order, and a declared page language.
• Sign-in without puzzles or character-recognition tests, which WCAG 2.2 asks for directly.

Prepared statements, capability checks on every action that writes data, separated environments, a written update policy and backups that have actually been restored. Blocking SQL injection is a baseline, not a feature.

• Prepared database statements, input validation and sanitisation, escaped output.
• Nonces and capability checks on every action that changes data.
• Separated local, staging and production environments. Nobody tests on production.
• A policy for updating core, plugins and dependencies, rather than updating on impulse.
• Backups with periodic restore tests. A backup nobody has restored is not a backup.
• Platform versions that still receive security support, which is why the stack above names 8.4 and not 8.1.

We work both ways and we are not against builders. Elementor and the tools like it solve a real problem honestly, and if one fits your project we will build on it and support it. The question is not which is better in general, it is which is better for your case.

A builder is usually enough when

• You need to launch quickly and the structure is conventional.
• There are few pages and no unusual logic behind them.
• Your team wants to change everything themselves, without a developer in the loop.

A custom build pays for itself when

• Loading speed is part of the business case, not a nice-to-have.
• There is non-standard logic: pricing rules, accounts, integrations.
• The catalogue is large, or the site will be extended for years.
• The design has to be exact and stay that way after handover.

If you are already on a builder and it works for you, we will not try to talk you into moving. If you are hitting a wall on speed or on logic you cannot implement, that is a different conversation and worth having.

We build a set of finished design blocks in ACF Flexible Content. Your team assembles pages from them, reorders them and changes the content, and the design holds. That is our default.

• Flexible blocks for pages that vary: an about section, a slider, a gallery, text with an image.
• Simple fields for fixed templates where the structure never changes, such as a product card with a name, a price and specifications. There, filling in the data is the whole job.

• Markup built precisely to the Figma design.
• Responsive layouts for desktop, tablet and mobile.
• Technical SEO groundwork: semantic markup, correct heading order, structured data.
• Performance work against the Core Web Vitals thresholds above.
• Accessibility to WCAG 2.2 AA.
• Cross-browser testing.

What changes the scope and the timeline

None of these are hidden extras. They are the things worth naming at the start so an estimate is honest.

• Complex animation, including scroll-driven sequences, Lottie and 3D.
• Non-standard forms: multi-step, conditional logic, file uploads.
• Integrations with third-party systems and payment gateways.
• No mobile design in the handover, which means the mobile layout has to be designed as the build goes.