On staff augmentation engagements, we generally don't touch requirements in the first week. Rushing to write something to prove you're busy is the least useful thing you can do. Start with five small tasks instead.
1. Get the System Running Locally
Not reading docs — actually clone, install dependencies, configure the environment, connect to the test database, and get it running. Every step that fails is a gap in the docs; patch the README the same day. This pass also tells you the language version, how many services there are, and whether cron jobs exist.
2. Find Where the Logs Live
Application logs, Nginx access logs, slow-query logs, cron job output — which machine, which directory, how many days of retention. When something breaks, the first move is reading logs; if you can't find the log files, everything after that is guesswork.
3. Build an Account Inventory
Code repos, databases, servers, domains, certificates, third-party APIs — which accounts exist, who's the admin, whether any are shared. On one engagement we found 3 shared accounts where each side assumed the other was managing them; nobody had ever changed the passwords. The client rotated them the day we handed over the list.
4. Walk Through the Deploy Steps
No release — just run the process end to end in staging: which branch to pull, where config lives, how to roll back, who has access. Note every step that snagged and how long it snagged for. This beats reading ten pages of deployment docs.
5. Ask Who to Call When Things Break
Not a contact directory — a clear map of "which problem goes to which person". Slow database: who? Page down: who? Third-party API unreachable: who? And on the client side, who makes the final call? It's worth asking at what hour you should stop calling and switch to messages.
The Checklist Itself
When the five tasks are done, the output is usually a two-page document plus a table. Not pretty — no architecture diagram, no grand roadmap.
Once a client read the whole thing and said, "This is all you wrote in week one?" Yes. The next week they changed how work got assigned on their own — requirements used to come out of three different people's mouths separately; now everything enters one queue. The change wasn't directly ours; it was forced out by the account inventory and that "who decides" column.
The hardest part of being on-site isn't the technology — it's taking over something nobody can fully explain but that runs every day. The first week should be spent making it explainable.
