Statamic vs Laravel: when you actually need both

Clients ask me whether to build in Statamic or Laravel as if they are alternatives. They are not. Statamic is a content management system built on top of Laravel. Choosing between them is a bit like asking whether to build with bricks or with houses.

The real question is which combination fits your project. Sometimes plain Laravel is right. Sometimes Statamic on top of Laravel is right. Sometimes the right answer is both, with one mounted inside the other. This site you are reading runs that exact hybrid, which is part of why I have opinions about it.

What Statamic actually is

Statamic is a flat-file or database-backed CMS that runs as a Laravel package. You install it into a Laravel project. The Laravel framework is still underneath. You can write controllers, queues, jobs, commands, models and tests exactly as you would in a plain Laravel app. Statamic adds the content modelling, the editor experience, the templating layer and the control panel on top.

That single fact is the thing most decision documents get wrong. Treating Statamic as a separate platform misses the point. It is Laravel with a CMS bolted on, written by people who clearly love both.

The current major version shipped at the start of this year. The control panel was rewritten on a modern frontend stack and the editor experience tightened up. None of that changes the fundamental architecture. Statamic is still Laravel underneath.

When you reach for plain Laravel

Plain Laravel without Statamic is the right answer when content management is not part of the project.

A pure SaaS application is the obvious example. Users sign up, log in, do something to data, get billed. There are no marketing pages. Maybe a settings page or a help section, but you do not need a CMS for that. Adding Statamic would just put a layer between you and the framework for no benefit.

An internal tool is another. Operations dashboards, admin systems, internal portals. Nobody is editing content. The interface is for staff who do work in the system. Laravel with Filament or a custom admin is exactly right.

A heavy workload application with queues and scheduled work is another. If the value of the product is in the background jobs, the API integrations, the data pipelines, plain Laravel is what you want. You do not need a content editor in the path of any of that.

Anything with no content team falls in the same bucket. If nobody at the client is going to edit pages, you do not need an editor interface. You can put copy in the templates and update it when you do release work. That is not glamorous, but it is appropriate for the project.

When Statamic on top of Laravel earns its place

Statamic earns its keep when you have a content team that needs to edit the site and you also want the power of Laravel underneath for everything else.

A marketing site for a SaaS is the canonical case. The marketing team needs to publish blog posts, update landing pages, run campaigns and build new pages for launches. They cannot wait for a release cycle. Statamic gives them the editor. The Laravel framework underneath gives you the freedom to add forms, integrations, calculators or anything else that goes beyond static content.

A brochure plus product application is the next case. The marketing pages need a CMS. The product needs to be coded. With Statamic on top of Laravel, you get both in one codebase. The content team edits in Statamic. The developers write controllers, jobs and tests in the Laravel underneath. There is no boundary to manage between two systems.

A client site where the developer wants Laravel underneath is another. If you anticipate needing custom features that would be painful in a content-only CMS, Statamic preserves that escape hatch. You can drop into a controller, write a custom command, build a workflow and the editor experience stays clean for the client.

A site with structured content that does not fit page templates fits Statamic well too. Case studies, services, team members, locations. Statamic collections, blueprints and fieldsets let you model that content properly. Trying to express the same thing in WordPress custom post types and Advanced Custom Fields is doable but always feels like you are working against the grain.

The pricing reality

Statamic is paid software. The licence is a one-off payment per site at a few different tiers. The current model has a free tier for personal use, a paid tier for commercial single sites and a higher tier for sites with users or commerce.

Some clients balk at this. WordPress is free. The licence cost is a real consideration on small projects. On larger projects it is a rounding error compared to development time. Match the spend to the project.

I tell clients that the licence buys you a CMS designed by people who use it themselves. The polish shows. Editors who have used Statamic generally do not want to go back to WordPress for serious work. That is worth the cost on a project of any reasonable size.

The hybrid patterns I use

There are three hybrid patterns I reach for regularly. Each one solves a specific shape of project.

The first is Statamic for the content site, with Laravel features added in the same project. This is the most common pattern. The site is mostly content, but it has a contact form that talks to a CRM, a quote calculator, a booking widget, a custom report tool. You build those as Laravel controllers and views inside the Statamic project. The content team never sees them. The developer adds them as part of normal work. That is how this site is built. The blog, services and pages are Statamic. The site health report, the secure handover flow, the contact form, the 404 monitor are all Laravel.

The second is Laravel for the application, with Statamic mounted as the marketing front. The application has its own login, dashboard and product. The marketing site is its own subdomain or its own URL prefix running Statamic. Editors work in Statamic. Developers work in the Laravel app. The two share the same database if useful, the same authentication if you want it, the same theme if you want consistency.

The third is Laravel as a backend with Statamic as a content service. Less common, but it comes up. Your application is a single-page app or a mobile app and you want non-developers to edit the marketing pages, help articles or in-app content. You expose Statamic content through the API endpoints it provides and consume them from the frontend or app. The content team gets an editor. The product team gets the data.

How to pick between the patterns

I ask three questions.

Who edits the content? If nobody does, plain Laravel. If a content team does, you want a CMS.

How separate are the marketing site and the application? If they are one thing with the same brand, the same database and the same audience, Statamic on top of Laravel as one project is usually right. If they are genuinely separate products with different requirements, two applications mounted side by side make more sense.

How much custom logic does the marketing side need? If the answer is "it is just pages and posts and a contact form", plain Statamic is enough. If the answer is "we also have a postcode lookup, a property calculator, a quote builder", you need real Laravel underneath, which is what Statamic gives you anyway.

Common mistakes

I see the same handful of mistakes when people pick between these.

Choosing plain Laravel when there is a content team is the most expensive one. You build admin screens for content editing that are worse than what Statamic gives you for nothing. The content team complains, the developers get tired of building editor features and eventually you bolt on a CMS anyway.

Choosing Statamic when there is nobody to edit it happens too. The licence costs money, the editor experience is wasted and the build is slightly slower because you are content-modelling things that would be cleaner as hard-coded views.

Putting the marketing site and the application in separate codebases when they should be one is another. You end up duplicating authentication, theming, deployment and analytics. Statamic on top of Laravel as a single project usually wins for projects where the marketing and the product share a brand and a database.

Building everything in Statamic when the product really wants a separate Laravel application is the opposite mistake. The CMS gets in the way. You spend half your time fighting the templating layer for things that would be one controller in plain Laravel.

If you are weighing this up and not sure which side of the line your project falls on, send me the brief and I will tell you which pattern fits. If it is a Statamic shaped project, Statamic development and rescue is part of what I do. If it is plain Laravel, Laravel work covers it. If you are still on Craft and considering a move, Craft CMS work is in the mix too.