A good share of software work does not start with an empty repository. It starts with a system somebody else built, a team that has partly moved on, and a deadline that was set before anyone read the code.
The instinct — from both sides — is to show value immediately by shipping something in the first days. It is the wrong instinct. The first week is for finding out what you are standing on, and it pays for itself several times over in the weeks after.
Day one: get it running, and time it
Before reading a single file, clone the repository and get it running locally. Write down how long it took and everything that was not in the README.
That number is the most honest metric you will collect all week. A project you
can run in twenty minutes has been cared for. A project that takes two days,
a Slack thread and a copy of someone’s .env is telling you what the last
year of maintenance looked like — and it is telling you what onboarding will
cost every future hire.
Fix it while it is fresh. A working setup script, committed on day one, is usually the highest-value change of the entire engagement, and it is the one nobody scopes.
Day one, second half: can you deploy it?
Not should you — can you. Find out whether there is a path from a merged commit to production that a new person can follow, and whether it can be reversed.
If deployment depends on one person’s machine, one person’s credentials, or one person’s memory, that is the key risk in the project, and everything else you plan is conditional on it. It is also usually fixable in days rather than weeks.
Days two to three: read, in a specific order
Reading a codebase randomly produces a feeling of familiarity and no knowledge. Read in this order instead:
- The data model. Schema and migrations first. The nouns of the system and how they relate constrain everything above them, and the schema is usually more honest than the code.
- The boundaries. What comes in and what goes out: routes, jobs, webhooks, integrations. This gives you the shape of the system without reading its middle.
- One feature, end to end. Pick a real user action and follow it from the click to the database and back. You learn the conventions, the layering, and where the layering is violated.
- The tests — and their absence. What is tested tells you what previously broke. What is untested tells you where to be careful.
git log, not just the code. Which files change constantly? Which haven’t been touched in two years? Who wrote most of it, and are they still here? Churn is the best map of risk in an unfamiliar system.
Day four: write the assessment
Not a document that grades the previous team — nobody needs that, and it poisons the relationship with whoever is still there. A document that answers four questions:
- What is solid? Say this first, and mean it. There is always something, and a report that only lists problems gets read as posturing.
- What is load-bearing and undocumented? The parts where one person’s knowledge is the only copy. This is the section a founder should read twice.
- What is genuinely risky? Security, data loss, key-person risk, anything that could produce an incident. Ranked, with an estimate.
- What would we change first, and why? One thing. Not a backlog.
Give it to the client whether or not the engagement continues. It is theirs — it describes their system.
Day five: something small, merged
Now ship. Deliberately small: a bug fix, a missing index, the setup script. The point is not the feature. It is to prove the whole loop works — branch, review, CI, deploy, rollback — while the stakes are near zero.
If the loop is broken, you have found that out in week one with a trivial change instead of in week four with something that matters.
What not to do in the first week
- Do not propose a rewrite. Not in week one, usually not at all. A rewrite discards years of accumulated business logic encoded as bug fixes nobody documented, and it reaches parity later than anyone forecasts.
- Do not reformat everything. A repo-wide style change destroys
git blame, which is the only working documentation an inherited codebase has. - Do not import your own conventions because they are better. Adopt theirs, learn why they exist, and change them later with a reason.
Why the week is worth it
Because the alternative is confident work built on wrong assumptions. Three days of reading is cheap; three weeks of building against a data model you misread is not — and that bill always arrives after the deadline is already tight.