Taking Over an Abandoned Web Project: The 10-Step Audit I Run Before Quoting

Short answer: before anyone quotes for finishing an abandoned web project, they need a written audit: an access inventory, proof the code builds from a clean clone, a dependency and security check, the state of the database and migrations, a review of authentication and secrets, error monitoring and tests, performance, SEO continuity, code-quality hotspots and a map of the business logic. The audit takes two to five days, costs $400 to $1,200, and ends with a severity-ranked report and a fixed price for stabilisation. The rescue-or-rebuild decision follows from it, not from anyone's gut.

I take over projects other developers left behind often enough to have a fixed procedure for it. This is that procedure, written for the business owner who has to choose the next developer, with the questions to ask along the way.

What must you collect before the audit can start?

Short answer: access to everything the app touches. Half of abandoned projects are stuck not because the code is bad but because nobody knows the password to the payment gateway or where the DNS lives.

• Source code: Git repository with full history (GitHub, GitLab, Bitbucket) or, failing that, a ZIP and the server
• Hosting: Vercel, a VPS, cPanel, AWS; and the domain registrar and DNS provider
• Database: connection string or a dump, plus any hosted database dashboard (Neon, Supabase, PlanetScale, RDS)
• Third-party accounts: payment gateway, email provider, file storage, analytics, maps, SMS or WhatsApp, error tracking
• Environment variables: the .env file or the hosting platform's settings
• Documentation, the original scope, invoices, and the chat history with the previous developer
• A plain list from you: what works, what is broken, what was promised and never delivered

Which ten checks reveal whether the project can be rescued?

1. Clean-clone build. Clone the repository on a fresh machine, install, build, run. If it does not build without the previous developer's laptop, every later estimate is fiction until this is fixed. In Next.js, TypeScript errors and lint failures in the build are the usual culprits; in Laravel, missing Composer packages and PHP version mismatches.
2. Framework and dependency state. Which major version of Next.js, React, Laravel or PHP, how far behind, and whether an upgrade path exists. npm audit or composer audit for known vulnerabilities. Abandoned packages with no maintainer are flagged.
3. Database and migrations. Does the schema in the code match the production database? Are migrations present and applied? Is there a backup and when was the last one? Unmigrated manual changes are the most common time bomb.
4. Authentication and secrets. Passwords hashed, sessions expiring, admin routes protected on the server (not just hidden in the UI), API keys out of the repository and rotated if they were ever committed.
5. Payments and money paths. Webhooks verified, idempotent, and actually reaching the server; refunds handled; no orders marked paid from a client redirect.
6. Error monitoring, logging and tests. Is anything watching production? Any tests at all, and do they pass? No monitoring means the owner has been the error tracker.
7. Performance. Core Web Vitals on the key pages, unindexed queries, N+1 patterns, oversized images, blocking scripts. Quick wins here are cheap and visible.
8. SEO and analytics continuity. Are the existing URLs still served (or redirected)? Sitemap, canonical tags, structured data, Search Console access, analytics still firing after any redeploy.
9. Code-quality hotspots. Files over a thousand lines, any everywhere, copy-pasted components, business logic in UI components, no separation between data access and rendering. I map where changes would be dangerous rather than counting style violations.
10. Business logic and unknowns. A one-page map of what the app does, feature by feature, marked working, partly working, missing or unknown. The unknowns list is where the risk lives, and it becomes the first week of stabilisation.

How is the report structured?

Short answer: every finding gets a severity, an effort estimate and a recommended order. The owner reads the summary and the P0 list; the next developer reads the rest.

When should you rescue and when should you rebuild?

Short answer: rescue when the framework is current or upgradable, the data model is sound, and less than about forty percent of the core code needs rewriting. Rebuild when there is no working build from a clean clone, the framework is end-of-life with no upgrade path, or the data model must change so much that migrating it costs more than a new schema plus a data import.

Between forty and sixty percent is the grey zone. There I usually recommend a "strangler" approach: stabilise the old app, then rebuild the highest-value area (checkout, dashboard, admin) as a new module that runs alongside it, and retire the old parts one at a time. Users see continuous improvement instead of a long dark period.

What does stabilisation look like after the audit?

1. Get a clean build and a reproducible deployment with a preview environment
2. Fix every P0: rotate secrets, verify webhooks, back up the database, lock admin routes
3. Add error monitoring, uptime checks and basic logging
4. Bring migrations and the production schema back in sync; write the missing ones
5. Upgrade the framework if the path is short; otherwise pin versions and plan it
6. Write a one-page runbook: how to run, deploy, roll back, and where every account lives
7. Only then, resume features, priced from what the audit found

Stabilisation usually takes one to three weeks. On my pricing page the audit itself is $400 to $1,200; stabilisation is quoted fixed from the report.

How do you avoid the same outcome with the next developer?

• Repository, hosting and every third-party account in your name, with the developer as a collaborator
• Fixed-price milestones with acceptance criteria, paid on delivery, not on dates
• A preview URL updated at least weekly, so silence is visible early
• Written scope with exclusions; changes go through a short written change note
• A handover document as a deliverable of every milestone, not just the last
• A support window after launch, then a named rate or retainer

Frequently asked questions

What does a code audit of an existing project cost?

A written audit of a typical web application is $400 to $1,200 and takes two to five days. It ends with a prioritised report and a fixed-price quote for stabilisation.

How do I know whether to rescue or rebuild?

Rescue when the framework is current or upgradable, the data model is sound, and less than roughly forty percent of the core code needs rewriting. Rebuild when the framework is end-of-life with no upgrade path, when there is no working build from a clean clone, or when the data model has to change so much that a migration costs more than a fresh schema.

What do I need to give a new developer before they can start?

Repository access, hosting and domain access, every third-party account the app depends on, the environment variables, any documentation or chat history with the previous developer, and a list of what currently works and what does not.

The previous developer will not hand over the code. What can I do?

Check whether you have hosting access; a deployed app can often be recovered from the server, and databases can be exported. Your contract and payment records usually establish ownership. In parallel, plan for a rebuild in case recovery fails, because waiting on a non-responsive developer is the most expensive option.

How long does stabilisation take after the audit?

Typically one to three weeks to get a clean build, fix security and data issues, restore deployments and add monitoring. Feature work resumes after that.

Related: the direct answer on taking over an abandoned project, and the Next.js development and backend development services, both of which start with an audit on existing code.