At some point you will own software nobody on your team wrote. A developer moved on, an agency finished and moved off, you acquired a company, or the original build was three years and two contractors ago.
The instinct is to start reading files. That is the slowest possible route. Code tells you what the system does; it does not tell you what matters. Here is the order that gets you oriented quickly.
Start with how it deploys
Before any application code, find out how a change reaches production.
That single question answers several others. If there is a pipeline, the project had
discipline. If deployment is a document titled deploy_steps_FINAL.txt, expect
undocumented state on the server, configuration that exists only in one person’s
memory, and a transfer that can
stop halfway and leave the site in a state nobody designed.
If nobody can tell you how to deploy at all, that is the first thing to fix,
because until you can ship safely you cannot fix anything else.
Look for: the CI configuration, environment variables, and whether staging resembles production in any meaningful way.
Then read the data model
The database schema is the most honest document in any codebase. Code lies — it contains abandoned experiments, dead branches, and the ambitious refactor someone started. The schema reflects what the business actually stores, and it is the hardest thing to change later.
Read every table and ask what it represents in the real world. Where the schema is
confused — a table called data, a column called type_2, three tables that clearly
duplicate each other — you have found where the original team’s understanding broke
down. That is also where the bugs live.
Then follow one request end to end
Pick the most important thing the system does. A user signing in, an order being placed, a case being created. Follow it from the interface through to the database and back.
One complete trace teaches you the project’s conventions faster than reading a hundred files: how routing works, where validation happens, whether business logic sits in controllers or services, how errors propagate, what the team’s habits are.
Then follow a second one, and check whether it works the same way. If two comparable flows are built differently, the codebase has no single author and you should expect inconsistency everywhere.
Three things to check before you promise anything
Whatever you are asked to estimate, check these first.
Are there tests, and do they run? Not coverage percentage — can you run the suite, and does it pass on a clean checkout? A codebase with no tests is not unworkable, but every change carries risk you cannot measure, and estimates must widen accordingly.
Are the dependencies still supported? An application on a framework version that stopped receiving security updates has a bill attached, and it is usually due before whatever feature you were asked about. Find that out before quoting the feature.
What is not in version control? Configuration on the server, a cron job somebody set up by hand, a file uploaded once and never committed. This is the category that turns a two-week job into a six-week one, because you discover it at deployment.
What to write down
You will forget most of this within a fortnight. Before moving on, write a single document containing: how to run it locally, how it deploys, what the main data entities are, which parts you would not touch without care, and what you have not yet looked at.
That last section matters most. An honest map with acknowledged blank areas is far more useful than one that pretends to be complete — to you in a month, and to whoever inherits it after you.
How long it should take
For a mid-size application — say a web app, an API, and a database — expect two to four days to get genuinely oriented and produce that document. Less than that and you are guessing. Much more and you are reading code you do not need yet.
The point is not to understand everything. It is to know enough to say honestly what a change will cost, and to know which parts you are still unsure about.
We do architecture reviews on inherited codebases — a written assessment of what will break as you grow and what to fix first. Tell us what you inherited.