Overview

Taking over an existing site is very different to starting a greenfield project. The challenge isn't building something new, it's understanding what's already there, how it works and where the risks are before making any changes. Here I'll walk through the process I typically follow during the first 48 hours after inheriting a project from a new client.

The Starting Point

The handover process varies wildly between projects - sometimes I've received super detailed documentation, architecture diagrams and credentials. Whereas, other times it's literally a forwarded email containing a ZIP file and a message saying the previous agency is no longer involved, this actually happens more times than you would think.

Before touching the code, my goal is to build a high level understanding of the platform and identify any immediate risks.

1) Can I Get the Project Running Locally?

My first priority is getting the project running on my machine. If I can't run the code locally, then I can't investigate issues, safely develop features or understand how the application behaves.

  • ✓ Confirm the Node.js version
  • ✓ Install dependencies
  • ✓ Identify required environment variables
  • ✓ Understand build and startup commands
  • ✓ Check whether any third-party services are required

This stage often uncovers missing documentation, expired credentials or assumptions that only existed in the previous developer's head.

2) Understanding The Architecture

Once the project is running, I start mapping out how everything fits together.

  • • Is this headless Shopify, WordPress or a custom build?
  • • Is the frontend built using React, Next.js or Remix?
  • • Is there a CMS involved?
  • • How is content managed?
  • • What third-party services does the business rely on?

At this stage I'm not trying to understand every file, I'm trying to understand how the business operates through the technology.

3) Following The Customer Journey

Before reviewing technical debt, I like to understand the experience from a customer's perspective.

  • • Can customers browse products as expected?
  • • Can they complete checkout?
  • • Are forms working correctly?
  • • Are confirmation emails being sent?
  • • Are analytics tracking key events?

This quickly highlights the areas of the platform that are most critical to the business.

4) Understanding Deployments

One of the most important things to establish early is how code reaches production.

  • ✓ Where is the site hosted?
  • ✓ How are deployments triggered?
  • ✓ Is there a staging environment?
  • ✓ What are my rollback options?
  • ✓ Who currently has access?

If a production issue occurs, understanding the deployment pipeline can save hours of stress and investigation.

5) Identifying Technical Debt

Once I understand the platform, I begin reviewing the overall health of the codebase.

  • • Outdated dependencies
  • • Security vulnerabilities
  • • Performance bottlenecks
  • • SEO issues
  • • Missing tests
  • • Inconsistent coding patterns
  • • Lack of documentation

The goal isn't to fix everything immediately, but rather identify where effort will have the biggest impact.

6) Creating Documentation

One of the most valuable things I can do early in a project is document what I've learned so far.

    This often includes:
  • ✓ Environment setup instructions
  • ✓ Deployment processes
  • ✓ Architecture diagrams
  • ✓ Third-party integrations
  • ✓ Development workflows

Good documentation and solid READMEs makes onboarding future devs significantly easier and reduces reliance on any one individual.

Final Thoughts

Most clients don't need somebody to immediately start building features, but they need somebody who can quickly understand an unfamiliar platform, identify risks and create a clear plan for moving forward.

Those first 48 hours are usually less about writing code and more about building understanding. Once you understand the platform, the people using it and the business goals behind it, the technical decisions become much easier.