Service

Laravel, CodeIgniter and the PHP that is already running your business

New Laravel applications, and the less glamorous work of keeping older PHP systems secure, supported and possible to change. Both matter, and the second one is harder to find help with.

  • New application development in Laravel
  • CodeIgniter maintenance and staged modernisation
  • Legacy PHP support, security patching and refactoring
  • API development and integration between systems
PHP source code displayed in a dark code editor

What kind of PHP work do you take on?

Three kinds. New applications built in Laravel, where the framework's structure and tooling earn their place. Maintenance of CodeIgniter and older PHP systems that still run daily operations and cannot simply be replaced. And the modernisation work in between: upgrading PHP versions, removing abandoned dependencies, adding tests around the risky parts and refactoring in stages that keep the system running throughout.

  • New builds where a framework is genuinely warranted
  • Support for systems other developers have declined to touch
  • Staged modernisation rather than a risky rewrite

Common situations

The PHP problems we get called about

  • The original developer is gone

    A system that runs the business, no documentation, no tests, and nobody who knows why a particular file is the way it is.

  • Stuck on an unsupported PHP version

    The host is pushing an upgrade, the code will not run on it, and nobody knows how much will break.

  • It slows down every year

    Queries that were fine on ten thousand rows are not fine on two million, and nothing was ever indexed for the way the data grew.

  • Security findings with no owner

    A penetration test or an insurer's questionnaire has produced a list of issues and there is nobody to hand it to.

  • Abandoned dependencies

    Composer packages that stopped being maintained years ago, now blocking every other upgrade.

  • A rewrite that stalled

    A replacement was started, ran out of budget, and now two systems run in parallel with data in both.

Scope

What Laravel and PHP engagements cover

New Laravel builds

  • Application architecture and data modelling
  • Authentication, roles and permissions
  • Queues, scheduled jobs and notifications
  • Test coverage on the logic that matters

Legacy support

  • Codebase assessment and risk report
  • Security patching and dependency updates
  • PHP version upgrade planning
  • Documentation of how the system actually works

Modernisation

  • Staged refactoring with the system live throughout
  • Introducing tests around high-risk areas first
  • Extracting logic from templates and controllers
  • Replacing abandoned dependencies

Performance

  • Query profiling and indexing
  • Caching strategy appropriate to the workload
  • Background processing for slow operations
  • Load behaviour measured, not assumed

Integration

  • REST API design and versioning
  • Third-party API consumption with retry handling
  • Webhook endpoints with verification
  • Scheduled synchronisation between systems

Operations

  • Environment separation and configuration management
  • Deployment process and rollback
  • Error logging and alerting
  • Backup and restore verification

Legacy work

Why we do not lead with a rewrite

A full rewrite is the most expensive and highest-risk option available, and it is the one most frequently proposed, because reading someone else's code is harder than writing your own. It also means running two systems in parallel for months while the new one catches up with behaviour the old one accumulated over a decade.

We start instead by making the existing system safe to change: understand it, document it, patch the security issues, get it onto a supported PHP version, and put tests around the parts that would hurt most if they broke. From there, replacement becomes a series of decisions you can afford to make one at a time — and sometimes it turns out you never needed the rewrite at all.

  • Assessment and written risk report before any code changes
  • Security and supportability addressed first
  • Refactoring in increments, with the system live throughout
  • Replacement considered per component, not all at once
Two developers reviewing an existing codebase together at a screen

Stack

What we work with

Frameworks

  • Laravel
  • CodeIgniter
  • Plain PHP
  • Composer
  • Blade templates

Data

  • MySQL
  • MariaDB
  • Query profiling
  • Migrations
  • Redis caching

Operations

  • Git workflows
  • Staging environments
  • Scheduled jobs
  • Queue workers
  • Error logging

Questions

Laravel and PHP questions

Will you take on a system you did not build?
Yes — that is a large part of this service. We start with a paid assessment so we are reading the actual code, database and hosting rather than working from a description. You get a written report on what it does, what is risky and what it would take to make it maintainable, and you are free to act on that with anyone.
Our system runs on an old PHP version. Can it be upgraded?
Almost always, though the effort varies enormously. The assessment establishes which language features and dependencies are blocking the upgrade, and the work is planned in stages with the system tested at each version step rather than jumping several at once.
Do you write tests?
On the parts where a failure is expensive: business rules, calculations, permissions and integrations. Blanket coverage on a legacy codebase is rarely a good use of budget. On new Laravel builds, tests are written alongside the features as a matter of course.
Can you work alongside our in-house developer?
Yes, and it usually works well. We agree ownership boundaries, code standards and review process up front. Your developer keeps context on the system, and we bring capacity or specific experience where it is needed.
What if the honest answer is that the system should be replaced?
Then we will say so, explain why, and set out what replacement involves and what it would cost — including the option of doing it component by component. We would rather lose a maintenance engagement than take money to keep something alive that should not be.

Have a PHP system that needs attention?

Tell us what it does, what version it runs on and what is going wrong. An assessment will tell you where you actually stand.