Choosing a Web Stack: An Honest Assessment

The question usually starts in the wrong place. "What platform should we use?" treats the decision as a feature comparison. WordPress has plugins. Shopify handles payments. Next.js has server components. Pick your checklist winner and ship it.

The better questions: What does this site need to do? Who updates it, and how often? What does maintenance look like in year three? What happens when the developer who built it isn't available?

I'm going to work through the stacks I actually use and recommend, with the honest tradeoffs for each. This isn't a vendor review. It's a decision framework built from building and maintaining real sites.

Vanilla HTML and Vite

The simplest option is often the most defensible.

A static site, plain HTML, CSS, and JavaScript with no server-side rendering, delivers pre-built files. The server isn't executing code on every request. There's no database. No plugin vulnerabilities. The attack surface is small: the web server and the files it serves.

Performance ceilings on static sites are higher than any CMS. Core Web Vitals scores near 100 are achievable and maintainable because nothing is fighting the render path. No PHP executing, no database queries, no plugin scripts loading before your content does.

Vite changes the development experience without changing the output. You write modern JavaScript with modules, import aliases, and TypeScript if you want it. Vite bundles it into optimized static files at build time. This site uses Vite for its asset pipeline: CSS and JS are compiled and fingerprinted by Vite, served by Apache.

The constraint is content editing. A static site has no admin panel. Changes go through a developer. For a marketing site updated once a quarter, that's not a problem. For a site with a content team posting daily, it's a dealbreaker.

Static is also not a synonym for simple. A Vite build pipeline, asset optimization, and a proper deployment workflow are real engineering. The simplicity is in the output, not necessarily the setup.

Right for: Portfolios, landing pages, documentation, single-purpose marketing sites. Any project where a developer handles all updates and performance is the primary constraint.

Not right for: Non-technical editors who need to update content without a developer. Sites with frequent publishing cycles. Anything with multiple contributors.

WordPress

WordPress runs 42.2% of all websites and 59.6% of the CMS market. Those figures are from W3Techs, updated daily, as of April 2026. That kind of adoption doesn't happen by accident. The content editing interface works. The plugin ecosystem covers most requirements. The developer community is enormous.

The performance cost of that adoption is documented. The 2024 HTTP Archive Web Almanac shows WordPress sites passing the "good" LCP threshold on mobile at a rate of 40%. The global web average is 63.4%. WordPress trails by 23 percentage points.

A WordPress install with 20 active plugins is a fundamentally different performance problem than one with three. A well-built site with a minimal plugin set, good caching, and quality hosting can perform well. Most WordPress sites aren't that, because most WordPress sites are set up quickly and left alone.

The security picture is nuanced. Patchstack's vulnerability database tracks 38,309 WordPress vulnerabilities, with 91% in plugins, not core. Sucuri's 2023 Hacked Website Report found that 95.5% of CMS-targeted infections involved WordPress. Sucuri themselves note this reflects market dominance more than inherent vulnerability. A lean, updated WordPress install is reasonably secure. An abandoned one with outdated plugins is not.

WordPress also gets unfairly trashed by developers who've only seen badly built sites. A custom theme, a small plugin set, a good host, and an update schedule produces a solid platform. The tool isn't the problem. Lazy installs are.

The maintenance reality is what clients should understand before choosing. WordPress requires active upkeep: core updates, plugin updates, PHP version compatibility, backup verification. A site that gets built and forgotten will drift from maintainability. That's not unique to WordPress, but the plugin ecosystem means there are more things to maintain.

Right for: Content-heavy sites where non-technical editors need regular access. Businesses with existing WordPress experience. Projects where moderate performance is acceptable and the plugin ecosystem fits the requirements.

Not right for: Performance-critical applications. Complex custom data structures that plugins can't express cleanly. Clients who won't commit to maintaining updates.

Headless CMS

Headless CMS separates the content layer from the presentation layer. The CMS stores and manages content. A frontend framework, typically Next.js, Astro, or Remix, fetches that content via API and handles rendering. The two systems are independent and can be deployed, rebuilt, or replaced without affecting each other.

Sanity, Contentful, and Payload are the mature options in 2026. Sanity offers a fully customizable editing studio. Contentful is enterprise-focused with strong editorial workflows. Payload is self-hosted and TypeScript-first, popular with developers who want direct control over the data model without a vendor hosting bill.

The architectural advantage is real. The frontend can be rebuilt without touching the content model. Content can be delivered to a website, a mobile app, and a digital display from the same data source. Because the frontend is typically statically generated at build time, the performance ceiling matches a hand-coded static site.

The cost is operational complexity. You're running two systems: the CMS and the frontend, each with its own hosting environment. Build times add latency between a content edit and a live update. On large sites, that can be minutes, which matters for news organizations and not at all for a plumber's booking page.

Infrastructure costs matter for smaller clients. Sanity's hosted tier starts free; production usage has real pricing. Contentful's free tier has limits. These are costs a client accustomed to $20/month WordPress hosting may not have budgeted for.

Right for: Organizations delivering content to multiple surfaces. Large content teams with editorial workflows. Projects with the budget for two infrastructure environments and ongoing technical support.

Not right for: Small businesses with one website and a single content editor. Projects under $10,000. Developers without Node.js experience managing the frontend.

Headless WordPress

Headless WordPress uses WordPress as the content backend, WPGraphQL to expose that content as a GraphQL API, and a separate frontend framework (typically Next.js) deployed on a platform like Vercel.

This is a legitimate architecture. It also gets oversimplified in developer conversations, where "just go headless WordPress" glosses over what you're actually committing to.

The value proposition is continuity. If you have an existing WordPress site with years of content and a content team that knows the admin panel, migrating to a pure headless CMS means migrating content and retraining editors. That's a real cost. Headless WordPress lets you decouple the frontend and get the performance benefits of a modern framework, without that migration overhead.

