Laravel, CodeIgniter or CakePHP? Choosing a PHP framework for a client project

Clients rarely ask for a framework by name. They ask for a booking system, a dealer portal, an API for a mobile app or a rescue of an old custom PHP application. Choosing the framework is my job, and the right answer is often "the one the existing code already uses". When there's a free choice, these are the three I reach for, and this is how I decide.

The short versionLink to this section#

Laravel: the ecosystem choiceLink to this section#

Laravel's strength is that almost everything an application needs has an official, well-documented answer: authentication, queues, scheduling, mail, notifications, file storage, caching, testing and API tokens. That means less glue code and fewer decisions per project.

// A typical Laravel query: eager loading, scopes and pagination
$orders = Order::with(['customer', 'items.product'])
    ->where('status', 'processing')
    ->latest()
    ->paginate(25);

Choose Laravel when the project will grow: multiple user roles, background jobs, integrations, an API and an admin panel. It's also the easiest framework to hire for, which matters if the client's team will take the code over.

Watch out for the hosting assumptions. Queues need a worker process and the scheduler needs a cron entry, which some shared hosts don't allow. Laravel also releases a major version every year, so budget for regular upgrades. They're usually smooth if you upgrade one version at a time.

The Laravel for WordPress developers guide walks through routes, Eloquent, Blade and queues in detail.

CodeIgniter 4: small and quick to startLink to this section#

CodeIgniter has always been the framework that gets out of the way. Version 4 modernised it with namespaces, Composer, a real router, filters (middleware), entities and a CLI called Spark, while keeping it small and quick to learn.

// app/Config/Routes.php
$routes->get('orders', 'Orders::index');
$routes->post('orders', 'Orders::create', ['filter' => 'auth']);

// app/Controllers/Orders.php
class Orders extends BaseController
{
    public function index()
    {
        $model = model(OrderModel::class);

        return view('orders/index', [
            'orders' => $model->where('status', 'processing')->orderBy('created_at', 'DESC')->paginate(25),
            'pager'  => $model->pager,
        ]);
    }
}

The model class also handles validation rules and allowed fields, so simple CRUD stays short:

class OrderModel extends Model
{
    protected $table          = 'orders';
    protected $allowedFields  = ['customer_id', 'status', 'total'];
    protected $useTimestamps  = true;
    protected $validationRules = [
        'customer_id' => 'required|is_natural_no_zero',
        'status'      => 'required|in_list[pending,processing,shipped]',
    ];
}

Choose CodeIgniter when the app is compact (an internal tool, a small API, a dashboard), when the hosting is modest, or when the team is new to frameworks. It's also the natural path for the many older CodeIgniter 3 applications still running: moving them to CodeIgniter 4 keeps familiar concepts.

Watch out for the smaller ecosystem. Queues, advanced auth and admin panels come from community packages (Shield is the official auth library), so check that the packages you need are maintained before committing.

CakePHP 5: conventions for long-lived business appsLink to this section#

CakePHP is one of the oldest PHP frameworks and one of the most consistent. Its strict naming conventions mean that a ArticlesController uses an ArticlesTable for the articles database table and templates in templates/Articles/, with very little configuration. Its ORM separates table classes (queries, associations, validation, behaviours) from entity classes (one row).

// src/Model/Table/OrdersTable.php
class OrdersTable extends Table
{
    public function initialize(array $config): void
    {
        $this->belongsTo('Customers');
        $this->hasMany('OrderItems');
        $this->addBehavior('Timestamp');
    }

    public function findProcessing(SelectQuery $query): SelectQuery
    {
        return $query->where(['Orders.status' => 'processing'])->contain(['Customers']);
    }
}

// In a controller
$orders = $this->paginate($this->Orders->find('processing'));

The bake command generates models, controllers and templates from an existing database, which makes it very quick to put a working admin around legacy data.

Choose CakePHP when the application is data-heavy, with many related tables, forms and reports, and will be maintained for years by a team that values predictable structure. It's also a good fit when you must build on an existing database schema.

Watch out for fewer developers in the hiring pool than Laravel, and conventions that feel restrictive until the team learns them.

Performance: rarely the deciding factorLink to this section#

