The honest answer
Roughly 70% of the businesses we speak to should use WordPress. It is familiar to editors, cheap to host, extensively documented and perfectly capable of excellent Core Web Vitals when built properly.
Headless makes sense when one or more specific conditions apply, and it introduces real costs that vendors rarely mention: two systems to maintain, a higher development cost, more complex preview workflows and greater dependence on developers for structural changes.
Choose WordPress when…
These conditions describe the majority of content-led business websites.
- Your team already knows WordPress and wants a familiar editing experience.
- Content is primarily articles, pages and a blog with a moderate number of types.
- You need a plugin for a specific function that has no clean headless equivalent — memberships, LMS, complex forms, directory listings.
- Budget is a primary constraint and the site does not need to serve thousands of concurrent users.
- You want a single system to back up, update and secure.
Choose headless when…
Headless earns its cost under these conditions. If none apply, the extra complexity is not justified.
- Content must be delivered to multiple channels — web, mobile app, in-store displays, partner portals.
- You have a large content model with many types and complex relationships that WordPress would model awkwardly.
- Performance at scale is a hard requirement and full static generation is the goal.
- You have an in-house development team that will own the front end long-term.
- Content is created by multiple teams with distinct workflows, permissions and approval chains.
The performance reality
Headless does not guarantee speed. A headless site with an unoptimised image pipeline and eight client-side libraries will be slower than a well-built WordPress site with proper caching. We have measured both.
What headless genuinely offers is architectural control: no plugin layer injecting code you do not control, full static generation, and no database query on most requests. On a site with real content complexity, that is worth something. On a five-page brochure site, it is not.
| Consideration | WordPress | Headless (e.g. Sanity + Next.js) |
|---|---|---|
| Typical build cost | PKR 45,000–190,000 | PKR 190,000–550,000 |
| Ongoing maintenance | Moderate — updates, plugin risk | Low on front end, higher on custom code |
| Editor familiarity | High | Moderate — needs onboarding |
| Performance ceiling | Good with proper build | Excellent |
| Multi-channel delivery | Awkward | Native |
| Time to launch | 3–8 weeks | 6–12 weeks |
The hybrid option most people miss
You can use WordPress as a headless CMS. You get the familiar editing interface your team already knows, plus a static Next.js front end with excellent performance. The content is served through the WordPress REST API or GraphQL plugin and cached at build time.
This works well for teams that want performance but cannot justify retraining editors or paying for a commercial headless licence. The trade-off is that WordPress still needs updating and securing, which is a real ongoing cost.
Key takeaways
- Most content-led business sites should use WordPress for familiarity and lower total cost.
- Headless is justified by multi-channel delivery, complex content models or genuine scale requirements.
- Headless does not guarantee speed — architecture and optimisation still decide that.
- Using WordPress headless with a static front end is a legitimate middle path.
Bilal Ahmed
Head of Engineering
Oversees web and application development, with a focus on Next.js, TypeScript and performance engineering.