1. Decide what is actually for sale
List the code, domain, brand, designs, data, accounts, documentation, content, and customer relationships separately. Confirm who owns each asset and whether it can transfer. A repository by itself is rarely the whole product.
2. Replace potential with evidence
Buyers discount vague upside. Use dated screenshots, analytics exports, customer messages, revenue records, and working product access. If something is an estimate, label it as one.
3. Explain why you stopped
A direct answer reduces suspicion. Loss of interest, a new job, lack of distribution, or a strategic shift can all be understandable. Hiding the reason makes the buyer invent a worse one.
4. Price the head start—not your hours
Sunk time does not set market value. Consider replacement cost, usable quality, traction, operating burden, known risks, strategic fit, and the number of plausible buyers.
5. Build the handoff before accepting an offer
Write setup instructions, document the deployment, list recurring costs, identify secrets and credentials, and state what support you will provide. The smoother the first week feels, the more credible the opportunity becomes.
6. Disclose what still needs work
Known bugs and missing features do not automatically kill a sale. Surprises do. Give buyers a prioritized view of technical debt, customer obligations, platform dependencies, and compliance concerns.
Ready to make the project legible?
Start with a private submission. There is no obligation to list.
Submit a project