Laravel or WordPress: which, and when

We get asked this more than anything else, usually phrased as “could WordPress do this?” The answer is almost always yes, which is what makes it a bad question. WordPress can do nearly anything. The useful question is what it costs you in year three.

I have spent ten years building in both, and the projects that went wrong were almost never wrong about the framework on day one. They were wrong about which part of the system owned the data, and the framework choice simply made that mistake cheap or expensive to live with.

The one-line version

If the thing you are building is documents, use WordPress. If it is transactions or state, use Laravel.

A page, a post, a case study, a landing page, a job listing: those are documents. Someone writes them, someone publishes them, and the software’s job is to store and render them. WordPress is exceptional at that and you should not rebuild it.

An order moving through six states, a subscription that renews and fails and retries, a quote approved by two people, an inventory count that reconciles against a warehouse: those are transactions. WordPress can be made to model them. It will fight you the whole way.

Everything below is an elaboration of that sentence.

Why the boundary sits there

WordPress stores everything as posts and postmeta. Every custom post type, ACF field group and taxonomy you add becomes rows in wp_posts and wp_postmeta, as strings, with no foreign keys and no constraints. Database people call this an entity attribute value model, and they say it the way a structural engineer says “we found sand”.

For documents that is a genuinely good design. It is why a non-technical editor can invent a new content type on a Tuesday afternoon without a developer, a deploy or a migration. That is not a small thing. It is most of why WordPress runs a large share of the web.

What postmeta actually costs once the data gets relational

Here is the same requirement in both systems: find published items in a category, with a price between two values and a status flag, sorted by a date field.

In WordPress, every one of those custom fields is a separate row in a table with no idea what a price is.

new WP_Query([
    'post_type'  => 'listing',
    'tax_query'  => [['taxonomy' => 'region', 'terms' => 'west']],
    'meta_query' => [
        ['key' => 'price',  'value' => [100, 500], 'compare' => 'BETWEEN', 'type' => 'NUMERIC'],
        ['key' => 'status', 'value' => 'active'],
    ],
    'meta_key' => 'available_from',
    'orderby'  => 'meta_value',
]);

That produces three self-joins on wp_postmeta plus two more for the taxonomy, and it sorts on a longtext column cast to a date at query time. It works perfectly well at two thousand rows. On a 40,000-product catalogue, variations push wp_postmeta past a million rows before anyone has written a custom query at all, and this shape of query is where the page time goes.

The Laravel equivalent is a query against columns that have types.

Listing::where('region_id', $region->id)
    ->whereBetween('price', [100, 500])
    ->where('status', 'active')
    ->orderBy('available_from')
    ->get();

One table, real indexes, and a price the database understands as a number.

What the schema buys you beyond speed

Speed is the obvious difference and the least important one. The real difference is that some things become impossible rather than merely discouraged.

A unique constraint on a booking slot means a double booking cannot exist, no matter how many concurrent requests arrive or which developer forgets the check. A foreign key means an order cannot reference a customer who was deleted. A decimal(10,2) means a price cannot quietly become the string "49.99 " with a trailing space that breaks a comparison eight months later.

In postmeta all of those are conventions, and conventions hold right up until somebody writes a second code path.

The cost of the Laravel side is real too: you cannot invent a field without a migration and a deploy. That friction is exactly the thing WordPress people dislike, and they are not wrong to. Neither model is better. They are optimised for opposite things.

Eight real cases, and what we would build

A 40-page marketing site with a blog and a contact form. WordPress, and it is not close. Anything else means paying to build a CMS you could have had for nothing.

The same site, but marketing wants to compose new page layouts without a developer. Still WordPress. This is what native block themes and a proper pattern library are for. Budget the content model properly, because it decides whether editors use the site or fight it.

