The site audit checklist I run before taking on any client

Before agreeing to take on a client's existing site for a redesign or ongoing work, a short technical audit surfaces information that changes the scope, the timeline, or occasionally the decision to take the project at all, and skipping it in favor of getting straight to the exciting design work is a common reason projects run over budget on problems nobody knew existed at the start.

The checklist covers a handful of specific things: what's the current hosting and deployment setup, and does the client actually control it or does access live with a previous developer who's no longer reachable, what third-party integrations exist and are their credentials documented anywhere, and what does the current codebase's dependency health actually look like, current and patched, or years out of date.

The audit also checks something less technical and just as important: how was the previous developer relationship structured, and is there any reason to expect friction transferring ownership, domain access, hosting credentials, from whoever built the current site to whoever's about to take over maintaining or rebuilding it.

This audit takes an afternoon and routinely surfaces at least one issue that would otherwise have derailed the project's timeline mid-build: a domain registered under a departed employee's personal account, a hosting login nobody has access to anymore, a dependency so outdated that a simple update turns into an unplanned migration.