Choosing a Web Stack in 2026 | WordPress vs Custom PHP

Stack debates online are often identity battles. Real projects are trade-offs: who edits content, how complex checkout is, what must integrate, and who maintains the site after launch day.

This is a practical decision frame — technical enough to be useful, plain enough for non-developers in the room. The “best stack in 2026” is the one that fits your workflows, risk tolerance and care budget — not the one winning Twitter arguments this month.

Four practical lanes

WordPress — marketing sites, content-heavy brands, editor handoff, many plugins when chosen carefully
WooCommerce — product shops that want WordPress + cart in one place
Custom PHP (or similar server apps) — portals, memberships, odd workflows, tight control
Static / lighter stacks — brochure sites with rare updates and strong performance needs

Headless/Jamstack variants exist in each lane. They’re powerful — and they add moving parts (CMS, front-end host, previews, auth). Use them when the benefits outweigh the ops cost.

The best stack is the one your team will operate without fear.

Questions that decide it

How often does non-technical staff change content?
Do you need true ecommerce or a few payment links?
Any CRM, booking, ERP or inventory integration?
What’s the budget for care after launch?
Do you need multi-language, roles, or audit trails?
Who is on-call when something breaks on a Friday?
Is SEO content volume a growth engine or a side page?
Do you need logged-in experiences with permissions?

Write answers down before comparing tools. Otherwise every demo looks like the answer.

WordPress: strengths and traps

Strengths: editing UX, ecosystem, SEO tooling, hiring pool, speed to a credible marketing site.

Traps: plugin soup, page-builder bloat, update negligence, “it was free until the breach”.

WordPress succeeds when you treat it like a product: minimal plugins, backups, staging, and a theme that isn’t a black box. A custom theme or tightly controlled block theme with a small plugin list often beats a flashy multipurpose theme that loads everything “just in case”.

Good fit: brochure + blog + lead forms + light integrations
Stretch fit: complex membership with many gate rules (possible, not always pleasant)
Poor fit: highly relational internal tools that only vaguely resemble “posts”

WooCommerce: when the shop is the product

Good when catalogue, orders and content live together. Plan for payments, shipping (parcels, rates, carriers), email deliverability, tax, stock and performance on category pages. Migrations from Shopify or Magento need redirects and cutover discipline — not just a theme install.

Also plan operationally:

Who fulfils orders and how refunds work
Which payment providers you actually need in the UK
How product data is kept clean (SKUs, variants, images)
Whether B2B pricing or customer-specific catalogues appear later

If you only sell two services with a deposit, a full cart stack may be heavier than Stripe payment links or a simple quote flow. Match commerce complexity to real order volume and catalogue shape.

Custom PHP / app backends

Choose this when data is relational and permissioned: client portals, approval workflows, invoice states, multi-tenant tools. You own the schema and the UX. You also own security and deploy discipline — which is fine if that’s priced in.

Custom does not mean “from scratch forever”. It means:

Clear tables instead of meta soup
Auth and roles designed for your domain
Templates that match the workflow, not the CMS’s mental model
Composer packages for hard problems (mail, PDF, HTTP) without adopting a whole product ecosystem you don’t need

Frameworks like Laravel help when the application surface is large. A thin custom PHP app still wins when the surface is focused and the hosting story must stay simple.

Static and hybrid

Static generation shines for mostly-read content with rare publishes. Hybrid models (static marketing + app subdomain) are common and healthy. Complexity appears when previews, auth and personalisation blur the lines — design that deliberately.

Static: fast, cheap to host, great for mostly fixed pages
Hybrid: marketing site static or WordPress; app on app. or portal.
Headless: when multi-channel content or front-end freedom justifies two systems

If your “static” site needs daily editor access from non-developers, you either train them on a Git-based workflow (rarely popular) or add a CMS — at which point you should re-check WordPress or a hosted CMS against true static.

Integrations change the math

A clean brochure site becomes a systems project when you must sync:

CRM pipelines and lead routing
Booking calendars and staff availability
Inventory and warehouse tools
Accounting and invoicing
Email platforms and consent records

