You built an app and nobody uses it. Now what?
· Zero to Hundred
You shipped something that works. It solves a real problem. Almost nobody has used it. That is not a sign you built the wrong thing, and it is usually not a sign you built it badly.
You have three options, and most people only ever consider one. You can keep paying attention to it. You can let it sit. Or you can sell it to someone who wants the code. The third option gets skipped almost every time, which is why so many working projects end up as folders nobody opens.
Why does nobody use the thing you built?
Because building got cheap and attention did not.
An average of 2,901 new apps are released on Google Play every day, against a catalogue of 2.5 million. Last month alone added 105,318 (42matters, data current 2026-08-15). Every one of those was somebody's idea they believed in.
This is the thing solo developers keep landing on independently. In a recent r/SideProject thread asking whether we are seeing a solo developer renaissance, seven 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 is 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 simply that they find it difficult to expose them.
So the answer to "why does nobody use it" is rarely about your code. You shipped into a stream of nearly 3,000 apps a day and did not spend the months required to be found. It is common enough to be its own genre: one iOS developer wrote up two years of building apps alone that nobody used and reached the same conclusion about where the time actually goes.
Is this a marketing problem or something else?
It is a budgeting problem, and the currency is months.
Distribution is not a switch you flip once. It 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 cannot.
Which means the real question is not "how do I market this" but "am I going to pay this cost, for this project, for the next six months." Three honest 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 just 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 is for? Not a category. A person, with a job and a problem.
- Would you pitch it to a stranger this week? Not eventually. This week.
Three noes means you have already decided. You are not going to pay attention for this one. That is a legitimate decision and it is not a failure. What is a failure is refusing to say it out loud, so the project stays on the list for another two years, quietly making you feel behind.
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 cannot name the person it is for, ask someone else before you conclude nobody wants it.
What is a project with no users actually 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 honest gap in every valuation guide written for larger deals, and it is 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 does not want to spend a month building it has a real reason to pay. They are not buying your traction. They are buying the code, the decisions inside it, and the weeks you already spent.
That is 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 does not mean surrendering the thing you made. You can keep running your own copy. Sales at or above $100 hold the funds in escrow with a 7-day Dispute Window while the Buyer evaluates in a test environment. Below $100 the code is released instantly. A completed sale carries an 8% platform commission.
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 do not care who typed it. Both are arguing about status, and status is not what gets checked when someone considers paying you.
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. Those are not gatekeeping. They are the things a Buyer opens the repo and looks for, because they determine whether this becomes their software or their problem.
So the question is not who wrote it. It 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 is usually the difference between a project someone can evaluate and one they close.
When should you not sell it?
When it is your main bet. If this is the one, distribution is the job. There is 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 is no reason to force it.
When you cannot hand it over cleanly. API keys tied to your accounts, third-party terms that do not allow transfer, credentials you cannot separate from your own. Sort that out first or do not list it.
When the value lives in accounts, not code. If what makes it worth anything is a customer list or an ad account, you are 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 three questions on each. Be quick and be honest.
- For anything that got three noes, decide now: sell it, or archive it deliberately.
- For anything you are keeping, write down what paying attention looks like for the next 90 days. If you cannot write it, that was a no.
- For anything you are selling, spend one afternoon on the README and setup steps.
- Ask one person what your "basic" project would be worth to them. Their answer will probably surprise you.
The renaissance is real. Building has never been this accessible, and the people saying so are right. What nobody mentions is that the cost of finishing barely moved, and the cost of being found went up. That gap is where working software goes to sit 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 you are on the other side of this and would rather buy something finished than start over, what actually goes wrong when you buy software is worth reading first.
