Someone else's project is always an unknown. Nobody can say who wrote it or how, when it was last updated, or whether backups exist. So when a site is handed over to us for support, we start with a check, and the client's task list waits.
Step 1. Access and backups
First we collect access: the hosting or server, the domain control panel, the repository, the admin panel, the email. Right after that we take a full backup of the files and the database, before anything in the project changes. If there were no backups before, we set up regular ones and test a restore: a backup nobody has ever restored doesn't count as a backup.
Step 2. Technical audit
Next we look at the state of the project:
- versions of the language, the framework, and the dependencies: which of them no longer receive security updates;
- page load speed and heavy database queries;
- errors in the logs that nobody has been reading;
- certificates, email, external integrations: whatever is about to break.
The result is a short list: what's on fire, what can wait, and what is worth rewriting during the first big piece of new work.
Step 3. Ground rules
We agree on a few simple rules: where tasks are sent, how fast we respond to an outage, how changes are released. Routine changes go through a staging environment. Urgent fixes go straight to production, but with a backup and a way to roll back.
What the client gets
A working site, a clear list of risks, and a person to write to when something goes wrong. No "give us a minute, we're figuring out who wrote this": we figure that out once, at the very start.
