The most expensive decision in a web project is made in the first week, usually for the wrong reason. Someone read that a unicorn startup uses React, or that a competitor "rebuilt on a headless CMS," and now that's the plan — regardless of what the project actually needs. I've spent 12 years cleaning up after stacks chosen by hype, and the lesson is always the same: the right stack is the one that fits the problem, not the one trending on developer Twitter.

So here's the honest framework I use with every client. It's five questions, not a benchmark war.

The five questions that actually decide it

  • Content cadence. How often does content change, and who changes it — a developer, or a marketing manager who's never seen a terminal?
  • Interactivity. Is this content you read, or an application you operate? Real-time data and logged-in state are a different universe from a brochure.
  • Team. Who maintains this in two years? A solo founder, an agency, an in-house dev team? Build for the people who'll live with it.
  • Budget. Not just to build — to host, secure, and maintain. Every dependency is a recurring cost.
  • Scale. Ten visitors or ten thousand concurrent? Hundreds of pages or hundreds of thousands? Be realistic, not aspirational.

Answer those honestly and the stack usually picks itself. Let me walk the four options I reach for most, and exactly when each one wins.

Plain HTML & CSS: the underrated default

For a portfolio, a brochure site, a landing page, or any project that's mostly fixed content, hand-built static HTML is the strongest and most underrated choice. It's the fastest thing you can ship, has effectively no attack surface, costs almost nothing to host, and will still work flawlessly a decade from now with zero maintenance.

The MAP Architects portfolio is exactly this case — a minimalist showcase of $50M+ in projects where the content rarely changes and the photography needs to load instantly. A heavy framework would have made it slower for zero benefit. The trade-off is honest: if a non-technical client needs to publish new content weekly without calling me, plain HTML is the wrong answer. That's a real limitation, not a flaw.

If you can't name a specific requirement that rules out static HTML, static HTML is probably your answer. "It feels too simple" is not a requirement.

WordPress: when editors need to drive

WordPress earns its reputation in one scenario above all: non-technical people who need to publish often, independently. Mature editorial workflow, a vast plugin ecosystem, and a UI your client's marketing team already knows. For a content-heavy site with frequent updates across many contributors, it's the pragmatic winner.

The TIU University platform runs on a WordPress core for exactly this reason — many departments, constant updates, a student portal and admissions pipeline, all maintained by staff rather than developers. I extended it with custom PHP modules where the off-the-shelf parts fell short.

  • Choose it when: high content cadence, non-technical editors, a need for a known admin UI, multi-author publishing.
  • The honest trade-off: plugins are a security and performance liability. WordPress demands ongoing maintenance — updates, patching, monitoring — that static sites simply don't. Budget for it or it will bite you.

Custom PHP: when you need control without bloat

Sometimes the project has specific logic that no CMS models cleanly, but it also doesn't need a heavy front-end framework. That's the sweet spot for custom PHP: a bespoke gallery engine, a tailored data structure, a content workflow that's yours and not a plugin's. You get exactly the behaviour you want, fast server-side rendering, and no dependency on someone else's update schedule.

  • Choose it when: the logic is custom but server-rendered HTML is enough; you want full control and minimal dependencies; performance matters and you don't want a framework tax.
  • The honest trade-off: you own all of it. There's no plugin marketplace to lean on, so the maintenance burden lands on whoever holds the code. With a competent team that's a feature; for a client who'll change agencies, it's a risk to weigh.

React: when it's genuinely an application

React is brilliant — for the problem it was built to solve. The moment you have a real-time dashboard, complex client-side state, a logged-in app experience, or a UI that updates constantly without page reloads, a component framework stops being overhead and starts being leverage. The Eagle Tech client dashboard is React on Firebase because it genuinely needs auth, real-time data, and a rich interactive interface. That's the right call.

The mistake — the one I see constantly — is reaching for React to render content that doesn't change. A marketing site built as a single-page React app ships a megabyte of framework to display text, hurts SEO, slows the first paint, and complicates hosting, all to solve a problem the page never had.

  • Choose it when: genuine application interactivity, real-time or live data, complex client state, a SaaS dashboard, a team fluent in the ecosystem.
  • The honest trade-off: heavier payloads, more build complexity, an SEO and performance cost you must actively manage, and a bigger maintenance and dependency surface. Worth it for an app; wasteful for a brochure.

Mapping projects to stacks

Here's the decision compressed to the project types I see most:

  • Architecture portfolio / brochure: static HTML & CSS, or custom PHP if there's bespoke gallery logic. Fast, cheap, durable.
  • University platform / content-heavy multi-editor site: WordPress core, extended with custom PHP where needed.
  • E-commerce: WooCommerce or a dedicated commerce platform — carts, inventory and payments are inherently dynamic.
  • SaaS dashboard / real-time app: React (or similar) on a real backend. This is what the framework is for.

The principle underneath all of it

No bloated frameworks where they're not needed. No unnecessary complexity bought with someone else's maintenance budget. Understand the business first — content cadence, interactivity, team, budget, scale — then choose the simplest stack that satisfies those real constraints. The trendy choice and the right choice occasionally coincide. When they don't, pick the right one, and be able to explain exactly why. That explanation, not the logo on your stack, is what separates engineering from fashion.