Relaunch only if something important has changed since the product stopped, and give the attempt a firm deadline. Otherwise, sell. A relaunch keeps every option open but costs time, money and focus, and most of the reasons a product ends do not fix themselves. A sale settles the question now, at a price you know before you sign. Relaunch first and you can still sell later if it fails; sell first and the relaunch option is gone.
What relaunching and selling each involve
Relaunching means taking the product back to market yourself: updating the code, paying for hosting, getting back into the app stores and finding customers again. The upside is open-ended and so is the effort. It also assumes you still hold the rights: if the code belonged to a company that has since been dissolved, check who owns it now before investing a single weekend.
Selling means accepting a concrete cash offer for the code as it is. Odys AI Labs, the research and development arm of Odys, buys the code of software no longer in use and uses it for AI training and R&D. We never relaunch the product as yours or use your name. The offer comes after a review based on what you tell us, with no obligation.
Relaunch or sell, factor by factor
| Factor | Relaunch it yourself | Sell the code |
|---|---|---|
| Upside | Open-ended if it works | A known cash price |
| Downside | Months of work and spending, possibly for nothing | You give up the chance of a comeback on this code |
| Cash in the next few months | Usually negative | One agreed price, paid on transfer |
| Work needed | Dependency updates, security fixes, store compliance, marketing | Describing the product, then cleaning secrets and personal data with our help |
| Depends on | Market demand, your time, your funding | The code: size, originality, quality, history, docs and tests |
| Your name | On the product again | Never used |
| Reversible | You can stop and sell later | Final after transfer |
| Best for | Owners with new evidence and real time to give | Owners who have moved on |
What a restart actually costs
The code you shelved has kept aging. Black Duck’s 2026 open source report found that 92% of audited codebases contain components four or more years out of date, and only 7% of components in use are the latest versions. The same research found that 87% of codebases had at least one known vulnerability. A restart begins with upgrading third-party code and fixing whatever broke along the way.
Mobile apps face platform deadlines on top of that. Apple can flag an app for removal if it has not been updated within three years and falls below a minimal download threshold, giving the developer 90 days to submit an update. On Android, Google Play has required existing apps, since August 31, 2026 (with extensions possible to November 1, 2026), to target Android 15 (API level 35) or higher to remain available to new users on newer devices. A dormant app often needs a real engineering project just to be listed again.
Then there is the market. US Bureau of Labor Statistics data shows that only about half of new private sector business locations survive five years (51.4% of those opened in the year to March 2020 were still open in March 2025). The reasons your product stopped (too few customers, a stronger competitor, a funding gap) are likely still there unless you can point to what changed.
When relaunching wins
Relaunch yourself when most of these are true:
- There is new evidence of demand. Former users ask for it, a waitlist is growing, or a competitor has left.
- The original blocker is gone. You have the funding, the co-founder or the platform access you lacked before.
- You have the time. Not evenings for a month, but sustained time over a period you can name.
- The code is in good enough shape. A recent framework, a working test suite and clear docs make a restart much cheaper.
- You would regret not trying. That counts too, as long as it comes with a deadline.
When selling wins
Sell when the honest answer to “what has changed?” is “nothing much.” That is the usual case for a dead mobile app, a SaaS product that never found enough paying customers, or a product built but never launched whose builder has moved on to other work.
Selling also wins when the code is more valuable than the business ever was. A complete product with years of commits, reviews, docs and tests can be a good fit for AI training and R&D even if it never made money. Our guide on how codebase value is measured explains which factors a stopped product can still score well on.
Five questions to answer before a relaunch
Write the answers down. If any of them is blank or vague, treat that as a warning.
- Why did it stop? Name the main reason in one sentence: too few paying customers, a funding gap, a co-founder leaving, a platform change, a competitor.
- What is different now? Point to evidence, not mood: emails from former users, a waitlist, a new distribution channel, a market change you can show someone else.
- What has to be rebuilt? Run the build on a clean machine. List the dependencies that fail, the security updates needed and the store requirements to meet.
- Who does the work, and when? Name the person and the weekly hours. If the answer is “me, when I have time,” the relaunch will compete with everything else in your life.
- What is the stop rule? Pick the date and the target that will tell you to stop. Without one, a relaunch tends to drift for years while the code keeps aging.
Owners who answer all five honestly often find the decision makes itself. Some discover a real opportunity worth a focused attempt. More find that the reasons the product stopped have not gone away, and that the code is worth more to a buyer today than it will be after another year on a shelf.
Can you do both?
Only in one order. Relaunch first, with a deadline, and sell if it does not work out: the code can usually still qualify, as long as the relaunch did not turn into a business that makes money. Sell first and the rights are gone, so relaunching on that codebase is not an option.
If you take the relaunch path, set the test up in writing before you start. An illustration: suppose you give yourself one quarter, a cap on what you will spend, and a clear target such as a set number of former users returning. Write the date, the cap and the target down. At the deadline, either the target is met and you continue, or you stop and ask for an offer on the code while it is still fresh.
Which to choose
- Can you name what has changed since the product stopped? If not, sell.
- Can you give it real time and a spending cap? If not, sell.
- If both are yes, relaunch with a written deadline and target. Miss the target, then sell.
Ask for an offer before you start either way. It costs nothing, creates no obligation, and tells you what the code is worth as your fallback. Knowing the fallback also makes the stop rule easier to keep: when the deadline arrives, you are choosing between two known outcomes rather than between hope and nothing. Owners who skip this step often keep going long after the evidence has said stop.
What to do next
- Write one paragraph on why the product stopped, and one on what is different today.
- Estimate the rework: dependency upgrades, store compliance and hosting.
- Know your fallback before deciding: get a free code valuation from a short description of the product.
Frequently asked questions
Can I relaunch the product after selling the code?
Not on the code you sold. A sale assigns the rights to the buyer, so building on that codebase afterwards is no longer yours to do. Your skills, market knowledge and contacts stay with you, and the agreement spells out the details; have a lawyer read it if unsure. We never use the seller's brand or name and never relaunch the product as theirs, so the old product does not reappear under your name elsewhere.
How do I know if a relaunch is realistic?
Look for evidence that did not exist when the product stopped: former users asking for it back, a competitor leaving the market, a new channel you can reach customers through, or the original blocker (funding, a co-founder, a platform rule) now gone. Then check the cost: dependency updates, store requirements and hosting. If you cannot name the new evidence, a relaunch is mostly hope.
Will my code still qualify for a sale if a relaunch fails?
Usually, if the relaunch never produced revenue and the code is still a complete product your team wrote. We buy code from products that make no money today. If the relaunch does start earning, it is a running business again and a sale of the code is off the table, which is a good problem to have.
Is it cheaper to relaunch an old app than to build a new one?
Sometimes, but less often than owners expect. Old code carries old dependencies, old security issues and old platform targets. Mobile apps in particular may need significant rework to meet current App Store and Google Play rules. Count the rework honestly before assuming the existing code is a head start.
Find out what your old code is worth right now.
Tell us about the product in about a minute. No code needed. We review the details and come back with a cash offer or a plain no.
Get my free code valuation →