For teams already working in Next.js (17.9% of developers according to Stack Overflow's 2024 survey), WPGraphQL is a manageable integration. The tooling is mature and well-documented. Custom fields via ACF map to GraphQL cleanly enough that most editorial models translate without friction.

The honest cost is that you're still running WordPress. That means patching plugins, maintaining PHP hosting, managing the database, and staying on top of core updates, in addition to deploying and maintaining the Next.js frontend on Vercel. Two stacks, two hosting bills, two surfaces for things to break.

For a greenfield project, that cost calculus rarely makes sense. Starting from scratch, there's no continuity argument. You'd be inheriting WordPress's security surface, plugin overhead, and PHP hosting requirement without any transition-cost justification for doing so.

Right for: Established WordPress sites with substantial content and trained editors. Frontend teams already working in Next.js taking on a WordPress client. Projects where design or performance requirements exceed what a WordPress theme can deliver, and editor familiarity with WordPress is non-negotiable.

Not right for: New builds without existing WordPress content. Projects where the long-term maintainer doesn't have JavaScript experience. Small businesses where the cost of two environments isn't justified by the outcome.

Custom PHP

Custom PHP without a CMS framework is what I use for this site's routing and templating layer, and for client projects that need logic no existing platform handles cleanly. Vite handles the frontend asset pipeline on top of it, but there's no framework, no ORM, no CMS in between.

The case for it isn't nostalgia. It's the absence of abstraction overhead. A PHP application built around specific requirements runs only the code that serves a purpose. No plugin loading scripts on every page. No admin panel that needs to be hardened. No ORM generating queries for a data model that isn't yours.

Performance is proportional to what you built. Security surface is proportional to what you built. Maintenance scales with the application, not with a vendor's update schedule. That's the same reasoning behind building our own CRM rather than adapting someone else's.

The case against it is portability. A custom application is maintained by whoever built it, or by someone willing to learn it from documentation. WordPress is portable because every PHP developer has worked with it. A custom codebase requires a developer willing to read the docs and pick up the conventions. That works well in a stable, long-term development relationship. It's a problem when the project needs to change hands quickly.

Right for: Projects with custom data structures, workflows, or logic that no existing platform expresses cleanly. Long-term development relationships where continuity is stable. Performance-critical applications that don't need a content editing interface.

Not right for: Sites where non-technical users need to edit content. Projects that will be handed to a different developer without adequate documentation. Anything with requirements that fit neatly into an existing platform.

eCommerce: Stripe, WooCommerce, and Shopify

eCommerce complicates the stack decision because the right answer depends on what you're selling, how many products, and how much operational overhead you can absorb.

Stripe

Stripe is a payment processor, not an ecommerce platform. You build the cart, the checkout flow, the order management, and the customer interface. In exchange, you get complete control and the lowest overhead: no platform fee beyond Stripe's transaction percentage.

For a business selling one or two products, a service at a fixed price, or a subscription with a defined structure, Stripe is often the right call. A developer can build a clean checkout flow in a few days. Nothing carries more cost than it needs to.

For a catalogue of 50+ products with inventory tracking, variable pricing, and complex shipping, Stripe alone is a significant engineering project. That's when a dedicated ecommerce platform earns its fee.

WooCommerce

WooCommerce runs 49.3% of ecommerce platforms [W3Techs, April 2026]. It's a WordPress plugin that turns a WordPress site into a store. Content management and commerce live in the same admin interface.

The advantage is familiarity. If the client is already on WordPress, WooCommerce is a natural extension. The plugin ecosystem covers most ecommerce requirements: subscriptions, local pickup, variable products, bookings.

The performance tradeoff is real and compounds. WooCommerce adds significant weight to an already performance-challenged stack. A well-optimized WooCommerce store is achievable with caching, a good host, and disciplined plugin management. An unmanaged one with payment plugins, marketing scripts, and product image carousels stacked on top can get very slow. Slow ecommerce stores lose sales at a higher rate than slow informational sites. The stakes are higher.

Shopify

Shopify runs 30.2% of ecommerce platforms [W3Techs, April 2026]. It's a hosted platform: Shopify manages the infrastructure, PCI compliance, and scaling. You pay a monthly fee plus transaction fees.

The value proposition is operational simplicity. Checkout reliability, payment processing, SSL, CDN: handled. For a business where commerce is the primary product and infrastructure is a distraction, that's worth the platform cost.

The constraint is customization. Shopify's Liquid templating language is capable but specific. Deep customization requires a developer who knows it. You're also renting: if Shopify changes pricing or discontinues a feature, your options are limited.

For most projects: single product or simple service, use Stripe. Existing WordPress site with a manageable catalogue, use WooCommerce. Commerce-first business with scale ambitions and an appetite for a monthly platform fee, use Shopify.

Making the decision

Four questions get you most of the way there beyond this table.

Who updates the site, and how often? Non-technical editors updating content regularly means the stack needs a CMS. A developer handling all updates means a CMS is optional.

What's the three-year maintenance budget? Custom and headless architectures carry higher ongoing costs than WordPress or Shopify. The total cost of ownership is worth modelling before you choose a platform.

What does performance need to do? If Core Web Vitals are measurable business outcomes for this project, the stack choices that achieve them are narrower. A site taking six seconds to load on mobile is losing customers before they've read a word.

What happens when the original developer isn't available? This question gets ignored most often and costs the most when it matters. Custom builds need documentation and a succession plan. Established platforms buy portability at the cost of flexibility.

Answer those four questions and usually one or two options remain. The stack conversation is most productive after you know what the site actually needs to do. That's what discovery is for.

If you're working through a stack decision and want a second opinion, get in touch. I'm happy to talk it through.