A store with 40,000 products, tiered pricing and a subscription tier. WooCommerce, with caveats. A catalogue that size is well within what it handles, and the checkout is usually where the recoverable seconds are. But HPOS, index strategy and ruthless plugin discipline stop being optional at that scale, and the work is closer to platform engineering than site building.

A booking platform where availability, pricing and cancellation rules interact. Laravel, and it is not close. Business logic with real invariants: no amount of postmeta makes a double booking impossible, whereas a unique constraint does it for free and for every code path at once.

An internal tool replacing a spreadsheet nobody trusts. Laravel, probably with Filament. Two weeks to a working panel with real permissions, audit trails and role-based access beats three months of bending an admin theme into a shape it was not built for.

A content site that needs to be fast, with editors who will not move. Headless: keep the WordPress admin, render elsewhere. It is a real architecture with real costs, and most of the speed it is credited with is available without it, so there is a separate guide on where the gain actually comes from.

A membership site with gated content and recurring billing. WordPress, more often than people expect. If the gating is “these posts require an active subscription” then a membership plugin and a payment gateway is a solved problem and a fifth of the cost. It stops being WordPress the moment entitlements get conditional: seats, usage limits, per-organisation billing, proration.

A marketplace with sellers, listings, payouts and commission. Laravel. Money moving between three parties with a ledger that has to balance is the clearest case on this list. WordPress marketplace plugins generally store balances in postmeta, and a balance in postmeta is a balance you cannot prove.

The hybrid, which is commoner than either

Plenty of our work is both, and that is entirely fine as long as the boundary is drawn on purpose rather than discovered later.

The split that works

WordPress owns the marketing site and the content. Laravel owns the application. They share nothing except an API contract and a decision about sessions. Two codebases, two deploys, one domain: example.com is WordPress, app.example.com is Laravel.

Three details make this pleasant rather than painful:

• One system owns identity. Usually Laravel, because it is the side with permissions that matter. WordPress reads the session, it does not create it. If both create sessions you will spend a week on it later, and we have.
• The API contract is versioned and small. Marketing pulls a plan list; the app pulls a few content blocks. Resist the temptation to let each side query the other’s database directly, because the moment that happens you have one system with two deploy schedules.
• Navigation and design tokens live in one place. Otherwise the header drifts and users notice the seam before you do.

The merge that does not

One WordPress install where the application lives inside a custom plugin, sharing the database with the CMS, storing its own domain objects in postmeta or in loose tables WordPress knows nothing about.

Every core update becomes a risk to your business logic. Every plugin you add runs in the same process as your billing code. The plugin accumulates a schema with no migration history, and the day someone needs a report the only way to get it is a raw query nobody dares change.

If you take one thing from this guide: the split is fine, the merge is not.

What each costs to own

This is where the decision usually turns, and it rarely gets discussed before the quote is signed.

WordPress has a lower build cost and a permanent maintenance floor. Core updates every few months, plugin updates continuously, and a security surface proportional to how many plugins you run. Budget a retainer from day one. The sites that go wrong are the ones nobody patched for two years, not the ones built badly. The worst codebase we have taken over had nine years without a patch and 41 vulnerable dependencies.

Laravel costs more to build and less to keep. Framework upgrades are a scheduled piece of work every year or two rather than a continuous drip, and there is no plugin ecosystem to audit. The cost lands as a bigger, less frequent lump, which is easier to plan for and harder to ignore until it hurts.

Indicative five-year shape for a mid-size project:

Over five years the two are closer than the initial quotes suggest. What separates them is not the total, it is whether the money leaves as a drip or as a lump, and which of those your organisation is better at approving.

The part nobody factors in: who maintains it

A framework choice is also a hiring choice, and it outlives the project.

WordPress developers are abundant and the range of ability is enormous. You can find someone in a week almost anywhere, at almost any rate, and the screening is entirely on you. Laravel developers are a smaller pool, more expensive on average, and considerably more consistent, because the framework’s conventions mean two Laravel codebases look more alike than two WordPress ones ever will.

