Custom WordPress vs Headless WordPress: Which to Offshore for SMB Business Sites

Last updated: July 2, 2026

WordPress powers 43.5% of all websites globally as of June 2026. For US SMBs, that statistic doesn’t usually matter. What matters is what happens when you try to staff the development of one.

The WordPress developer market has quietly split. Traditional PHP-based WordPress remains the most common tech stack in offshore hiring markets. Headless WordPress, where content is served via API to a separate React or Next.js frontend, is growing fast. But it’s a fundamentally different hiring brief with a meaningfully different price tag. Understanding that gap before you spec out a team changes your budget, your timeline, and the amount of technical debt you carry for the next three years.

The math on offshore vs in-house software development always favors offshore. But within the offshore model, custom WordPress and headless WordPress aren’t equally priced. And they don’t draw from the same talent pool.

This post covers both architectures: what each costs to build with an offshore team, which model actually fits most SMBs, how to build the team, and the questions worth asking before you commit to either path.

What’s the Actual Difference Between Custom and Headless WordPress?

Custom WordPress is one system. WordPress generates your pages on the server using PHP, your theme controls the layout, and plugins handle the extra functionality. Content management, page generation, and delivery all happen in the same installation. It’s what the vast majority of WordPress sites run, including most SMB sites built in the last decade.

Headless WordPress splits that system in two. WordPress still manages your content through the same admin panel you know. But instead of generating HTML, it exposes your content through an API. A completely separate JavaScript application, usually React or Next.js, fetches that content and handles everything the user actually sees. Two codebases. Two hosting environments. Two sets of developers to maintain over time.

WordPress 7.0, released in May 2026, elevated WPGraphQL to official plugin status. That’s a meaningful step toward making headless development more stable. It doesn’t make it cheaper to staff.

The practical difference for an SMB making a build decision comes down to this: custom WordPress needs developers with PHP expertise and solid WP theme and plugin knowledge. Headless needs all of that on the backend, plus React or Next.js on the frontend, plus GraphQL or REST API design. That’s a different job description, a narrower talent pool, and a higher hourly rate.

How Each Architecture Shifts What You Pay Offshore

Traditional PHP/WP developers in India and Southeast Asia run $28 to $45 per hour. Headless WordPress developers who combine WordPress backend knowledge with React and WPGraphQL command $40 to $65 per hour in the same markets. That’s a 25 to 40% premium for the combined skill set, according to offshore WordPress developer rate data from Elsner.

Those numbers compare well against US rates of $80 to $150 per hour regardless of which architecture you choose. The offshore savings are real in both scenarios. But the headless offshore baseline is higher, and the time to source and vet the right developer is longer. The talent pool for PHP/WP is deep and well-established in offshore markets. The pool of developers who can write both clean WordPress backend code and production-ready React is narrower.

There’s another cost people regularly miss: team size. A custom WordPress project for a standard SMB site typically needs one senior developer and maybe one mid-level for larger builds. A comparable headless build needs a minimum of two people working in parallel: one for the WordPress backend and API configuration, one for the React/Next.js frontend. Some teams add a third for DevOps and deployment infrastructure.

Custom WordPress Offshore: The Right Call for Most SMBs

Most SMBs don’t need headless. That’s not a hedge. It’s what the build requirements actually suggest when you look at them honestly.

A 15-page marketing site, a WooCommerce store, a professional services site with a blog and a contact form, a company intranet. Traditional custom WordPress handles all of these without architectural strain. Performance on a properly configured custom WordPress setup with a CDN and object caching is good. Not theoretical good. Practically fast enough that your visitors won’t notice the difference, and the tradeoff in complexity isn’t worth chasing.

The offshore talent pool for PHP/WP is the deepest of any web development specialization. The best countries for PHP development offshore include India, the Philippines, Poland, Ukraine, and Pakistan, all with established WordPress talent pipelines and verifiable project track records. Junior-to-mid PHP/WP developers run $20 to $35 per hour. Senior specialists hit $40 to $55 per hour. Turnaround on a solid job brief is often 48 to 72 hours, not two weeks.

Three clear signals that custom WordPress offshore is right for your situation:

