Taking over a Laravel app after the developer left
The app works, the person who built it is gone, and nobody knows what happens if you touch it. What I look at in the first week, in the order that stops things getting worse.
It is a common call. A company had a developer, freelance or in-house, who built a Laravel application that the business now depends on. That person has moved on. The app still runs, but nobody dares to change it, and the list of things people want changed keeps getting longer.
This is what the first week looks like when I take one over.
Day one: can we get it running somewhere that is not production?#
Before reading a single controller I want the code in a repository we control, the app running on my machine, and a copy of the database with personal data scrubbed. Surprisingly often one of those is missing: the only copy of the code is on the server, the .env has keys nobody can explain, or there are migrations that no longer run from scratch.
Nothing else is safe until this works, because every later step needs a place to try things that is not the live system.
Access and ownership#
Who owns the domain, the DNS, the server and the hosting account?
Which third-party accounts does the app use (mail, payments, SMS, storage), and whose card are they on?
Where are the backups, and has anyone ever restored one?
A surprising amount of risk lives here rather than in the code.
Versions#
Check the PHP version on the server and the Laravel version in composer.lock. An app two major versions behind is not an emergency, but it sets the order of work: security fixes for the framework and PHP stop at some point, and the jump gets harder the longer it waits.
What actually runs#
Laravel apps do a lot of work outside HTTP requests, and that is where the surprises are:
Scheduled commands in the console kernel or routes/console.php.
Queued jobs, and whether a worker is actually running on the server.
Anything in crontab that bypasses the scheduler.
Webhooks from payment or shipping providers.
If a queue worker died six months ago, some feature has been quietly not working for six months.
Tests, or the lack of them#
Most inherited apps have few or no tests. I do not start by writing a full suite. I write a handful of tests around the flows that make or lose money, such as signup, checkout and the invoice run, so the next change has something to fail against.
Then, and only then, the list#
With a running copy, known access, known versions and a few tests around the important flows, the list of wanted changes becomes something you can estimate instead of guess at. That is usually where the fixed price for the actual work comes from.
More on Laravel development and maintenance.
Was this useful?
More notes
What a technical SEO check actually finds
Not keywords. Mostly pages Google cannot see, pages it sees twice, and pages that are too slow on a phone to matter. The findings that come up again and again on small Danish business sites.
WooCommerce or Shopify for a Danish webshop
Both run fine Danish shops. The choice is rarely about features - it is about who owns the server, what the accounting sync has to survive, and how much of the shop you will want to change in year three.