If your plan is to bring maintenance in-house in year two, that difference matters more than anything in the build quote. A Laravel codebase built to convention can be handed to a competent new developer in a fortnight. A WordPress site with 40 plugins and a heavily customised theme cannot be handed to anyone quickly, whoever built it.

The option neither camp mentions: not building it

Before the framework question, there is a cheaper question nobody asks on a sales call, so I will ask it here.

Does an off-the-shelf product already do this? Scheduling, invoicing, CRM, help desk, learning management, event ticketing. Each of those is a mature category with products costing a few hundred dollars a year. If your requirements are 80% standard and 20% specific, buying the product and building only the 20% as an integration is dramatically cheaper than either framework. We have recommended this and lost the work, more than once.

Is the specific part actually specific? The usual answer is “our process is unusual”. Sometimes true. Often it means the process grew around the limitations of a spreadsheet, and adopting a standard product would improve it. That is a business conversation rather than a technical one, and it belongs before a framework is chosen rather than after.

Could a low-code tool carry it for a year? For internal tools especially, something like Airtable or Retool can validate whether the workflow is right before anyone spends a build budget. If it survives a year and outgrows the tool, you now have a specification written in usage rather than in assumptions, and the Laravel build that follows is faster and better aimed.

The framework question is worth answering carefully. It is worth first checking that you need to answer it.

The three questions that settle it

When someone describes a project, these three answers decide it almost every time.

1. Who invents new fields, an editor or a developer? If it genuinely is an editor, and they will do it often, that is WordPress. If the honest answer is “a developer, in a ticket, twice a year”, the flexibility you are paying for in postmeta is costing you and buying nothing.

2. Does anything have states that must not be violated? An order that cannot ship twice, a booking that cannot double-sell, a balance that cannot go negative. If yes, that is Laravel, and the reason is the constraint rather than the framework.

3. Is the front end the product, or the shop window? A shop window can be rendered by whatever holds the content. A product usually cannot, because the thing users interact with is state rather than pages.

Where we would push back

If you have arrived at “we need a custom platform” and what you described is a site with a members’ area and gated PDFs, that is WordPress with a membership plugin, at roughly a fifth of what you were about to spend. We have said this and lost the work, and it was still the right advice.

If you have arrived at “we will just do it in WordPress” and what you described has an approval workflow, a billing cycle and a reporting requirement, that is a Laravel application. Doing it in postmeta will be the most expensive decision of the project, and the bill arrives about eighteen months later when someone asks for a report the data model cannot answer.

We have talked people out of both directions. It is worth twenty minutes on a call before anyone writes a quote, and there is no fee for having it.

Common questions

Can WordPress handle a large amount of traffic?

Easily, if the pages are cacheable. A well-cached WordPress site serves an enormous amount of traffic from static HTML and never touches PHP. Traffic is rarely the problem. Logged-in, personalised pages are the problem, because those skip the cache and hit the database on every request.

Is WooCommerce a real answer for a serious store?

Yes, up to a point that is higher than its reputation suggests. We run a 40,000-SKU catalogue on it. What kills large Woo stores is plugin sprawl rather than product count, and that is a discipline problem rather than a platform one.

We already have WordPress and now need an application. What now?

Do not put the application in a plugin. Stand up Laravel alongside it, give one system ownership of identity, and keep the API between them small. That is the hybrid described above and it is the most common shape of work we take on.

Is headless the way to get the best of both?

Sometimes, and less often than the marketing suggests. It genuinely helps when editors will not leave the WordPress admin and the front end has performance or interactivity requirements WordPress themes cannot meet. On a typical slow WordPress site, roughly two thirds of the available speed gain comes from work that does not require decoupling at all.

How long does it take to decide?

Twenty minutes, usually. If the three questions above give clean answers the decision is already made and the call is a formality. If they give mixed answers, you have a hybrid, and the real work is drawing the boundary rather than picking a framework.