# A list of a hundred software ideas, and the seventeen that got built > This repository contains no code. It is a curated list of around a hundred software project ideas written as bounty prompts, plus a record of the projects people have actually built from them, and the completed list is more informative than the ideas because it shows which problems turn into working software and which stay on paper. The pattern in what got finished is unusually consistent. **Divide-By-0/ideas-for-projects-people-would-use** — Every time I have an idea, I write it down. These are a collection of my top software ideas -- problems I think enough people have that don't have solutions. I expect you can reach a decent userbase if marketed correctly, as I am surely not the only one with these problems. - Repository: https://github.com/Divide-By-0/ideas-for-projects-people-would-use - Stars: 2,193 · Forks: 97 - Language: Unknown - License: MIT - Published: 2026-09-30 · Updated: 2026-09-30 · Language: en - Canonical page: https://hysenlabs.com/projects/divide-by-0-ideas-for-projects-people-would-use ## What is actually in this repository The honest first thing to say about this project is that it is not software. There is no build system, no library, no application and no test suite. The top-level contents are a `README.md`, a `LICENSE`, a `CONTRIBUTORS.md`, a `CNAME` file and an `assets` directory, and the primary language is recorded as unknown because there is no primary language. The `CNAME` file is the marker for a GitHub Pages custom domain, so this is a published website that happens to live in a repository. What it contains is a list. The author describes it as a collection of their top software ideas, being problems they think enough people have that do not have solutions, and the entries are framed as bounty prompts rather than as feature descriptions. The framing is deliberate and it is the most useful thing about the format. The stated motivation is personal rather than commercial. The author writes that it is difficult to stay motivated coding on a side project when you do not know whether people will use it, or whether the end goal is solving a problem that is already solved. The list exists to remove that uncertainty, at least the part of it that can be removed by knowing the problem is genuinely open. There is a stated inspiration, another repository of things to code, and a scale figure: the list is around a hundred curated ideas, with a target of a hundred and fifty by the end of 2023, and the author says several hundred more sit on a private list, the majority of which they describe as patently ridiculous and not worth anyone's time. That last detail is worth crediting. A person publishing a hundred ideas and saying they have three hundred more they are hiding is making a claim about curation rather than about volume. The completed section is where the analytical value is, and the author is upfront that the count is seventeen. Seventeen projects built out of a hundred ideas is a completion rate in the region of one in six, which is a more useful number than the list itself for anyone trying to estimate what happens when you pick one. ## What a finished entry has to contain, and one that did not Each completed entry follows a template, and the template is a useful evaluation rubric in itself. A finished entry carries the original bounty prompt, a line naming who completed it, a link to a GitHub repository, and where applicable a link to a deployed site. Look at what that requires. A repository link means someone wrote code and put it somewhere. A deployed site means the code runs somewhere other than a laptop, which for most of these ideas is the difference between a weekend project and a product. Naming the builder means the list doubles as a credit record, which is why there is a `CONTRIBUTORS.md` alongside it. Two of the completed entries also carry implementation detail rather than just a link, and those are the most instructive. The witness-encrypted matching app lists a browser-friendly witness encryption library, a fork of an existing one, and a deployed login site, and the prompt itself specifies the cryptographic construction to implement, the exact matching rule, and the two garbled-circuit primitives that could be used. That is what a well-specified bounty looks like: the builder still does the work, but nobody has to guess what the work is. One entry does not match its prompt, and it is worth naming because it is the kind of thing a curated list is supposed to filter out. The video colorization idea asked for an API endpoint for temporally consistent video colorization, and what is linked is a demo hosted on Replicate, a platform for running hosted models. A hosted model demo is not an API endpoint, and the difference is not pedantic: one is a thing you call, the other is a web page you visit. Whether that satisfies the prompt depends on how you read it, and the entry records the completion without discussing the gap. A second mismatch is softer. The prompt for a near-cost hosted version of colourisation and OCR models is delivered as another Replicate deployment, which is exactly what was asked for, so that one is consistent. The pattern is that a Replicate demo is an acceptable answer to a prompt that says Replicate, and a questionable answer to a prompt that says API endpoint. The list could be stricter about that distinction, and until it is, the completed section is a set of links rather than a set of verified deliverables. ## The pattern in what got built: music, and someone else's API Look across the visible completed entries and count the domains. A Spotify playlist remixer. A site that matches you with friends who have listened to the same artist. A Tinder-style music discovery app released as an iOS app. A second Tinder-style music discovery app released as a web app. Four of the visible completions are music, and the repository's own topic list includes music, playlist, spotify and whattodo. Now count the third-party dependencies. Spotify appears in a playlist remixer and in a listening-history matcher. Apple Music appears in one discovery app and SoundCloud in the other, with the second explicitly inspired by a now-dead predecessor. Replicate appears twice, for the two model-hosting entries. So nearly every completed project is a thin layer over a platform that already holds the data, the catalogue or the model. That is the pattern worth taking from this list, and it is a pattern about feasibility rather than about taste. An idea that consumes someone else's API and presents a new interaction can be scoped to a weekend, because the hard part, the data, already exists and is already licensed for access. An idea that requires you to build the data, train the model, or solve a distributed systems problem cannot be, and the same idea in the list will sit unfinished indefinitely. The counter-examples make the pattern sharper rather than weaker. The witness-encrypted matching app is the most technically demanding entry on the list and it was built, because the prompt specified the construction to use and the builder already knew that field. The Tornado Cash leaf blocklist is also a serious cryptographic engineering task and it was built, by someone with the relevant expertise. What neither of those is is a beginner-accessible idea. So the rule the completed section suggests is not that easy ideas get built. It is that ideas get built when the specification is precise and the builder already has the domain knowledge, or when the remaining work is a thin layer over an existing API. Ideas that are both open-ended and require new expertise are the ones that stay on the list, and there is no entry in the completed section to prove otherwise. ## Two builds of one idea, and a predecessor that died first Two of the completed entries are the same idea built twice, and that repetition is more informative than either entry alone. The first plays the ten most commented seconds of a song and adds it to a playlist if you like it, and it shipped as an iOS app. The second does the same thing with SoundCloud instead of Apple Music and shipped as a web app. Both name their inspiration: a project called Soundsieve, which the entries describe as unfortunately dead, and a service called fab.fm, which apparently uses a different song discovery method. The fact that the same idea produced two independent implementations on two platforms, from two different builders, is the strongest evidence in this repository that the idea is wanted. One person building a Tinder-style music discovery app might be a personal taste. Two people building it, six months apart, is a signal about demand that a hundred-item idea list cannot provide on its own. The dead predecessor is the other half of the story, and it recurs. An idea whose previous attempt has already died is simultaneously more attractive and riskier than one that has never been attempted. More attractive, because the failure mode has already been demonstrated to be survivable, and someone is willing to bet again. Riskier, because whatever killed the first attempt is probably still there, and neither entry says what it was. Soundsieve is described only as dead, with no diagnosis. This is the pattern that makes the completed section worth reading carefully. A list of unsolved problems tells you what someone thinks is missing. A list of completed projects tells you what has been tried, what survived, and what has already failed once. Only the second list updates your priors. ## An MIT licence with conditions the MIT licence does not contain The licence recorded for this repository is the MIT License, with the text in the `LICENSE` file. The README then attaches a set of conditions to it, and the two do not line up. The README invites anyone to use the ideas for a hackathon, a side project or a hacklodge project, and says the author would like to see them built. The only things asked for are three: that the result be open source, that credit be given to the author under one of three names, and that the repository and the site link back to the list, with a shortlink provided. The MIT licence does not require any of those things. MIT permits commercial use, permits modification, permits private use, and requires only that the copyright notice and licence text travel with copies. Nothing in it requires the source to be published, nothing requires attribution beyond the notice, and nothing restricts where a link points. So a company could take an idea from this list, build it as a closed-source commercial product, and be entirely within the licence. That is not a criticism of the author, who is asking rather than claiming, and asking for credit is a reasonable thing to do. But it is worth being precise about what kind of statement it is. The README's conditions are a request in the prose, and the licence file is the grant. If you wanted the conditions to be enforceable, they would have to be in the licence text, which would make it a different licence from the MIT one the repository declares. The author also offers direct help, which is the most valuable thing in the README and the least mentioned. If you are interested in an idea and do not know where to start, the README says you can reach out and the author will give pointers on which frameworks they would use, on the high-level design, and on the best way to learn how to build it. An email address at an MIT domain is given. For a list of ideas whose stated purpose is to get people to build them, that offer is the mechanism, and the licence question is beside the point. ## A target date that has passed, and a list that is not a market The README says the list is around a hundred curated ideas and that the author hopes to hit a hundred and fifty by the end of 2023, with a note to stay tuned. The last push to the repository was on 2026-09-09, and there are no GitHub releases. So the stated goal date has passed and the stated count has not been updated. There are two possible explanations and the repository does not distinguish them: the list stalled, or the prose was written once and never revised. Either way, a reader should treat the count as unverified and judge the list by what is actually in it rather than by the number at the top. What the repository is not is market research, and the author does not claim it is. The framing is one person's unsolved problems, and there is no evidence in the repository about how many people share them. The description field goes further, suggesting that you can reach a decent user base if marketed correctly, which is an assertion rather than a finding. An idea can be a genuine unsolved problem and still be a terrible project, because the person with the problem may be a thousand people who will never find your solution or one person who will pay for it tomorrow. Nothing in a list can distinguish those cases, and the completed section does not either, since it records that a project was built rather than whether anyone used it. That is the honest boundary of this project. It is a well-organised set of prompts, with enough specification in the best entries that a builder does not have to invent the problem, and with a completion record that shows which ones have been tried. If you are choosing between ideas on this list, the completed section and the precision of a prompt are the two things that should decide it. Everything else, including the total count and the claim about marketing, is the author's optimism rather than evidence. One last practical note for anyone who does pick something. The strongest entries specify not just the feature but the constraint, as the witness encryption prompt does when it names the construction, the matching rule, and the two primitives available. An idea that says build a thing is a project. An idea that says build this specific thing under these specific constraints, and here is a repository, a site and a person who will answer questions about it, is a project with a start line drawn on it. ## Conclusion Read this list if you are choosing a side project and want problems that are known to be unsolved rather than problems you assume are, and read the completed section first because it filters the ideas by whether someone could actually finish one. Do not treat it as a market analysis, since the entries are one person's unsolved problems with no validation behind them, and do not assume the list is current, because the stated target of a hundred and fifty entries by the end of 2023 has passed with the README still describing around a hundred. Verify first by checking which entries have a linked repository and a live site, since those are the ones that survived contact with a builder. ## FAQ ### What is in the ideas-for-projects-people-would-use repository? It contains no code. The top level is a README, a LICENSE, a CONTRIBUTORS.md, a CNAME file for a GitHub Pages domain and an assets directory. The content is a curated list of around 100 software project ideas written as bounty prompts, plus a section recording 17 projects that have been built from them. ### How am I meant to use the ideas, and what does the author ask for? The README invites use for hackathons, side projects or hacklodge projects and asks for three things in return: that the result be open source, that credit be given to the author, and that the repository and site link back to the list. The author also offers to give pointers on frameworks, high-level design and how to learn to build a given idea. ### Is the MIT licence on this list enforceable as stated? The repository is licensed under the MIT License, which does not require open source, attribution beyond the notice, or any particular link. The three conditions in the README are a request in the prose rather than terms in the licence text, so a closed-source commercial implementation would be within the licence as written. ### What kinds of projects have actually been built from the list? The visible completed entries include a witness-encrypted mutual matching app, a Spotify playlist remixer, a video colorization demo hosted on Replicate, a Chrome extension that enforces self-predicted time limits on websites, a site matching friends by listening history, a Tornado Cash leaf blocklist, a keybr clone with per-key statistics, and two Tinder-style music discovery apps released as an iOS app and as a web app. ### Is there a pattern in which ideas get completed? The visible completions lean on music and on other companies' platforms, with Spotify, Apple Music, SoundCloud and Replicate appearing repeatedly, and nearly every finished project is a thin layer over an existing API. The other completions are technically demanding but were specified precisely and built by someone with the relevant expertise. ### How current is this list? The README says the list is around 100 curated ideas with a target of 150 by the end of 2023, and that date has passed with the count in the prose unchanged. The last push to the repository was on 2026-09-09 and there are no GitHub releases, so the stated count should be treated as unverified. ## Sources - [Divide-By-0/ideas-for-projects-people-would-use on GitHub](https://github.com/Divide-By-0/ideas-for-projects-people-would-use) - [Issues](https://github.com/Divide-By-0/ideas-for-projects-people-would-use/issues) - [License: MIT](https://github.com/Divide-By-0/ideas-for-projects-people-would-use/blob/main/LICENSE) - [README](https://github.com/Divide-By-0/ideas-for-projects-people-would-use/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/divide-by-0-ideas-for-projects-people-would-use