• Your site runs WooCommerce or depends heavily on WP plugins. Most headless WooCommerce setups require significant custom API work and lose native checkout behavior. WooCommerce is deeply plugin-dependent, and those plugins often don’t behave in headless contexts.
• You have non-technical team members managing content. Native WP admin is the simplest content experience available. When you go headless, editors lose live preview and the block editor experience can degrade depending on configuration. Your offshore team can’t fix what’s a structural architecture choice.
• You need to ship fast. Replacing a site that’s underperforming? Custom WP developers are quicker to hire, quicker to onboard, and quicker to deliver. That’s not a small advantage when speed matters.

When Headless WordPress Actually Pays Off

Headless isn’t overkill in every context. There are specific situations where the extra cost and complexity pays real dividends, and being able to recognize them matters before you start writing a job brief.

The strongest case for headless WordPress offshore is a content-heavy business that needs to deliver to multiple channels simultaneously. If your content needs to appear on a web app, a mobile app, and a third-party platform without duplication, the API-first approach is genuinely valuable. One content source, rendered everywhere. WP Engine’s headless hosting documentation covers this pattern directly, and it’s a real architectural advantage in multi-channel scenarios.

A few other situations where headless makes sense:

• Your existing development team already writes React. Adding a WordPress backend for content management is a clean extension of what they know. The headless pattern plays to existing strengths instead of introducing a new paradigm.
• You’re building a web application, not a website. Complex dynamic user interactions are easier to manage in React than in PHP/jQuery. If your “site” has dashboard functionality, personalization, or real-time features, a JavaScript frontend solves real problems.
• You’re a SaaS or media company that needs content-as-infrastructure. Headless turns your WordPress install into a content API that multiple products consume. At that scale, the architecture makes sense.

What doesn’t justify headless for a standard SMB site: “we want better performance” and “we want to future-proof.” Traditional WordPress with LiteSpeed caching and a CDN delivers sub-200ms load times on a well-configured setup. The headless performance ceiling is higher, but you’re unlikely to hit the traditional WP ceiling on a standard SMB build. And future-proofing with a more complex and expensive architecture means paying now for capabilities you don’t need yet. That’s not planning ahead. That’s over-engineering.

Kanopi’s headless WordPress analysis puts it plainly: “For the vast majority of websites, the improvements from headless WordPress are negligible, but the cost to develop and maintain is much higher.” They build both architectures. That opinion carries weight.

The Hybrid Path Most SMBs Actually Land On

Worth naming: a lot of SMBs end up in the middle. Not fully headless. Not purely traditional.

The most common real-world setup is traditional WordPress with one or two headless-adjacent components. The main site runs PHP, but marketing landing pages are built in Next.js pulling from the same WP content API. Or the primary site is custom WP, and a specific product feature runs as a React application. This isn’t a compromise position. It’s practical architecture that matches actual requirements instead of picking a camp.

The hiring implications are messier, though. You need developers comfortable working in both paradigms, and that narrows the available pool somewhat. A developer fluent in PHP/WP who also writes functional React is more common in 2026 than it was three years ago, but you’ll still spend more time vetting to find one at the right price point.

3-Year Total Cost Comparison: Custom vs Headless with Offshore Labor

These estimates cover a typical SMB site: 10 to 30 pages, moderate traffic, one non-technical content manager. Developer rates reflect offshore teams based in India and Southeast Asia. Hosting figures are current 2026 market rates.

The headless 3-year total is still 55 to 65% lower than comparable US-based development, per Invedus’s offshore WordPress development analysis. So offshore makes headless more affordable. The question for an SMB isn’t whether offshore headless is cheaper than US headless. It’s whether headless was the right architecture choice to begin with.

How to Vet an Offshore WordPress Developer for Each Architecture

Before you write a job brief, know what you’re actually testing for. Generic “WordPress developer” job posts attract both traditional and headless developers, and the skill sets don’t overlap as much as the title suggests.

For custom WordPress developers offshore, the core test is practical. Ask them to extend an existing theme with a custom post type, create a settings page using the Settings API, and explain how they’d optimize a slow database query in WP. Most developers who claim WP experience can install themes and plugins. Fewer can write clean PHP. Fewer still understand the hooks system well enough to build features that survive updates.

Three vetting questions worth using:

• “Walk me through how you’d build a custom Gutenberg block from scratch.” Tests block editor knowledge, not just classic editor familiarity.
• “What’s the difference between add_action and add_filter, and when would you reach for each?” A foundational question. Developers who can’t answer this clearly won’t build maintainable WP code.
• “Show me a real project where you had to resolve a conflict between two WooCommerce plugins.” Filters out developers with theoretical knowledge but no real-world WP complexity behind them.

