How to evaluate developers who want to finish your app

When you post a project that is already partly built, the replies you get are not all equal. Some developers have read your listing carefully and thought about your stack; others send the same message to every project they see. This guide shows how to compare the people who send interest, what to ask them, and how to test the working relationship with a small paid task before you hand over the whole project.

What TakeoverWork checks, and what it does not

TakeoverWork connects people who need a project finished with developers and agencies who do that kind of work. It does not employ, supervise or test the people who reply, and it never handles project money. Badges on a profile each mean one narrow thing:

• Email verified means the person confirmed an email address.
• GitHub connected means they linked a GitHub account, and the profile shows how old that account is.
• Business verified means a submitted business name and registration number were compared with a public register.

None of these tells you anything about code quality, honesty or availability. Hover over any badge to read exactly what was checked. Judging the person is your job, and the rest of this guide is about doing it well.

Read the structured interest notes side by side

Every interest on TakeoverWork arrives as a structured note with four parts: how the developer would start, their relevant experience, their availability, and a rough effort band (or "need to review code first"). There is no price field and no bidding, so you compare approaches rather than numbers. Open your dashboard and read the notes next to each other.

Look for:

• A starting plan that fits your listing. If your listing says Stripe webhooks fail and users cannot reset passwords, a strong note mentions those exact issues. A note about "modern scalable solutions" that never touches your problems was probably not written for you.
• Experience with the same kind of project. Finishing a Lovable app on Supabase is different from finishing a Bubble app or a WooCommerce store. Ask for one example close to your stack.
• Honest effort bands. "Need to review code first" is often the most honest answer for a codebase nobody has opened yet. Be cautious of anyone who promises a short fixed timeline without seeing anything.
• Availability that matches your deadline and time zone. A few hours a week may be fine for a small fix and wrong for a launch next month.

Questions worth asking before you share any code

Use the conversation to ask a few direct questions. The answers matter, and so does how clearly they are written.

1. "What would you look at first in our project, and why?"
2. "Tell me about a project you took over from someone else. What was the hardest part?"
3. "How do you report progress, and how often?"
4. "What do you need from me to start, and what access would you ask for?"
5. "If the code needs more work than expected, how and when would you tell me?"
6. "Who will actually do the work: you, a team member or a subcontractor?"

The last question matters most with agencies. Using a team is normal, but you should know who is touching your code and who your main contact is.

Good answers are specific. "I'd run the app locally, check the Supabase policies, then reproduce the checkout bug" is specific. "I will analyse everything and deliver an excellent result" is not.

Look at real evidence: portfolio and GitHub history

Rescued and finished projects

Provider profiles can mark portfolio items as rescued or finished projects. These are the most useful examples for you, because inheriting someone else's code is a different skill from starting fresh. Ask what state each project was in when they took it, what they changed, and whether you can see the live result.

Profiles also show two separate numbers: takeovers continued via TakeoverWork, which are counted when customers mark a connection as continued, and rescue projects the developer reports themselves. Treat the self-reported number as a claim to discuss, not a fact.

GitHub history

A public GitHub profile is not required, and many capable developers do most of their work in private client repositories. If there is public history, it can still tell you a few things:

• Do commit messages explain what changed, or are they all "fix" and "update"?
• Do projects have a README that tells someone else how to run them?
• Is activity spread over months or years, or did the account appear last week?

Paste a public repository URL into the Repo Health Check to see the last commit, whether tests and CI exist, and whether secrets were committed. Run it on a project the developer points you to, and on your own repository, so you both start from the same picture.

Start with a paid code review as the first milestone

The safest way to test a new working relationship is a small, paid, clearly defined first task. For a takeover, the natural first task is a code review. The developer gets read-only access, studies the project, and delivers a short written report.

A useful review report covers:

• How to run the project locally, and what was missing to do so
• What works, what is broken and what is unfinished
• Security issues found, such as exposed keys, missing access rules or weak login handling
• Recommended fixes in order of priority
• An effort range for each fix, with the assumptions stated
• Questions the code alone could not answer

A review does several jobs at once. You see how the developer writes and communicates. You get a document you own and can show to someone else if you do not continue. And the developer is paid for the time it takes to understand an unfamiliar codebase, which is real work. If two candidates seem equally good, some owners pay both for a short review and compare the reports.

Before the review starts, run the Rescue Effort Estimator yourself. It gives a rough band, not a quote, but it helps you notice when someone's estimate is far from what the project's size suggests. For setting up payment around this first milestone, see Paying a developer safely.

Judge communication during the first week

How someone communicates before you pay them is usually the best preview of how they will communicate afterwards. During your first exchanges and the review, notice:

• Do they reply within the time they said they would?
• Do they ask questions, or do they assume?
• When they do not know something, do they say so?
• Do they write decisions down, or keep everything vague?
• Do they push back politely when you ask for something unrealistic?

A developer who says "this will take longer than you hoped, and here is why" is often a better choice than one who agrees to everything.

Red flags to act on

Some behaviour should make you pause, however good the portfolio looks.

• Asking for your passwords. A developer never needs your personal login. Give access through collaborator or team invites on GitHub, your hosting, Supabase and other services, so you can remove it later. Our guide on giving access without sharing passwords shows how on common platforms. TakeoverWork blocks messages that look like they contain secrets for the same reason.
• Asking for 100% upfront. Paying everything before any work is delivered leaves you with no leverage. A partial deposit for the first milestone is normal; the full amount is not.
• Pushing to move to another chat app at once, before anything is agreed, where there is no shared record.
• No questions about your project. If they have not asked about your stack, users or deadline, they do not know enough to promise anything.
• Wanting to rebuild everything before looking. A rebuild is sometimes right, but that conclusion should come after a review, not before.
• Refusing any written agreement, or insisting the code stays in their own account until the end.
• Pressure tactics such as "the price goes up tomorrow" or "another client is waiting".

If something feels wrong, you can report or block a user from the conversation. Our safety page explains how.

Making the final choice

After the review, score each candidate on the points that matter to you: understanding of your problem, relevant experience, quality of the review, communication, and fit with your budget and timeline. Write one sentence explaining each score. This is not about precision; it helps you notice when you are choosing on charm rather than evidence.

If your project mostly works and just needs the last parts done, our page on finishing a half-built app explains what usually remains and how to describe it. Once you choose someone, prepare a clean starting point with the Handover Checklist Generator, so the work begins from a shared list of accounts, environments and known issues.

Checklist before you say yes

• I compared at least two interest notes side by side
• The developer described a starting plan that fits my project
• I have seen at least one rescued or finished project they worked on
• I know who will actually do the work
• We agreed a paid code review as the first milestone
• Access will be given by collaborator invites, never by sharing passwords
• Nobody has asked for full payment upfront
• Scope, price and milestones for the next stage are written down