For agencies: turning inherited projects into steady work

Many agencies already take on inherited projects without calling it a service. A client arrives with a half-finished app from a freelancer who moved on, or a store left behind by a studio that closed, and the team does its best. Turning that into a defined offer makes the work more predictable, easier to price and more likely to lead to long-term clients. This guide covers how to structure it, from first enquiry to ongoing care.

Offer rescue as a named service

A named service is easier to sell and easier to deliver consistently. Define it on your website and in proposals with:

• Who it is for. For example, founders with AI-built apps that work in demos but not in production, businesses with unfinished WordPress or Shopify sites, or teams whose previous provider is no longer available.
• What the first step is. Usually a fixed, paid assessment.
• What the client receives. A written report, a staged plan and, if they continue, milestones with acceptance criteria.
• Which stacks you cover. Be honest. Rescue work goes badly when a team learns an unfamiliar framework on a client's broken project.

Keep the description factual. Avoid promises about outcomes or timelines before you have seen the code.

Build a repeatable intake process

Intake is where you decide whether a project fits before anyone spends serious time on it. A short form or call script should capture:

• What the product does and who uses it today
• Stack and builder tools used, and where the code is hosted
• What works, what is broken and what remains
• Which accounts the client controls: domain, hosting, database, payment provider, app stores
• Whether real users or payments are live
• Deadline drivers, such as a launch date or investor demo
• Why the project changed hands, described neutrally

If the client has a TakeoverWork listing, much of this already exists in structured form. For a quick outside view of a public repository, run the Repo Health Check before the first call so you can ask sharper questions.

Screen out poor fits early. A project that needs a stack you do not cover, a client who will not share code before a full fixed quote, or a deadline that cannot be met are all reasons to decline politely or refer elsewhere.

Run a paid assessment

The assessment turns an enquiry into a plan. Give it a fixed time box and a named lead, and produce a consistent report each time:

1. Current state: builds, runs, deploys, or not
2. Security findings, including exposed secrets and weak access rules
3. Dependency and framework age
4. Data model and migration status
5. Account ownership and transfer gaps
6. Recommended options: stabilise, finish, partially rebuild
7. Staged plan with effort ranges and assumptions

A shared template keeps quality steady no matter which team member runs it. The Rescue Effort Estimator can give a first rough band during intake, but the assessment is what your pricing should rest on. For individual developers' views on the same steps, see how to assess a takeover before you commit.

Define team roles

Rescue projects fail inside agencies when everyone assumes someone else owns the risky parts. Assign roles explicitly, even if one person covers several:

• Rescue lead. Owns the technical assessment, the architecture map and decisions about what to change and when.
• Client contact. Owns communication, change requests and expectations. On small teams this may be the rescue lead.
• Security reviewer. Checks secrets, key rotation, access rules and authentication before anything goes to production.
• Developers. Deliver milestones against acceptance criteria and keep the characterisation tests passing.
• QA or reviewer. Tests each milestone from the client's point of view before sign-off.

Write down who approves production deploys. Inherited projects often have fragile deployment paths, and one person making an unplanned release can undo a week of careful work.

Produce strong handover documents

Documents are part of the product in rescue work. They protect the client and make your team replaceable on the project, which, perhaps surprisingly, makes clients more comfortable continuing with you.

Produce at least:

• Intake handover record. What you received, in what condition, from which commit, with known issues listed. This doubles as your as-found baseline.
• Access register. Every service, who owns it and who has access. Access is granted through invites, never shared passwords.
• Architecture overview. One or two pages a new developer can read in an hour.
• Runbook. How to set up locally, deploy, roll back, restore from backup and rotate keys.
• Exit handover. The same documents updated at the end of the engagement, plus open issues and recommendations.

The Handover Checklist Generator creates a structured starting document you can adapt to your template.

Turn rescues into retainers

A rescued project rarely stays finished. Dependencies age, platforms change their APIs, and clients want new features once the basics work. A care plan after the rescue gives the client stability and gives your agency recurring work.

Common retainer elements include:

• Monitoring and responding to errors
• Dependency and security updates on a set schedule
• Backups checked by test restores
• A monthly allowance for small changes
• A periodic review against the Production Readiness Checklist

Offer the retainer at the end of the rescue, not at the start. By then the client has seen your work and you understand the real maintenance load. Keep the scope written and review it on a regular schedule so neither side drifts.

Ethics: never disparage the previous developer

This deserves its own section because it is tempting and harmful. When you open an inherited codebase, you will find shortcuts, odd choices and outright bugs. You will rarely know why they are there. The previous developer may have had a tiny budget, changing requirements, a deadline set by someone else, or instructions to use a tool that did not fit.

Practical rules for your team:

• Describe code, not people. "The checkout logic duplicates price calculation in two places" is useful. Comments about the person who wrote it are not.
• Keep internal chat professional too. Clients sometimes see screenshots, and habits leak into reports.
• If you suspect wrongdoing, such as code withheld or accounts held back, stick to facts and point the client to the developer disappeared with code or agency abandoned project pages for neutral recovery steps.
• Remember that one day another team may inherit your work.

Clients notice this restraint. It signals that your team will treat them fairly too.

Post overflow projects on TakeoverWork

Agencies are not only providers. When you have more work than capacity, an inherited project outside your stack, or a client who needs a specialist for one part, you can post it on TakeoverWork with the poster type set to agency. Providers respond with a structured note covering approach, experience, availability and effort band, so you can compare them side by side.

Before posting, get the client's agreement to involve another provider, and remove anything confidential from the listing. TakeoverWork does not check providers, so run your own checks: review their profile and portfolio, ask for references, and start with a small paid task. Agree scope, price and payment directly with them, off the platform. You can browse open listings at /takeover-jobs, post at /post, and find provider resources on /for-developers.

Agency rescue service checklist

• Rescue offer described on the website with stacks covered
• Intake form or call script in use
• Clear criteria for declining poor-fit projects
• Assessment report template shared across the team
• Named rescue lead, client contact and security reviewer per project
• Production deploy approval rule written down
• Intake handover record, access register and runbook produced
• Exit handover documents updated at the end of each engagement
• Care plan offered once the rescue is complete
• Team guidance on neutral language about previous developers
• Process for posting overflow work, with client consent and your own checks