For headless WordPress developers, the skills split. Test PHP knowledge for the WP backend the same way as above. Then test JavaScript fundamentals and API design separately. WPGraphQL is often the weak spot for offshore headless developers: it’s newer, adoption is still growing, and many developers have used the REST API but haven’t worked with GraphQL at all.

Good headless vetting tasks:

• A 30-minute live exercise: set up a basic Next.js app that fetches and renders posts from a WordPress REST API endpoint. Simple enough that a real headless developer does it fast. Revealing enough that it surfaces gaps immediately.
• “Explain how you’d handle user authentication for a member-only headless WordPress site.” Tests architectural thinking, not just syntax.
• “What breaks when a WordPress plugin doesn’t support headless, and how do you handle it in practice?” Tests real-world experience with headless’s actual limitations.

The offshore developer vetting process Kore BPO runs includes a live coding step for every technical placement. Portfolio reviews alone don’t surface the gap between a developer who has used WordPress and one who understands it. That distinction matters considerably more in headless builds, where bad architectural decisions are expensive to unwind.

If you’re writing the initial job brief, the offshore developer job brief guide covers what to include for technical roles so you attract the right candidates from the start rather than filtering after the fact.

What Your Offshore WordPress Team Looks Like in 2026

Most SMB offshore WordPress teams are small. One to three people for the majority of builds. Here’s what those teams actually look like in practice.

For a custom WordPress SMB site:

• 1 senior WP developer (lead): PHP, WP architecture, theme and plugin development, performance optimization. This is the person making architectural calls and writing the complex parts. $40 to $55/hr offshore.
• 1 mid-level WP developer (for larger or faster-paced builds): handles implementation of standard features, plugin configuration, content migration. $28 to $38/hr offshore.

One senior developer handles most SMB custom WP builds comfortably. Two is a faster path for larger sites or tight timelines.

For a headless WordPress SMB site:

• 1 senior WordPress backend developer: manages the WP installation, configures WPGraphQL or REST API endpoints, defines custom post types and field schemas, handles content modeling decisions. $45 to $60/hr offshore.
• 1 React/Next.js frontend developer: builds the presentation layer, handles routing and state management, optimizes performance, consumes the API cleanly. $48 to $65/hr offshore.
• 1 DevOps or infrastructure resource (often part-time or shared): manages frontend hosting on Vercel or Netlify, plus WordPress hosting, plus build pipelines. $35 to $45/hr offshore.

Coordination between two codebases needs deliberate structure. Shared Slack channels, API contracts documented before frontend development starts, and a weekly sync between backend and frontend developers prevent the most common failure modes. Without that structure, headless builds drift into integration problems that cost significantly more to fix than they would have cost to prevent.

Kore BPO’s offshore WordPress developer roles cover both traditional and headless placements. We pre-screen for the architecture type you’re building, not just for generic WordPress experience. The distinction matters, and it’s the first question we ask before sending resumes.

One thing we see consistently: the single most common failure in offshore WordPress builds isn’t a skill problem. It’s a specification problem. An excellent PHP developer can’t rescue a headless build where no one defined the content model before the API was built. Get the architecture decision made and documented before the first hire starts. That’s true whether you go custom or headless, but it’s especially true in headless where the two codebases need to agree on structure before either one starts moving.

There’s no objectively right answer between custom WordPress and headless WordPress for SMB sites. There’s only the answer that fits your actual requirements.

For most SMBs, custom WordPress offshore delivers strong results at lower cost with a deeper available talent pool. You’ll find developers faster, onboard them faster, and maintain the system at lower cost over three years. The plugin ecosystem covers most feature requirements without custom development. Performance, with proper configuration, is genuinely good.

Headless makes sense when you have specific requirements that justify the overhead: multi-channel content delivery, a React-centric existing team, or web application-level interactivity. Those requirements are real. They just don’t apply to most 20-page SMB sites.

The offshore cost advantage exists in both scenarios. The decision is whether headless complexity is solving a real problem you have today, or a theoretical one you might have at some point. Most of the time, the answer favors custom WordPress. When it doesn’t, headless offshore is still meaningfully cheaper than headless in-house.

If you’re working through this decision and want to understand what a team would cost and how long staffing would take, build your offshore WordPress team with Kore BPO. We help you spec the right team for whichever architecture fits before you commit to either path.