This one began as a CodeIgniter project in the autumn before the Laravel work started. The owner ran a small European business on a web application they had commissioned years earlier, and the framework underneath it had reached the point where every change cost more than it should. We rebuilt it in Laravel the following spring and then looked after it for the next four years.
The problem: a working application nobody wanted to touch
The CodeIgniter application did its job. The trouble was everything around that job. Authentication, validation and database access were hand-written in the style of the time, there were no automated tests, and the framework version had fallen behind the PHP releases the host was pushing out. Each small request from the owner turned into a cautious afternoon of checking what else might break.
For an owner-operated business there is no in-house developer to absorb that cost. The owner wanted an application they could keep asking for changes to, from someone who would still be around to make them.
What we built
- A Laravel rebuild of the existing application. The screens, workflows and rules the business depended on were rebuilt on Laravel's conventions: Eloquent for the data layer, Laravel's authentication and validation in place of the hand-written versions, and Blade templates for the views.
- The data came with it. The existing database was migrated rather than recreated, with a mapping written for every table and field so the owner lost nothing in the move.
- Behaviour matched before anything new was added. The first milestone was the new application doing exactly what the old one did. Only once the owner had signed that off did the feature requests start.
- A deployment the owner did not have to think about. Hosting, releases and PHP updates were set up so that shipping a change was a routine step, not an event.
How the retainer worked
After launch the relationship ran as a maintenance retainer for roughly four years:
- Framework and PHP kept current. Laravel releases and PHP versions were taken as they arrived, so the application never drifted back into the state it had been rescued from.
- Changes on request. New features and adjustments were scoped, built and released by the same engineer who had done the rebuild, which kept each change small and the turnaround short.
- Fixes and server upkeep included. Bugs, security patches and hosting issues were handled as part of the monthly arrangement.
The outcome
An application that had become something to avoid became something the owner could keep investing in. Four years of maintenance later, it was still on a supported framework and a supported PHP version, with features added along the way and no second rebuild in sight. The rebuild paid for itself by making every later change cheap.
Running something similar?
If you have an application on an old framework or an old Laravel release, start with the free audit. We will tell you honestly whether it needs an upgrade or a rebuild, and what either would cost. Or see the care plans that keep it current afterwards, or talk to us.