When inheriting an existing website, the first hour can reveal a lot about its structure, dependencies, technical debt, and operational risks. Before changing anything, what do you usually inspect first—code organization, deployment, performance, databases, logs, access and ownership, or the site's main user flows? Have you ever taken over a site that seemed simple but turned out to have hidden integrations, outdated dependencies, undocumented jobs, or a production setup that didn't match the codebase?
4 Answers
I first verify that the repository actually matches what is running in production. I’ve inherited sites where someone had been applying fixes directly over FTP for years, while the Git history described a completely different application. Comparing the live server with the repository can prevent you from undoing a production fix or trusting code that is no longer deployed.
Once I understand the live behavior, I inspect how the application is built and deployed: language and framework versions, dependency and lock files, database structure, build scripts, environment variables, and rollback steps. Consistency across the codebase matters more than whether it follows a particular framework. I also want to know how changes reach production before making any, because an undocumented deployment process makes every change risky.
Getting it running locally is a useful health check by itself. If setup takes hours before you’ve changed a line, that already tells you a lot about the maintenance state.
Before reading much code, I sort out ownership and access: the domain, DNS, hosting, email delivery, repositories, backups, and any external services. Then I get the project running in a safe environment and test an actual backup restore. A backup that has never been restored successfully is only an assumption. I also look for scheduled jobs, webhooks, payment systems, order syncs, and other integrations that may not be obvious from the main site.
The distinction between having a backup and knowing it restores is huge. Hidden scheduled tasks and third-party services are often what turn a supposedly small takeover into a much larger project.
I walk through the main visitor journey before opening the code—login, signup, contact forms, checkout, or whatever the site is actually built to do. That quickly separates things that are merely dated from things that are genuinely broken. I’ll also check server metrics, logs, browser errors, and the Network tab for failed requests, slow responses, duplicate libraries, or missing assets.
The Network tab often tells you more than the console. I’ve found unnecessary duplicate libraries, missing fonts, and painfully slow requests there that nobody had noticed during normal browsing.
When the live system and repository differ, is there usually any explanation for the old fixes, or do you have to reconstruct the history from the server itself? That kind of handover can feel like archaeology.