What To Do When Your Laravel Developer Disappears

A calm, ordered recovery plan for founders locked out of their own Laravel application: regain access, stabilise production, and get an independent read on the codebase before you hire anyone else.

It happens more often than anyone admits. The developer who built your Laravel application stops replying. Invoices go unanswered, the staging site drifts out of date, and nobody left in the business knows how to deploy. The instinct is to hire a replacement immediately. That is usually the wrong first move — you cannot brief a replacement on a system you do not control yet.

Here is the order of operations we use when a founder calls us in this situation.

1. Establish what you actually own

Before touching code, write down every account the application depends on and who controls it:

  • Source control — GitHub, GitLab or Bitbucket. Are you the organisation owner, or is the repository sitting in a personal account?
  • Hosting — Forge, Vapor, Ploi, a raw VPS, or a managed platform. Who is the billing owner?
  • Domain and DNS — registrar login and DNS provider, which are frequently different.
  • Database — managed Postgres/MySQL, or a database living on the same VPS with no backups.
  • Third-party services — Stripe, Mailgun/Postmark, S3, Sentry, Redis, any API the app calls.

Ownership, not access, is what matters. A shared password can be changed by the other party at any time. Transfer billing ownership where you can, and add yourself as owner — not collaborator — everywhere else.

2. Freeze production before you change anything

Do not let a panicked deploy be the event that takes the site down. Take a full database dump and a copy of the storage directory today, store both somewhere you control, and confirm the dump actually restores into a local container. An untested backup is a rumour.

If the developer still has active credentials and the relationship has ended badly, rotate keys in this order: hosting SSH keys and deploy tokens, then APP_KEY-adjacent secrets that are not used for encryption at rest, then third-party API keys. Rotating APP_KEY itself will break every encrypted column and every existing session — check Crypt, encrypted casts and Cashier data before you touch it.

3. Get the application running somewhere you control

The single best signal of codebase health is whether a stranger can boot it. Clone the repository and try to bring it up locally or in a fresh container:

composer install
cp .env.example .env
php artisan key:generate
php artisan migrate --seed
php artisan test

Note every step that fails and every undocumented environment variable you had to guess. If .env.example is missing or stale, that alone tells you the project was never handed over properly.

4. Read the risk surface, not the whole codebase

You do not need to understand every line. You need to know what will hurt you in the next ninety days:

  • Which Laravel and PHP versions are in use, and whether either is out of security support.
  • Abandoned Composer packages and known CVEs — composer audit gives you a first pass in seconds.
  • Whether queues and the scheduler are actually running in production, or whether half the features quietly stopped working months ago.
  • Whether there are any tests at all, and whether they pass.
  • Hardcoded credentials, APP_DEBUG=true in production, and public storage buckets.

5. Decide: continue, upgrade, or rebuild

Most abandoned Laravel applications are worth continuing. Laravel is stable, boring and well documented, and a competent engineer can usually pick up a 30k-line codebase in a week. Rebuild is the right answer far less often than agencies claim — typically only when the app is on an unsupported PHP version, has no tests, and the domain logic is genuinely small.

The decision should be written down with numbers next to it: upgrade cost, rescue cost, rebuild cost, and the risk of each.

6. Only then hire

With access, a working local environment and a ranked risk list, you can brief anyone — an agency, a contractor, or an in-house hire — in a single call. You will also be able to tell within a week whether the person you hired is any good, because you know what the problems are.

Getting an independent read

If you would rather not do steps 3 and 4 yourself, that is exactly what our Laravel Triage Audit is: $299, five business days, a written risk register and a plain-language recommendation to fix, upgrade or rebuild. It is deliberately independent — the document is written so you can hand it to any Laravel developer, including one who is not us.

Next in this series: the Laravel application takeover checklist, which turns steps 1 to 4 into a document you can work through line by line.