Built an app nobody uses? Keep or sell it
If nobody uses the app you built, check whether the right people have seen it and whether it solves their problem. Ask one person with that problem to try it. Then choose whether to keep finding users, set the app aside deliberately, or sell a license to the code. A working app can still be useful to a Buyer even when it has no users today.
Why does nobody use the thing you built?
There's no single answer. If someone needs it but hasn't seen it, discovery is the problem. If people try it and leave, check what the software does before you spend months promoting it. Low usage alone can't tell you which problem you have.
Attention is scarce. The number of new apps makes it harder for each one to be found.
As of September 26, 2026, 42matters reported 2,089 new Google Play apps per day on average, with 2,585,496 apps available. Those counts measure mobile app supply, not whether any one app meets a need.
This is the thing solo developers keep landing on independently. In a recent r/SideProject thread asking whether we're seeing a solo developer renaissance, 7 separate people arrived at the same answer without coordinating. The tools got extraordinary. Discovery got worse. One commenter put it as building getting "close to free while attention stayed expensive." Another said the hard part is no longer the building, it's that a good idea gets buried because the developer has no press contacts, no audience, and no patience for posting everywhere for months. A third, building apps alone, said they find it difficult to expose them.
One possible answer to "why does nobody use it" is that the right people have not found it. You shipped into a stream of about 2,000 mobile apps a day. It's common enough to be its own genre: one iOS developer wrote up 2 years of building apps alone that nobody used and reached the same conclusion about where the time goes.
Is this a marketing problem or something else?
It's a budgeting problem, and the currency is months.
Distribution is a recurring cost you pay per project: posting, pitching, answering support, writing updates, being visible for long enough that someone notices. One project can absorb every hour you have. Five can't.
So ask one question. Will you pay this cost, for this project, for the next 6 months? Three answers:
| What you do | What it costs | When it is the right call |
|---|---|---|
| Keep paying attention | Months of posting, pitching, support, updates | You still care, and this is your main bet |
| Let it sit | Nothing today. The code goes stale, dependencies rot, the store delists it | Almost never, though it is what usually happens by default |
| Sell it | One listing and a clean handover | It works, you are finished with it, someone else wants it |
Most people pick the middle row without deciding to. They stop opening the folder.
How do you decide which projects to keep?
Three questions. Answer them about a specific project, not in general.
- Would you ship an update to it this month if nobody asked you to?
- Can you name the person it's for? Name one person, with a job and a problem.
- Would you pitch it to a stranger this week?
Three noes mean you've already decided. You aren't going to pay attention for this one. That's a legitimate decision. The mistake isn't saying it, so the project stays on your list for another 2 years.
One caution on question 2. Builders are consistently the worst judges of what they made. A commenter in that thread described shipping a small Mac utility that renames files based on EXIF data and folder rules. They thought it was basic. They still get emails from strangers saying it saves them 2 hours a week. If you can't name the person it's for, ask someone else before you conclude nobody wants it.
What is a project with no users worth?
Nobody can tell you a number, and anyone who quotes you a multiple is guessing.
Valuation methods for software run on revenue. Multiples of annual profit, multiples of recurring revenue, comparisons to similar sales. At 0 MRR none of those inputs exist. This is the gap in every valuation guide written for larger deals, and it's the exact situation most finished side projects are in.
What working software does have, independent of its users, is the cost of not writing it. Someone who wants what you built and doesn't want to spend a month building it has a real reason to pay. Usually that's a team whose engineers keep rebuilding the same internal software, or a founder who wants a starting point instead of an empty repository. Those are the people on the other side of this trade. They are buying the code, the decisions inside it, and the weeks you already spent.
That's the transaction a license makes clean. On Zero to Hundred a listing grants the Buyer the right to use, modify, and deploy the software. Copyright stays with the Builder, so selling doesn't mean surrendering the thing you made. You can keep running your own copy. Every sale is final, and the source is delivered the moment the Buyer pays. They have 24 hours to report a factual problem, and your payout is held for 72 hours so a report is reviewed before any money moves. A completed sale carries a commission on your side: 25% on a marketplace sale, or 8% plus $0.50 on a sale you brought yourself from a link you shared.
Does it count if AI wrote most of it?
To a Buyer, no. To the code, sometimes.
That thread contained the usual fight about it. One commenter argued that very few real solo developers are left and the rest are "vibe coding wannabees." Another pushed back that their customers don't care who typed it. Both are arguing about status. A Buyer checks the code.
The useful version of that objection came from a third commenter, who listed what tends to be missing: passwords and encryption handled properly, architecture, coding style, code review, documentation that a human can follow. A Buyer opens the repo and looks for exactly those, because they decide whether the software works for them.
So the question is whether it survives a stranger opening it. If you want it to sell, spend an afternoon on the README and the setup steps. That's usually the difference between a project someone can evaluate and one they close.
When should you not sell it?
When it's your main bet. If this is the one, distribution is the job. There's no version where you skip it.
When you built it for yourself. One commenter described writing small apps that fit exactly how they work and deciding they no longer care whether anyone else can use them. That is a good outcome. Software shaped around one person rarely transfers well, and there's no reason to force it.
When you can't hand it over cleanly. API keys tied to your accounts, third-party terms that don't allow transfer, credentials you can't separate from your own. Sort that out first or don't list it.
When the value is in accounts, such as a customer list or an ad account. Then you're having a different conversation than this one.
What to do this week
- List every finished project you have. All of them, including the embarrassing ones.
- Run the 3 questions on each. Be quick and be honest.
- For anything that got 3 noes, decide now: sell it, or archive it deliberately.
- For anything you're keeping, write down what paying attention looks like for the next 90 days. If you can't write it, that was a no.
- For anything you're selling, spend one afternoon on the README and setup steps.
- Ask one person what your "basic" project would be worth to them.
Building got easier. Finishing didn't, and being found got harder. That's why working software sits unused.
You can see what other Builders have listed, or read how listing from anywhere works if you already know which project you are done with. If selling is where you've landed, what selling the software you built pays is the next read. If you're on the other side of this and would rather buy something finished than start over, what goes wrong when you buy software is worth reading first.
