For developers: pricing rescue and takeover work fairly

Pricing inherited work is harder than pricing a new build because part of the job is discovering what the job is. Code that looked finished may be held together by a hard-coded value, and a feature listed as "almost done" may rest on a database design that cannot support it. A fair price reflects that uncertainty openly instead of hiding it inside one large number.

This guide covers practical structures you can use. It does not suggest market rates, because rates vary widely by country, stack, experience and client, and any figure here would be a guess.

Why rescue pricing is different

On a new project you control the architecture, so estimates improve as you plan. On a takeover, the architecture already exists and your estimate depends on how well it holds up. Three things make inherited work riskier to price:

• Hidden coupling. A change in one place breaks something unrelated because the previous structure tied them together.
• Missing context. Nobody remembers why a strange workaround exists, so you must investigate before you can safely remove it.
• Access gaps. Work stalls while the owner recovers a hosting login or a payment account that sits under someone else's name.

None of these are the owner's fault, and none are yours. Your pricing should make them visible so neither side is surprised later. If you have not yet read how to assess a takeover before you commit, start there, since a good assessment is what makes the rest of this guide work.

Charge for discovery

A discovery or assessment stage is a short, separately priced piece of work with a defined output. It answers "what is the real state of this project?" before anyone agrees to finish it.

A good assessment agreement states:

• The time box. A fixed number of hours or days, agreed upfront.
• The inputs you need. Read access to the repository, a list of services used, and ideally collaborator access to hosting and database dashboards.
• The deliverable. A written report covering what runs, what is broken, security concerns, dependency risks, account ownership gaps, and a staged plan with effort ranges.
• Ownership of the report. The owner keeps it and may share it with other providers.

Charging for this is fair. You are doing real technical work, and the owner gets something useful whether or not they continue with you. Tools such as the Repo Health Check and the Production Readiness Checklist can speed up parts of the review, but your judgement is what the owner is paying for.

Fixed-scope milestones or time and materials

Both models work for takeovers. The right one depends on how well the work is understood.

Fixed-scope milestones

Fixed pricing suits work you can describe precisely with clear acceptance criteria, such as "Stripe checkout completes for a test card and the webhook updates the order status in the database." Break the project into milestones, each with:

• A short description of the outcome
• Acceptance criteria the owner can check without reading code
• A price for that milestone alone
• What is explicitly out of scope

Smaller milestones lower the risk for both of you. If one turns out harder than expected, the damage is limited to that stage.

Time and materials

Time-based billing suits investigation, debugging with an unknown cause, and ongoing maintenance. It is honest about uncertainty, but owners can find it hard to budget for. Make it workable by agreeing:

• A rate and a billing interval
• A cap per week or per stage, after which you stop and check in
• A simple log of what you worked on, shared regularly

A hybrid that often fits

Many rescue projects end up with a time-based assessment and stabilisation stage, followed by fixed milestones for feature work once the code is understood. This matches pricing to what you actually know at each point.

Build in a risk buffer, and say so

Unknown code deserves a buffer. The mistake is hiding it. Instead, name it in your proposal and link it to specific risks you found:

• "The schema has no migration history, so changes to the orders table may need data fixes."
• "Authentication uses a library two major versions behind; upgrading may affect login flows."
• "Tests do not exist, so I will add basic coverage before refactoring checkout."

When the owner can see why the buffer exists, it reads as professional caution rather than padding. If a risk does not appear, say so at the end of the stage. Some providers return unused buffer or roll it into the next milestone; whichever you choose, state it in writing.

Use an as-found condition clause

An as-found clause records the condition of the project when you received it. It protects you from being held responsible for problems that existed before you started, and it gives the owner a clear baseline.

Include in the clause or in an attached handover document:

• The commit or snapshot you started from
• Known bugs and broken features at handover
• Security issues found during assessment, such as committed secrets
• Accounts not yet transferred
• A statement that fixing pre-existing issues is in scope only where listed

The Handover Checklist Generator produces a document with an as-found section you can adapt. Keep the wording neutral. The clause describes the code, not the person who wrote it.

Handle change requests in writing

Change is normal on rescue work. Owners see the app working again and remember features they forgot to mention. A light change process keeps this healthy:

1. Write the request down in one or two sentences.
2. Say whether it fits the current milestone or needs its own.
3. Give an effort range and any effect on the timeline.
4. Wait for written approval before starting.

A short message thread is enough written record for most projects. What matters is that both sides can point to the same agreed text later.

Communicate ranges honestly

Owners often ask for one number. A single figure for uncertain work is usually a promise you cannot keep. Give a range and explain what moves you to the low or high end:

• "Low end if the existing auth setup is sound; high end if we need to rebuild the session handling."
• "This assumes you can transfer the hosting account within the first week."

The Rescue Effort Estimator gives owners a rough effort band before they post, so some arrive with a starting expectation. If your range differs, explain why using what you saw in their code. Many owners come to TakeoverWork after a project stalled, as described on the finish a half-built app page, and they value plain answers.

Payment structure basics

Since TakeoverWork never handles project money, you and the owner agree payment terms directly. Sensible defaults for rescue work include payment per milestone on acceptance, a modest deposit before starting, and no large upfront sums for unscoped work. Put the terms, scope, milestones and as-found baseline in one written agreement before work begins. Owners are also advised on TakeoverWork never to pay the full amount upfront, so a staged plan will feel familiar to them.

Pricing checklist

• Offered a time-boxed, paid assessment with a written deliverable
• Chose fixed milestones, time-based billing or a hybrid to fit what is known
• Wrote acceptance criteria the owner can check for each milestone
• Named each risk that the buffer covers
• Recorded the as-found condition and starting commit
• Agreed a written change request process
• Gave ranges with clear reasons for the low and high ends
• Put scope, payment terms and milestones in one written agreement

More resources for providers are on /for-developers.