For developers: how to assess a takeover before you commit

Taking over someone else's project is different from starting fresh. You inherit decisions you did not make, accounts you do not control and bugs nobody wrote down. A careful assessment before you commit is the single best way to avoid a job that drains your time and damages a client relationship. This guide walks through what to check, in what order, and how to turn what you learn into a clear interest note.

Start with the listing, not the code

A TakeoverWork listing has structured fields for a reason. Read each one slowly and note what is missing as well as what is there.

• What works today tells you what the owner believes is safe. Treat it as a claim to confirm, not a fact.
• What is broken or blocked often names the symptom, not the cause. "Payments do not work" could mean a missing webhook, an expired key, a test-mode account or a logic bug.
• What still needs to be done is your likely scope. Watch for vague items such as "polish" or "make it production ready" that can grow without limit.
• Handover reason gives context. A stalled AI tool, a previous developer who became unavailable and a budget pause all suggest different risks.
• Repo status and access ready tell you whether code and accounts can actually change hands. A listing marked "partial" for the repository deserves extra questions.

If the owner gave a completion band, remember it is their own estimate. Owners often judge progress by how many screens exist, while most of the remaining effort sits in data, edge cases and deployment.

Check repository health from the outside

When the listing includes a public repository, you can learn a lot before anyone grants you access. Run it through the Repo Health Check to see commit history, contributors, open issues, and whether a README, licence, tests or CI configuration exist.

Signals worth noting:

• Commit pattern. Many small, descriptive commits suggest a developer who worked steadily. A few huge commits with messages like "update" suggest code exported from a builder or pushed in bulk, which makes history less useful for understanding intent.
• Committed secrets. An .env file or keys in the history are a security task you must plan for, because removing the file does not remove the secret from history. Keys must be rotated.
• Branches. Unmerged branches can hold half-finished features the owner thinks are done.
• Issue tracker. Open issues, even old ones, are free documentation of known problems.

If the repository is private, ask the owner for a read-only collaborator invite once you are in conversation. Do not ask for passwords or tokens in chat; TakeoverWork blocks messages that look like credentials for good reason.

Run the code locally

Nothing replaces trying to build and run the project. Give yourself a fixed time box for this step so it does not turn into unpaid work.

1. Clone the repository and read the README, if any, before running anything.
2. Identify the runtime and package manager from lockfiles and config. A package-lock.json, pnpm-lock.yaml or yarn.lock tells you which tool was used; mixing them causes confusing install errors.
3. Install dependencies and note every warning and error.
4. Look for an example environment file. If none exists, list the variables the code reads so you know which accounts the project depends on.
5. Try to start the app. If it needs a database, check whether migrations or a schema file exist.

How far you get is itself a finding. "Installs cleanly, starts with placeholder keys, login fails without a real auth project" is precise and useful. "Did not build" is not, so record the exact error.

Look at dependency age and risk

Old dependencies are not automatically a problem, but they shape your estimate. Paste the manifest into the Dependency Freshness Check to see which packages are outdated, deprecated or several major versions behind.

Pay most attention to framework packages, authentication libraries and anything that handles payments or file uploads. A framework several major versions behind may need a migration before you can safely add features, and that migration is work the owner probably did not anticipate. Deprecated packages with no maintained replacement are worth flagging directly.

Check tests, data and migrations

Ask three questions:

• Are there tests, and do they pass? Many inherited projects have none. That is common and not a reason to walk away, but it means you will spend time writing safety nets before making large changes.
• Where does the data live, and how is the schema managed? Migration files in the repository are a good sign. A database changed by hand through a dashboard means the schema in production may not match anything in the code.
• Is there real user data? Live users raise the stakes. You will need backups, a staging environment and more care around changes to tables and access rules.

For projects on Supabase, check whether row level security is on for every table that holds user data. The Supabase RLS Checker can flag tables without policies and overly broad rules. Weak access rules are among the most common issues in AI-built apps, as covered on the AI-generated app security issues page.

Map the third-party accounts

Most of the risk in a takeover sits outside the code. List every external service the project uses and who owns each account:

• Domain registrar and DNS
• Hosting and deployment platform
• Database and storage
• Authentication provider
• Payment provider
• Email sending service
• App store developer accounts, for mobile projects
• Analytics, error tracking and any AI or API keys

If the previous developer created some of these under their own login, the owner may not be able to grant you access at all. The developer disappeared with code page explains how owners can recover control; your job is to spot the gap early and include it in your plan.

Spot scope creep before it starts

Scope creep in takeover work usually comes from three places: items listed as "small" that touch the data model, features the owner assumes exist because a screen exists, and fixes that reveal deeper problems. While assessing, write down every assumption you are making. Each one is either something to confirm with the owner or a risk to name in your proposal.

A useful habit is to sort the remaining work into three groups: understood and estimable, understood but dependent on access or decisions, and unknown until you dig in. The third group is where a paid assessment earns its keep.

Propose a paid assessment first

For anything beyond a small, well-defined fix, offer a short paid assessment before quoting the full job. The output is a written report: what runs, what is broken, the risks you found, accounts that need transferring and a staged plan with effort ranges. The owner keeps the report even if they choose someone else.

This protects both sides. The owner gets an independent view of the project for a limited cost, and you avoid committing to a price for work you have not seen. The Rescue Effort Estimator can help you frame a first rough band, but it is a guide, not a quote, and you should say so. For more on structuring the fee, see pricing rescue and takeover work.

Write a good structured interest note

TakeoverWork interest notes have four parts and no price field. Use each part with care.

• Approach. Describe your first steps for this project, not your general process. "Get it running locally, confirm the Stripe webhook setup, then review auth rules before touching features" shows you read the listing.
• Relevant experience. Name similar stacks or similar rescues. Short and specific beats long and general.
• Availability. Be honest about when you can start and how many hours you can give.
• Effort band. Pick the band that fits, or "need to review code first" when the listing leaves big unknowns.

Avoid criticising the previous work in your note. You have not seen the full picture, and the owner may have been part of earlier decisions. You can find open projects on /takeover-jobs and more provider resources on /for-developers.

Pre-commitment checklist

• Read every listing field and noted gaps and vague items
• Checked public repository health, or asked for a read-only invite
• Attempted a local build within a fixed time box and recorded results
• Reviewed dependency age for framework, auth and payment packages
• Confirmed whether tests exist and whether they pass
• Found how the database schema is managed and whether live data exists
• Listed every third-party account and who controls it
• Flagged any committed secrets that will need rotating
• Sorted remaining work into known, dependent and unknown
• Offered a paid assessment where unknowns are large
• Wrote an interest note specific to this project