It usually starts with a message like “our developer is gone and something broke”. Before anyone changes a line of code, the first week is for finding out what you actually have. Here is the checklist, in order.
1. Get the keys
Access comes first, because everything else depends on it. List every account the product lives in and confirm you own each one, not a former developer:
- Source code repositories and who can see them
- Hosting and cloud accounts, and the billing for them
- The domain and DNS
- Apple and Google developer accounts
- Payment, email, SMS and analytics providers
- Error tracking, logs and any admin panels
If an account is in someone else’s name, moving it is the first job. Without it, you do not control your own product.
2. Can it be built from scratch?
Clone the code onto a clean machine and follow whatever instructions exist. If nobody can build and run the app from nothing, that is the most important finding of the week. It means the knowledge lived in one person’s laptop.
3. What does it cost to run?
Add up hosting, third-party services and licences. Surprises here are common and usually fixable: old test servers still running, services nobody uses, plans bigger than the traffic needs.
4. Where is the risk?
- Secrets. Keys and passwords committed into the code or shared in chat.
- Dependencies. Libraries so old that they no longer receive security fixes.
- Data. Are there backups, and has anyone ever restored one?
- Tests. Is there anything that tells you a change broke something?
- Releases. Is deploying a button or a ritual?
- Monitoring. Would anyone know if it went down at night?
5. Read the code, briefly
You are not judging style. You are looking for how hard it will be to change: is the structure understandable, is the same thing done five different ways, which parts do people avoid touching. Ask whoever knew it best, if you can reach them.
Common surprises
- The app depends on a personal account of someone who has left.
- A certificate, key or subscription is about to expire.
- The only person who knew how to deploy was the one who left.
- Monthly costs for things nobody uses.
- A library the whole app depends on is no longer maintained.
What not to do in week one
- Do not rewrite it from scratch. A rewrite is rarely the cheapest route, and you lose the knowledge buried in the old code.
- Do not add features yet. Every change on an unstable base is riskier than it looks.
- Do not change many things at once. Small, reversible steps tell you what caused what.
What you should have after week one
- Every account under your control.
- A way to build and run the app that others can repeat.
- A short, honest report: what is solid, what is fragile and what is dangerous.
- A list of fixes in order: do now, do soon, can wait.
- A plan and a price for stabilising it, so you can decide before you spend.
Only then does it make sense to start adding features. Stabilising first costs a little time and saves a lot of rework.