Count the integration edges before choosing a stack for its homepage demo. Every edge is monitoring, auth, failure handling and someone to fix it when a vendor changes an API.

Cost is more than build price

Hosting and CDN
Plugin/SaaS subscriptions
Developer time for updates
Training editors
Incident response
Time lost when the wrong person can’t update a critical page

A cheap build with expensive care is not cheap. Ask for a year-two cost sketch, not only a launch quote.

Skills and hiring reality

The best theoretical architecture loses if nobody available can maintain it. In UK SME work, WordPress and PHP skills are widely available; niche edge stacks may mean higher day rates and longer lead times. That is a business fact, not a moral judgment about technology.

A simple recommendation matrix

Lead-gen brochure + blog → WordPress or well-built custom marketing site
Product catalogue + checkout → WooCommerce (or dedicated commerce if scale demands)
Logged-in client tools → custom app / portal
Docs/marketing with high cacheability → static/hybrid
Content hub + separate product app → split systems with shared brand tokens

Decision workshop (60 minutes)

List top five user jobs (e.g. “request quote”, “pay invoice”, “read case study”)
Mark which need a CMS editor vs application logic
List must-have integrations
Set a care budget (hours/month)
Pick the simplest lane that covers must-haves
Only then evaluate specific tools inside that lane

If two lanes both fit, prefer the one your operators already understand. Momentum beats novelty after launch.

Migration and lock-in

Every stack has an exit cost. WordPress content is relatively portable; deeply customised page-builder layouts are not. Custom schemas are portable if you own the database dumps and documentation. Headless setups often have the highest operational surface: CMS, front-end host, build pipeline, preview auth.

Export paths for content and media
URL structure you can redirect later
Avoid proprietary blocks that only one agency understands
Document integrations as contracts, not tribal knowledge

Choose as if you might need to hand the site to another developer in two years — because you might.

Red flags in stack proposals

“We’ll use twelve SaaS tools and glue them with Zapier” with no failure plan
A full SPA for five static service pages
No staging environment in the quote
Plugin list longer than the feature list
Hosting so cheap the support model is a ticket queue measured in days

Worked examples (stack decisions)

Not code for code’s sake — decision artefacts you can put in a project brief.

1) One-page stack brief (fill in)

Project: ____________________
Audience: ____________________
Editors (non-dev?): yes / no · how often: ____
Commerce: none / payment links / full cart
Integrations: CRM · booking · ERP · other: ____
Must own hosting: yes / no
Budget band: build £____ · care £____/mo
Non-goals (explicit): ____________________

Recommended lane:
[ ] WordPress marketing
[ ] WooCommerce
[ ] Custom PHP portal
[ ] Static / hybrid
Why (3 bullets):
1.
2.
3.

2) WordPress vs custom — feature test

// Pseudo checklist in code form
const needs = {
  richEditing: true,
  multiRoleWorkflow: true,
  relationalData: true,   // invoices, assets, approvals
  publicBlog: true,
  hardAuditTrail: true,
};

// Rule of thumb
if (needs.multiRoleWorkflow && needs.relationalData && needs.hardAuditTrail) {
  stack = 'custom-php-or-app'; // WP as marketing only
} else if (needs.richEditing && needs.publicBlog && !needs.relationalData) {
  stack = 'wordpress';
}

3) Hybrid architecture (common winner)

www.example.com     → WordPress (marketing + blog)
app.example.com     → Custom PHP portal (login, data)
cdn.example.com     → static assets

Shared: design tokens (CSS variables), brand logo, analytics ID
Separate: databases, auth cookies, deploy pipelines

4) Minimum ops for any stack

# Definition of "done" before go-live
- [ ] Staging URL matches PHP/Node version of production
- [ ] Backups: files + DB, off-site, restore tested
- [ ] HTTPS + admin 2FA where available
- [ ] Forms deliver to a real inbox (and spam-tested)
- [ ] Monitoring for 5xx / uptime
- [ ] Written handoff: how to edit, where DNS lives

Not sure which lane fits? Describe the business — I’ll map a path →