Back to Blogs
Almost every week someone asks me whether their project should be built in Laravel or in plain PHP. Sometimes it's a business owner who read that Laravel is "the modern way", and sometimes it's another developer who thinks plain PHP is old fashioned. My honest answer is that I use both, and the choice depends on the project, not on which one is trendier.
In this post I'll explain how I decide, the questions I ask before I pick, and the mistakes I've seen when people choose the wrong one.
What I mean by plain PHP and by Laravel
When I say plain PHP, I don't mean messy files with database queries mixed into the HTML. I mean a small, organised codebase I write myself: a few shared include files, a simple router or one file per page, PDO with prepared statements, and a tidy folder for the admin panel. It runs on any shared hosting plan without extra setup.
Laravel is a full framework built on PHP. It gives you routing, a database layer (Eloquent), migrations, authentication, queues, email, validation and a lot more out of the box. You install it with Composer and it expects a certain folder structure and a bit more control over the server.
Both are PHP. The difference is how much structure and how many ready-made tools you start with.
When I choose plain PHP
Most of the small business websites I build are plain PHP with MySQL. That's not because I can't use a framework. It's because for these sites, a framework adds weight the owner doesn't need.
The site is mostly content
A service business usually needs a home page, service pages, a portfolio or gallery, a blog, a contact form and a small admin panel to edit prices and posts. That's a handful of database tables and a few forms. I can build that cleanly in plain PHP, and the result is fast and easy to read.
The hosting is basic shared hosting
Many owners already pay for a shared hosting plan with cPanel or hPanel. Plain PHP runs there with no Composer, no SSH and no special document root. Laravel can run on shared hosting too, but it often needs workarounds like moving the public folder or running commands without proper terminal access. If the owner wants to stay on cheap shared hosting, plain PHP saves trouble.
The owner may hand it to someone else later
Almost any PHP developer can open a small plain PHP site and understand it in an hour. A Laravel project is also readable for someone who knows Laravel, but a general PHP developer or a WordPress person may struggle. For a small site, I'd rather keep it simple so the owner isn't tied to a specific kind of developer.
Updates should be rare and small
A plain PHP site has very few dependencies, so there's not much to update. A Laravel project pulls in many packages through Composer, and every major Laravel version needs an upgrade at some point. That's fine for an active product, but a brochure site that nobody touches for two years is easier to keep safe when it has fewer moving parts.
When I choose Laravel
Once a project starts to look more like an application than a website, I reach for Laravel. Writing all of that structure myself would take longer and would be harder for the next developer.
Users log in and have their own data
If customers need accounts, password resets, roles and permissions, Laravel already has well tested tools for it. I could write login and roles myself in plain PHP, and I do for a single admin user, but for many users with different access levels I don't want to reinvent it.
There's real business logic
Booking systems with availability rules, order workflows, invoices, subscription billing, reports and dashboards all benefit from Laravel's structure. Models, validation rules and policies keep the logic in clear places instead of spread across page files.
Background jobs and scheduled tasks
Sending hundreds of emails, generating PDFs, syncing with an outside API every night or processing uploaded files are jobs that shouldn't run while a visitor waits. Laravel's queues and scheduler handle this well. In plain PHP I'd end up building a smaller, less reliable version of the same thing.
The project will keep growing
If the client already talks about phase two, a mobile app that needs an API, or a team of developers working on it later, Laravel gives everyone a shared structure. Migrations also make database changes safer when the schema keeps changing.
The questions I ask before deciding
Before I quote, I go through a short list with the client. The answers usually make the choice obvious.
- Who uses the site? Only visitors and one admin, or many logged-in users?
- How much changes over time? Mostly text and photos, or new features every few months?
- Where will it be hosted? Existing shared hosting, or a VPS or cloud server where I can run Composer and background workers?
- Who maintains it after launch? Me, the owner, or a developer they haven't hired yet?
- Does it talk to other systems? Payment gateways, CRMs, delivery services or a mobile app?
If the answers are "visitors and one admin", "mostly content" and "shared hosting", I build it in plain PHP. If they're "many users", "new features" and "a mobile app later", Laravel is the safer bet.
Mistakes I see with both
Using Laravel for a five-page site
I've taken over small brochure sites built in Laravel where the owner couldn't find anyone cheap to change a phone number, and the hosting kept breaking after PHP updates because the Laravel version was years old. The framework wasn't the problem. It was simply too much for what the site needed.
Stretching plain PHP too far
The opposite also happens. A simple site grows into a booking system with user accounts, and every feature gets bolted on with more include files. After a while nobody wants to touch it. When I see a plain PHP project heading that way, I tell the client early that a rebuild on a framework will cost less than patching it for another year.
Skipping security because "it's small"
Whichever one I use, the basics stay the same: prepared statements for every query, escaping output, hashed passwords, CSRF tokens on forms, secrets kept outside the public folder and a supported PHP version. Laravel does many of these for you by default. In plain PHP I have to do them myself, which is fine as long as I never skip them.
What this means if you're hiring a developer
If a developer suggests Laravel or plain PHP, ask them why. A good answer is about your project: how many users, how it will grow, where it's hosted and who will look after it. A weak answer is "it's what I always use" or "it's the latest thing".
Also ask what happens after launch. Who updates the framework or the PHP version, how often, and what that costs. A cheaper build can become expensive if nobody can maintain it.
For most small business websites, plain PHP with a small admin panel is all you need, and it keeps running costs low. For web apps with accounts, workflows and plans to grow, Laravel saves time and gives the project a solid structure. I'm happy to use either one, as long as it fits the job.
If you're not sure which way your project should go, send me a short description of what you need and I'll tell you honestly which I'd choose and why.
