How to write a takeover listing that gets good responses

Developers who take over unfinished projects read a lot of listings. They are quietly asking a few questions: can I get to the code, how messy is it, is the budget realistic, and is this owner easy to work with? A listing that answers those questions clearly gets fewer vague replies and more useful ones. This guide covers each part of a takeover listing and ends with a short example.

Start with a title that says what and why

A good title names the kind of project, the main tool and the main job. Compare "Need help with my app" with "Finish Lovable booking app: fix Stripe payments and Supabase sign-in". The second tells a developer within seconds whether the work matches their skills.

Keep it factual. Words like "urgent", "simple" or "quick job" rarely help, and developers often read "simple" as a warning sign.

List everything it is built with

The built-with field is how developers search. Include:

• The builder or framework: Lovable, Bolt, v0, Replit, Bubble, FlutterFlow, Next.js, WordPress, Shopify and so on.
• The backend and database: Supabase, Firebase, Xano, a custom API.
• Services wired in: payments, email sending, maps, AI model APIs, analytics.

If you are unsure, the project's package.json file lists most JavaScript dependencies, and your AI builder's settings usually show which integrations are connected. Partial information is fine. Just say what you know.

Describe what works, what is broken and what remains

These three sections carry most of the weight. Keep them separate, because developers read them for different reasons.

What works

Describe complete actions a user can take today: "A visitor can sign up, confirm their email, create a booking and see it in their dashboard." This shows how much can be kept and how much the developer would be finishing rather than rebuilding.

What is broken or blocked

Describe the symptoms precisely. Include the exact error message, where it appears, what you were doing, and when it started. "Since the last deploy, the payment page shows a 500 error after the card is entered" is something a developer can reason about. "Payments do not work" is not.

What remains

List the remaining features in priority order and mark which are must-haves for launch. If something is a nice idea for later, say so. This helps developers suggest a sensible first milestone instead of quoting for everything at once.

Be clear about code, access and the live version

Developers often decide based on this section alone.

• Repository status. Say whether the code is on GitHub, somewhere else, only partly available, or not available at all. If the repository is public, add its link: the listing can then show a Repo Health Check card, and you can run the Repo Health Check yourself first.
• Live or demo URL. A working link lets developers see the app's real state before they reply.
• What you can hand over. Tick the accounts you control: domain, hosting, database, app store, payment provider, other APIs. Do not put passwords or keys in the listing. Access is given later through invites, once you have agreed terms.

If the previous developer still holds some of these, say so plainly. It does not put serious developers off, but discovering it later does.

Add screenshots, but check them first

Screenshots of the app, error messages and the database layout make a listing much easier to understand. Before uploading, look carefully at every image:

• No API keys, environment variable screens, tokens or connection strings.
• No customer names, emails, addresses or payment details.
• No browser tabs or notifications showing private information.

Crop or blur anything sensitive. If you are copying text such as an error log into the listing, paste it into the Secret Leak Scanner first. It runs in your browser and flags strings that look like keys.

State a budget range

A range is more useful than a single number or no number. It helps developers judge whether their approach fits, and it saves you from replies that were never going to work. Add whether you are flexible. If you have no idea where to start, the Rescue Effort Estimator gives a rough effort band from a few questions. It is a starting point, not a quote.

Price and payment are agreed directly between you and the developer, outside TakeoverWork. The platform never handles project money, so a range in the listing is only a guide for that conversation.

Give an honest completion estimate

The completion band is always shown as an approximate estimate from you. Pick the band you genuinely believe, or choose Not sure. Overstating progress tends to backfire: the developer finds out when they open the code, and the conversation starts on the wrong foot.

Describe the situation, do not blame anyone

Choose the handover reason that fits and, if useful, add a short neutral note such as "the original developer is no longer available". Never name or criticise the previous developer or agency. It does not help the new developer, and it makes the listing harder to publish and less appealing to read.

Keep contact details out

Phone numbers, email addresses and messaging handles in a listing are hidden automatically. Conversations start on the platform, and when both sides are ready either person can request contact details for the other to approve. This keeps your inbox free of spam and keeps a record of early discussions.

Example: weak listing versus good listing

Example (weak):

"App half done, last dev left. Need someone good to finish ASAP. Lots of bugs. Contact me on my email. Cheap please."

It gives no stack, no detail on what works or fails, no code status and no budget. It also includes contact details, which will be hidden, and asks for "cheap", which signals that scope may not be valued.

Example (good):

Title: Finish Lovable booking app: fix Stripe payments and Supabase sign-in

Built with: Lovable, Supabase, Stripe, Resend

What works: Visitors can browse services, sign up, confirm their email and create a booking. Admins can see bookings in a dashboard.

What is broken: Card payments succeed in Stripe, but bookings stay "unpaid" in the app. Password reset emails link to the old preview URL.

What remains: Booking cancellation with refunds (must-have), SMS reminders (later).

Code and access: Repository on GitHub, private. Live demo link included. I can give access to hosting, Supabase and Stripe through invites.

Completion: I think it is roughly three-quarters done, but I am not technical, so this is my estimate.

Reason: The original developer is no longer available.

Budget: a range in my currency, flexible for the right approach.

The good version is still short. It simply answers the questions developers would otherwise have to ask.

Before you publish

• Title names the tool, the project type and the main job
• Built-with lists the builder, database and connected services
• What works, what is broken and what remains are written separately
• Error messages are included word for word
• Repository status and live URL are filled in
• Screenshots checked for keys and personal data
• Budget range and flexibility stated
• Completion estimate is honest, or set to Not sure
• No names, blame or contact details anywhere in the text

Let the tools help with the first draft

If your notes are scattered across emails and chats, paste them into the AI Takeover Listing Writer. It turns a messy description into a structured draft that you can check and edit before publishing. If your app was built in Lovable and has stopped behaving, the Lovable app not working page lists the details developers usually ask for. And if you have not yet gathered your accounts and notes, the finishing a half-built app page is a good place to start.

When your draft is ready, post your takeover for free. Reply to interested developers promptly and answer public questions in the listing, because a responsive owner is one of the things developers look for.