Guides / Ideas and launching

How to Sell a Side Project: Preparation, Pricing, Buyers and Handover

How to sell a side project or small app: when it makes sense, getting it ready, thinking about price, finding buyers, due diligence and a clean handover.

Mythex Team · 2026-09-29 · 6 min read

To sell a side project, get its numbers and accounts in order, write down how it runs, decide what you're selling and roughly what it's worth, then find a buyer through a marketplace, a community or a direct approach, and hand it over with a written agreement and a checklist. Most of the work is in preparation: a project that is easy to understand and easy to take over is easier to sell and sells on better terms. This guide walks through each step.

If you're earlier than this and still growing the project, how to make money from an app covers monetisation, and SaaS metrics explained covers the numbers buyers will ask about.

When selling makes sense

Selling is worth considering when:

• You've lost interest but the project still has users, revenue or traffic.
• It needs more time than you can give to grow, and someone else could.
• It fits better elsewhere — a competitor, partner or bigger product could make more of it.
• You want to fund or focus on something new.

It may not be worth selling if the project takes very little effort to run and earns steadily; some people keep those. Consider too whether shutting it down gracefully or open-sourcing it serves users better.

Step 1: Know what you're actually selling

Buyers pay for different things. List what your project has:

If the project has no revenue or users, you're selling assets — code, domain, design — and should price and describe it that way.

Step 2: Get the numbers straight

Before you talk to any buyer, prepare simple, honest records for at least the last twelve months, or since launch if shorter:

• Revenue by month, from your payment provider's reports.
• Costs by month: hosting, domains, tools, paid APIs, contractors, ads.
• Profit by month (revenue minus costs).
• Customers or users: new, active, cancelled. For subscriptions, monthly recurring revenue and churn.
• Traffic sources from your analytics.
• Time you spend per week and on what.

Don't adjust or round in your favour. Buyers will check, and differences you can't explain end deals. If your records are messy, spend a month cleaning them before listing.

Step 3: Make it easy to take over

The less a project depends on you personally, the more it's worth. Work through this list:

• Write a runbook: how to deploy, where things are hosted, what runs automatically, what breaks and how to fix it.
• Separate accounts: move the project's hosting, domain, email, analytics and tools into accounts that can be transferred, not your personal ones.
• List every service and key: a table of each third-party service, what it's for, its cost and who owns the account. Never put the actual keys in the document.
• Clean up the code: remove dead features, update dependencies, make sure it builds from a fresh copy. How to review AI-generated code is a useful checklist.
• Document customer support: common questions, canned replies, open issues.
• Check your legal pages: terms, privacy policy and what they say about transferring data to a new owner.

Step 4: Think about price

There's no fixed formula. Buyers of small online projects commonly start from profit or revenue over the last year and apply a multiple, then adjust it up or down based on:

• Trend: growing, flat or declining.
• Stability: how steady income is, and how concentrated in a few customers or one channel.
• Effort: how many hours a week it takes to run.
• Age: a longer track record is more convincing.
• Risk: reliance on one platform, one supplier or one search ranking.
• Transferability: how easily it can run without you.

To get a realistic sense, look at comparable projects listed or sold on marketplaces (listing prices aren't sale prices), and consider asking a broker or adviser for a view. Decide your walk-away price before you start negotiating.

Deal structure matters too. Beyond a single upfront payment, some sales include staged payments, a share of future revenue, or a paid transition period where you help the new owner. Each shifts risk between you and the buyer.

Step 5: Find buyers

For a direct approach, a short message works: what the project is, its key numbers, why it might fit them, and a question about whether they'd like details. The principles in cold email for startups apply.

When someone is interested, share a summary first and detailed numbers only after they've shown they're serious — many sellers ask for a non-disclosure agreement at this point.

Step 6: Due diligence

Serious buyers will want to verify what you've told them. Expect requests for:

• Read-only access to the payment provider dashboard or exported reports.
• Analytics access or screenshots with dates.
• A walkthrough of the code, hosting and admin tools.
• Lists of customers or users (often anonymised until the deal is signed — check your privacy policy and local data protection rules before sharing personal data).
• Any contracts, disputes, chargebacks or complaints.

Answer promptly and honestly. Surprises found late are what kill deals.

Step 7: Agreement and payment

Put the deal in writing. A sale agreement typically covers what exactly is being sold, the price and payment terms, what happens to existing customers, your help during the transition, any promise not to build a competing product, and what happens if something turns out to be different from what was described.

For payment, many sellers use an escrow service, which holds the buyer's money until the assets are transferred, so neither side has to trust the other blindly. This is general information, not legal or tax advice — rules vary by country, so for anything beyond a small sale, ask a lawyer and an accountant.

Step 8: The handover

Use a checklist and tick items off with the buyer:

After cutover, revoke your own access, cancel services the buyer doesn't need, and keep copies of the agreement and final records.

Common mistakes

• Listing before the numbers are clean.
• Overstating growth or leaving out a dependency, which surfaces in due diligence.
• Sharing customer data too early or without checking your privacy policy.
• Skipping a written agreement because the sale is small.
• Handing over personal accounts that mix the project with your other work.

Selling a project built with Mythex

If you built the project on Mythex, the code is yours to hand over. On Pro you can export the project as a download or sync it to a GitHub repository, then give the buyer the repository or archive; secrets and environment files aren't included in exports, so the buyer adds their own keys. The buyer can import the archive into a Mythex project of their own or run it elsewhere — see how to export and self-host an AI-built app and the docs on export and running elsewhere. Plan how the database data moves, too: agree whether the buyer needs a copy of production data and handle any personal data according to your privacy policy.