WordPress powers nearly half the web. Most companies that pick a “custom build” later regret it. Most companies that pick WordPress for a heavily custom application also regret it. The decision is more straightforward than the internet would have you believe — but it does require asking the right questions in the right order.
This guide is the framework we use internally when scoping a project. It saves us from over-engineering the simple jobs and from under-engineering the ambitious ones.
What “WordPress” actually means in 2026
Modern WordPress is three different things depending on how you set it up:
- Classic WordPress — themes, plugins, the standard PHP rendering pipeline. The version most people picture.
- Headless WordPress — WordPress as the CMS only, with the front-end built in Next.js, Astro, or another framework. The CMS data is fetched via REST API or WPGraphQL.
- Block-theme WordPress — Full Site Editing with Gutenberg blocks. Newer; works well for content-driven sites, less well for highly bespoke layouts.
When we say “WordPress vs custom” most people mean classic WordPress vs a hand-built application. Headless is its own conversation.
What “custom build” actually means
A custom build is a web application written from scratch — typically Next.js or Remix on the front-end, with Node.js, Python, or PHP (Laravel) on the back-end, and a database you control. There’s no CMS unless you build one or integrate something like Sanity or Payload.
The custom build’s superpower is freedom. The cost: you build everything. Authentication, content management, search, image handling, role-based access, comment moderation, SEO. Things WordPress gives you in a checkbox become engineering work.
The framework
Five questions, asked in order. The first one that yields a clear answer ends the discussion.
1. Is the website primarily a marketing surface, or is it primarily an application?
If it’s content + lead generation + occasional updates — a marketing surface — WordPress wins almost every time. If it’s a SaaS dashboard, a marketplace, a real-time collaboration tool, or anything users log into to do something — that’s an application, and WordPress is the wrong tool.
The middle case: marketing site that has a small custom feature (a calculator, a configurator, a quoting tool). WordPress with a custom plugin is usually fine here.
2. How often will non-developers need to update content?
Daily-to-weekly content updates by non-technical people is the strongest argument for WordPress. The CMS is good and the editorial UX is excellent, especially with ACF Pro fields and a custom admin theme. Custom-built CMSes (Sanity, Payload, Strapi) are catching up but require investment.
If “content updates” means twice a year, the CMS argument weakens.
3. How important is initial development cost?
WordPress builds at the same scope are typically 40–60% cheaper than custom builds. The plugin ecosystem, the theme starting points, and the maturity of WordPress development tooling all add up. If you’re price-sensitive, this is decisive.
The custom build’s cost advantage shows up later — usually around year 3–5, when the business has scaled enough that WordPress’s edge cases (high-traffic membership sites, custom user roles, complex e-commerce) start costing real engineering hours.
4. What’s your team’s technical depth?
WordPress has a vast pool of developers. You can hire WordPress people in any city in the US. Custom Next.js + Node.js developers exist but cost more, and replacing them mid-project is harder.
If your in-house team is non-technical, WordPress’s hireable surface area is a meaningful long-term advantage.
5. Are there features you literally cannot build on WordPress?
Real ones: real-time multiplayer collaboration, complex authentication flows (SAML, multi-factor with custom IDP), large-scale search beyond what plugins offer, computational features like ML inference, multi-tenant architecture with strict data isolation.
If you have one of these, the conversation’s over — you need a custom build. Or, more often, a hybrid: WordPress for the marketing site, custom application for the product.
Common mistakes in both directions
Mistake A: choosing WordPress for an application because it’s cheaper. Founders who do this end up paying twice. The first time on the WordPress build that doesn’t work for the use case; the second time on the custom rebuild 18 months later. The savings on year one cost three times that on year two.
Mistake B: choosing custom for a marketing site because “we want flexibility.” Flexibility isn’t free. Every custom decision is a maintenance cost. A 10-page agency website that ships on a custom Next.js stack will cost $15,000+ to build and another $5,000–$10,000/year just to keep current. The same site on WordPress would have cost $6,500 to build and $1,500/year to maintain.
Mistake C: assuming “headless WordPress” splits the difference
It can — but only when the front-end framework actually pays you back for its complexity. Headless adds an entire deployment surface (Vercel + Cloudflare + cache invalidation + preview environments) that classic WordPress doesn’t need. If your team is one designer and a part-time developer, headless is overkill.
Headless makes sense when (a) you want a Next.js front-end for performance or developer ergonomics, (b) you have multiple front-ends consuming the same content (web + mobile + email), or (c) you have a real reason to decouple the CMS from rendering. Otherwise, it’s a tax.
The hybrid pattern that often wins
For SaaS companies with real products, the right answer is usually:
- WordPress for the marketing site (homepage, pricing, articles, careers, legal)
- Custom application for the product (the dashboard users log into)
- A shared design system across both, ideally implemented in Tailwind or a shared component library
This pattern lets your marketing team move fast on WordPress without bothering engineering, and lets engineering ship the product without being slowed by WYSIWYG editors. The two surfaces share visual identity but are technically independent.
The decision in three sentences
If your website is primarily content and lead generation, build it on WordPress. The pace of editorial work, the cost of development, and the depth of the talent pool all push in that direction.
If your website is primarily an application your users log into, build it custom. The flexibility you need will outweigh the WordPress cost savings within a year.
If you’re not sure which it is, build the marketing site on WordPress and the product custom. The hybrid is the most common shape for a reason — it concentrates the right tool on the right job.
The internet will give you a hundred frameworks for this decision. Most are over-engineered or vendor-pitched. This one’s based on what actually plays out in production for the agencies that ship the work.