All three are fast enough for nearly every client project. Real-world speed depends far more on database indexes, N+1 queries, caching and the server (PHP version, OPcache, enough PHP-FPM workers) than on the framework. CodeIgniter has the smallest footprint, which helps on very small servers; Laravel and CakePHP both perform well with configuration and route caching enabled in production.

If an app is slow, measure before blaming the framework. A query log or a profiler such as Laravel Telescope, the CodeIgniter debug toolbar or CakePHP DebugKit usually points straight at the problem.

Security: similar foundations, different defaultsLink to this section#

All three provide CSRF protection, escaping helpers, prepared queries through their query builders, and password hashing. The differences are in the defaults: Laravel's Blade escapes {{ }} output automatically and Eloquent guards against mass assignment; CodeIgniter's esc() helper must be used in views; CakePHP's h() helper escapes output and its FormProtection component guards against tampered forms. Whichever you choose, keep the same rules as in WordPress plugin work: sanitize and validate input, escape output, and check permissions on every action.

Taking over an existing projectLink to this section#

The most common real decision isn't "which framework for a new project" but "what to do with this old one". My usual order:

1. Get it running locally with the exact PHP version and a copy of the database.
2. Add tests around the critical paths (checkout, login, the main forms) before changing anything.
3. Upgrade within the framework one major version at a time: CodeIgniter 3 to 4, CakePHP 3 or 4 to 5, older Laravel to current.
4. Rewrite only the parts that block progress, and only with a clear business reason.

A full rewrite into a different framework is the most expensive option and the riskiest, so it should be the last resort.

Three typical briefs and what I'd pickLink to this section#

A dealer portal for a manufacturer. Dealers log in, see their price lists, place orders, download invoices; the sales team approves accounts and orders; an ERP receives orders overnight. That's roles, workflows, queued exports and a scheduled sync: Laravel, because queues, the scheduler, policies and notifications are built in.

A small API for a mobile app on existing shared hosting. Twenty endpoints, token auth, a MySQL database that already exists, and a budget that rules out new infrastructure. CodeIgniter 4 keeps the footprint small, runs on that hosting without workers, and is easy for the client's in-house developer to follow.

An internal system with forty related tables and years of history. Inventory, suppliers, purchase orders and reports, built on a schema the business won't change. CakePHP 5: bake generates a working admin from the existing tables in an afternoon, and its conventions keep a long-lived codebase consistent as people come and go.

A decision checklistLink to this section#

Answer these before picking, and write the answers into the proposal so the client understands the choice:

• ☐ Is there existing code or a team that already knows one of these frameworks?
• ☐ Does the hosting support Composer, the command line and long-running worker processes?
• ☐ Will the project need queues, scheduled jobs, notifications or real-time features?
• ☐ How many developers will maintain it, and how easy is it to hire for this framework locally?
• ☐ Is there an existing database schema the framework must work with?
• ☐ What's the upgrade plan for the next three years?

Common mistakes when choosingLink to this section#

• Choosing by benchmark. Framework overhead is milliseconds; a missing index is seconds.
• Ignoring hosting. A Laravel app that relies on queues won't work properly on hosting without long-running processes.
• Picking what the developer knows, not what the client can maintain. Ask who will look after the code in two years.
• Mixing patterns. Using a framework but writing raw SQL and global functions everywhere throws away its benefits.

Frequently asked questionsLink to this section#

Which framework is best for an API?Link to this section#

Laravel if the API is part of a larger product with auth, queues and an admin; CodeIgniter 4 for a small, focused API on modest hosting. If the rest of the stack is JavaScript, a Node.js and Express API can be the simpler choice.

Is CodeIgniter still maintained?Link to this section#

Yes. CodeIgniter 4 is actively maintained with regular releases and supports current PHP versions.

Can I use these frameworks with WordPress?Link to this section#

Yes, usually side by side: WordPress for content, the framework for the application, connected through the WordPress REST API or webhooks. Avoid loading WordPress inside the framework or the other way round.

How long does an upgrade take?Link to this section#

It depends on the size of the app and how far behind it is. A small app one major version behind can take days; a large app several versions behind can take weeks. Tests make every upgrade faster and safer.

Need help choosing a framework, or rescuing an existing PHP application? Send me the details.