What to sell on Zero to Hundred
You have software sitting in a folder. The starter you have rebuilt three times. The admin panel you wrote for yourself. Half a business you shipped, ran for a while, and stopped charging for.
None of it is a business on its own. That is exactly why it is still sitting there.
It does not have to be a business to be worth selling. Licensing here is non-exclusive, so the same software can sell to more than one Buyer and you keep the copyright. That changes the question. It is no longer "is this a company?" It is "can someone else run this?"
The short version:
- Software does not have to be finished to sell. It has to be runnable by someone who is not you.
- The strongest categories are the boring ones: starters, internal software, and the per-seat subscriptions companies would rather own outright.
- Because the licence is non-exclusive, one build can sell more than once. That maths is different from shipping a business.
- Building specifically to sell is a reasonable way to work. It does not have to be the thing you love.
What kinds of software actually sell?
Starters other Builders launch from
The scaffolding you rebuild every time you start something. Auth, billing, roles and permissions, an admin panel, transactional email, the deploy pipeline. You have written it more than once, which means everyone else has too.
A starter sells because the Buyer knows exactly what they are skipping: the first 100 hours, the part nobody enjoys and everybody pays for. It is the easiest category to describe honestly, because "here is the boilerplate, wired up and deployed" is a complete claim. You are not promising a business. You are selling the floor someone else builds on.
Be specific about the stack. "Next.js starter" is a category. "Next.js 16, Postgres, Stripe subscriptions with proration handled, and a working invite-and-roles flow" is a listing.
Software that replaces a per-seat subscription
This is the largest gap and the least crowded.
Every company pays per seat, every month, for software it half uses. Screen recording. Team chat. Form builders. Scheduling links. Status pages. Time tracking. Help desks. Feature flags. Internal wikis.
Run the arithmetic from the Buyer's side. A 40-person company paying $12 a seat a month for a form builder spends about $5,760 a year, and $28,800 over five, on software a competent Builder could write in a fortnight. They are not paying for the software. They are paying for not having to build or host it.
For a large number of those companies the per-seat maths stopped working a while ago, and the reason they have not moved is that "build it ourselves" means hiring. Buying the source outright is the third option: pay once, host it, change the two things that never fit their process anyway.
That last part matters. Off-the-shelf subscriptions are built for the median customer. A Buyer who owns the source can add the one field their compliance team needs, or drop the four features they never touch. Nobody is going to buy your version because it does more. They will buy it because they can make it theirs.
Narrow software for one industry
Dental practices. Trucking dispatch. Veterinary clinics. Rental yards. Church admin. Anything where the incumbent is a decade old, priced per seat, and hated.
Narrow software is a hard business to run because the market is small and the sales cycle is long. It is a good sale, for the same reason. The Buyer is often someone inside that industry who already has the relationships and cannot write the software. You have the opposite problem. Selling the source is the trade.
Internal software you already run
The dashboard you built to watch your own metrics. The script that reconciles two systems nobody else connects. The onboarding flow you wrote because the off-the-shelf one did not fit.
Internal software has an advantage no side project has: it is in daily use, by real people, against real data. It already survived contact. It usually needs an install guide and the removal of a few hard-coded values before anyone else can run it, and that is a day of work, not a rewrite.
Software you build specifically to sell
Building for sale is a different brief from building a company, and it is a reasonable way to work.
You are not looking for a market you can own for five years. You are looking for a well-understood problem, a clear scope, and a stopping point. You ship it, you sell it more than once because the licence is non-exclusive, and you move on. No support burden you did not sign up for, no roadmap, no churn.
It will not be the thing you are most proud of. That is fine. Not every build has to be the one you love.
What makes any of it sell?
The category matters less than four things, and they are the same four every time.
A demo the Buyer can actually run. A working demo or a walkthrough video is required on every listing before it goes live, and it is the single strongest thing in your listing. Screenshots prove a design. A demo proves it runs.
An honest scope. Say what works and what does not. A limitation you disclose is not a problem; it is information the Buyer priced in. A limitation they find after buying is a dispute. The listing that says "payments and auth are done, the reporting is basic, there are no tests" outsells the one that says "production-ready" and means it loosely.
A README someone else can follow. Install steps, environment variables, and how to run it locally. This is the most common reason good software does not sell, and it is an afternoon of work.
A price that reflects the hours skipped, not the hours spent. The Buyer is not paying for your weekends. They are paying to not spend theirs.
Start with what already exists
The first listing is almost never something you build for the purpose. It is the software already on your drive that you stopped thinking of as worth anything, because it was not a company.
Listing is free, and the licence is non-exclusive, so listing it costs you nothing and does not stop you using it, selling it again, or building on it later.
Go and look in the folder.
