Core PHP or a Framework? How to Choose for Your Project

The core PHP vs framework argument is usually held as a matter of taste. What you are deciding is who writes, and later maintains, the parts every web application needs: routing, input validation, database access, sessions, CSRF protection and error handling. In plain PHP that is you. With a framework it is a team of maintainers, and thousands of other projects have already found the bugs.

Neither answer is right every time. Here is where plain PHP is the sensible choice, what a framework buys, what both cost in year three, and a short test you can run before the first line is written.

What "core PHP" means on a real project

Core PHP means no framework: your own files, PHP's built-in functions and whatever structure you give them. Current plain PHP is not the PHP of old tutorials. It has namespaces, typed properties, Composer autoloading and PDO with prepared statements, and a careful developer can write clean, safe code with nothing else.

The catch is growth. Any application beyond a few pages ends up with a way to map addresses to code, a place for configuration, a database layer and a convention for templates. At that point you have a framework, with one author, no documentation and no security releases.

Where plain PHP is the right call

• Small tools with a fixed scope. A form that writes to one table and sends an email, a webhook receiver, a script that syncs two systems every night, a calculator on a landing page.
• Code that lives inside another system. A WordPress or Moodle plugin already has a host with its own APIs and rules. Bringing a second framework into it creates conflicts and solves nothing.
• Additions to an existing plain PHP application. Matching the code that is there usually beats introducing a second style next to it.
• Environments where you control very little. Basic shared hosting with no command line and no Composer still runs plain PHP files.

The common thread: one or two developers, a small surface, and either no user accounts or a single admin login.

What the smallest safe handler looks like

Here is a plain PHP handler for a one-field signup form. It checks a CSRF token, validates the input and writes to the database with a prepared statement.

<?php
declare(strict_types=1);

session_start();
$config = require __DIR__ . '/../config.php';

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $sent  = $_POST['csrf'] ?? '';
    $known = $_SESSION['csrf'] ?? '';

    if ($known === '' || !is_string($sent) || !hash_equals($known, $sent)) {
        http_response_code(403);
        exit('Invalid request');
    }

    $email = filter_var($_POST['email'] ?? '', FILTER_VALIDATE_EMAIL);
    if ($email === false) {
        http_response_code(422);
        exit('Please enter a valid email address');
    }

    $pdo = new PDO($config['dsn'], $config['user'], $config['pass'], [
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    ]);
    $stmt = $pdo->prepare('INSERT INTO subscribers (email) VALUES (:email)');
    $stmt->execute(['email' => $email]);
}

Nothing in it is hard. Every line is also one that gets forgotten: the empty-token check, the type check on the posted value, the prepared statement. A framework writes these lines once, for every form, and tests them. In plain PHP you write them for each form, and the tenth form is where one goes missing. Our PHP application security checklist lists the rest of what you take on.

What a framework gives you

Laravel and CodeIgniter differ a lot in size, but both hand you the same foundation:

• Routing and filters or middleware, so login checks and rate limits sit in one place and not at the top of every file.
• A query builder with parameter binding by default, plus migrations that keep the database schema in version control.
• Validation, CSRF protection, sessions and password hashing that are switched on, documented and patched.
• A known structure. A developer who has used the framework can find the controllers, the models and the configuration on day one.
• Tooling: a command-line runner, test helpers, and in the larger frameworks queues, scheduled tasks, mail and notifications.
• Security releases and upgrade guides written by someone else.

It also brings costs. Frameworks release major versions on a schedule, and staying supported means budgeting for upgrades. There is more to learn before the first page works. Each request loads more code, which matters less than people expect once OPcache is on and the database is the slow part. And the framework has opinions: if your design fights its conventions, you pay for that every day.

Core PHP vs framework in one table

	Plain PHP	Plain PHP with Composer packages	Full framework
First working page	Minutes	An hour or two of wiring	Quick once the framework is installed and understood
Security defaults	Whatever you remember to write	Per package, and you join them up	On by default and maintained upstream
A new developer joining	Has to read all of it	Knows the packages, learns your glue	Knows the layout already
Upgrades	Only PHP itself, but every fix is yours	Each package on its own timeline	Scheduled major versions with a guide
Hosting	Anything that runs PHP	Needs Composer at build time	A public web root, usually Composer, and often command-line access
Fits	Small bounded tools	Small APIs and services	Applications with accounts, roles and a future

The middle column deserves a note. A router package, a template engine, PDO and a validation library, pulled in through Composer, make a tidy base for a small service. You stay in control and you become the integrator, which means tracking security advisories for each piece. When you reach for the sixth package, you are assembling a framework by hand and should use a finished one.

Maintenance and hiring decide more than the first month

The first month always favors plain PHP, because there is nothing to learn. The comparison changes when the original developer leaves. A custom structure exists in one head. The next person has to read all of it before changing anything safely, and you cannot test a candidate for knowledge of a codebase nobody else has seen.

A framework gives you a hiring filter and a shared vocabulary. "Laravel developer" or "CodeIgniter developer" tells you what the person already knows about your project's layout, tools and habits. "Core PHP developer" tells you much less about how they structure an application.

The same holds for upkeep. PHP itself moves on a fixed schedule, published on the supported versions page, and each branch reaches the end of security fixes after four years. When that happens, a framework ships a compatible release and tells you what to change. In a hand-built application, finding and fixing every affected line is your job, which is why so many plain PHP systems are still running on versions that stopped receiving fixes years ago.

A short test before you commit

1. Will it have user accounts with different roles? Use a framework.
2. Will more than two developers work on it, or will the team change? Use a framework.
3. Is it expected to run and grow for more than a couple of years? Use a framework.
4. Does it need background jobs, scheduled tasks, an API or transactional email? Use a framework.
5. Is it a bounded tool with a page or two and no login? Plain PHP is fine, and often better.

If the first four are all "no", do not let anyone talk you into a framework for the sake of it. If any of them is "yes", the choice between a lighter and a fuller framework is the next decision, and Laravel vs CodeIgniter covers it.

If the application already exists in plain PHP

An existing plain PHP system that works is not a problem to be fixed by rewriting it. The practical path is usually to put it in version control, add the missing security basics, move it to a supported PHP version and bring structure in gradually, starting with the parts that change most often. A rewrite on a framework makes sense when new features are blocked by the old structure or when nobody can be hired to work on it.

Our PHP development team works in plain PHP, Laravel and CodeIgniter, so the recommendation follows the project and not a house preference. If you want a second opinion on a specific build, the scoping conversation for custom PHP development is where we would make this choice with you.

Frequently asked questions

Is core PHP faster than a framework?

A plain PHP script does less work per request, so in isolation it responds faster. In business applications the time goes into database queries and external services, and framework overhead is small next to that once OPcache and the framework's own caches are enabled. Speed is rarely a good reason to avoid a framework.

Is plain PHP less secure than a framework?

The language is the same, so plain PHP can be exactly as secure. The difference is that a framework applies protections by default and you must apply them by hand, every time. Most vulnerabilities we find in plain PHP code are omissions, not mistakes in the lines that are there.

Can I start in plain PHP and move to a framework later?

Yes, but the move is a rewrite of the structure, not a switch. It goes more smoothly if the plain PHP code already separates database access, business rules and templates, because those parts map onto models, services and views. Code that mixes SQL and HTML in one file has to be untangled first.

Does a framework lock me in?

To a degree. Your controllers, models and templates follow the framework's conventions and would need rework to move elsewhere. Business logic written as plain classes that do not depend on the framework stays portable, and it is good practice to keep the important rules there.