How long should this take before we commit to anything?

A week for a small application, two for most. The temptation is to promise dates sooner, and the cost of doing that is that the estimate is built on an assumption rather than on the system. Reading first is cheaper than being wrong in public.

What if there are no tests at all?

Then you write a few before changing anything - not a suite, a handful over the paths that carry money or data. They are the only thing that will tell you whether your first change broke something nobody remembers depends on it.

Should we rewrite it?

Almost never, and the instinct is strongest on day three when the code is ugliest and your understanding is thinnest. Ugly code that has run in production for four years encodes rules nobody has written down, and a rewrite rediscovers them one customer complaint at a time.

Who do we ask when there is nobody left?

The git history, which is the most underused artefact in a handover. Commit messages, the order things were built, and who touched what - that is a narrative about the application, and it is usually more honest than the documentation.

You Inherited a Laravel Codebase. Read It in This Order.

The first instinct is to open the controllers. The faster route into an unfamiliar application is the schema, the queue and the deploy - in that order, before anybody asks for an estimate.

Published September 20, 20264 min readUpdated September 21, 2026

Somebody has left, or a company has been acquired, or an agency relationship has ended. There is a repository, production access, and a question about how long something will take.

The instinct is to open the controllers and start reading. It is the slowest route to understanding, because a controller tells you what one screen does and nothing about what the system is.

Here is the order that works.

1. The schema, before any PHP

The database is the most honest document in the repository. Code can be refactored on a whim; the schema is what the business actually does, and its awkward parts are where the requirements were awkward.

Read the migrations in order, or dump the current structure and read that. Look for the tables with the most foreign keys pointing at them - those are the core of the domain. Look for the ones nobody references, which are usually features that were abandoned. Look for four columns that all appear to hold a status, because that is a decision made three times by three people.

By the end of it you can usually name the five nouns the business cares about, which is more than most handover documents contain.

2. The jobs, because that is where the risk lives

Controllers do the visible work. Jobs do the work that costs money when it goes wrong - charging cards, issuing invoices, sending things to other systems, exporting data.

Read every job class. For each, ask what happens if it runs twice, because at some point each of them will. Then look at the failed jobs table in production and find out which ones already do fail, how often, and whether anybody is looking.

An application's failed job table is a summary of its unresolved problems, and it is almost always the first place nobody has checked.

3. The deploy, because it tells you what you can change

Find how code reaches production. A pipeline, a script, or somebody with SSH access and a habit.

You are looking for specific answers: do migrations run automatically, are queue workers restarted, is there a rollback, and has anybody used it. The answers decide how bold your first change can be.

If the deploy is a person following steps from memory, that is the first thing to fix regardless of what you were hired for. Everything else you do depends on being able to ship safely.

4. Composer, for the dependencies that have left

composer outdated --direct

You are looking for two things. Packages several major versions behind, which constrain what you can do. And packages that are abandoned, which are a decision waiting to happen rather than a version number.

Check which Laravel and PHP versions the application runs, and whether either is still receiving security fixes. That single fact reorders every plan.

5. Production, for what actually happens

Not the code - the behaviour. Which endpoints are slow, which errors repeat, how deep the queue gets at its worst hour, and how large the biggest tables are.

If there is no monitoring, adding it is your first week's work. An application nobody can observe is one where every estimate is a guess and every incident is a surprise.

6. The git history, last and usefully

Now that you know the shape of things, the history tells you why. Which parts are churned constantly - that is where the requirements are unstable. Which parts have not been touched in three years - that is either stable or terrifying. Who wrote what, and whether they are still there.

Commit messages from the week before a launch are the most informative documentation in most repositories, and nobody reads them.

What not to do in the first fortnight

Do not reformat anything. A whitespace commit destroys the blame history you are about to need.

Do not fix things that look wrong. On day four, unusual code looks like a mistake. On day twenty, half of it turns out to be a rule somebody learned the hard way.

Do not give a number until you have finished. The estimate everyone wants on day one is the one that gets quoted back at you in month three.

What this produces is a document: what the application does, what is fragile, what is out of support, and what would happen at three in the morning. That is the same thing our audit delivers, and whether you do it yourself or we do it, it is what every decision after this depends on.