I have a lot of side projects. The usual advice is to kill most of them.
Focus on the winner. Archive anything that is not growing. Stop spending time on products that will never become companies. Clear the graveyard so nobody mistakes it for a portfolio.
I understand the advice. I just do not accept the premise that every piece of software has to justify itself like a venture.
Useful is a complete outcome
BudJet helps me understand where my money goes. Viddl downloads a video without turning the page into an ad maze. SlovoCard helps me retain the language around me. Earth Roulette turns “where should we go?” into an actual place.
Those are useful outcomes. They remain useful if the addressable market is small, if growth is flat, or if I am one of the main users.
Commercial success is welcome. It is not the only authority allowed to declare software alive.
A small number of users is still people
Analytics makes it easy to turn users into a threshold. Below some number, maintenance looks irrational.
But a person who depends on a small tool does not experience themselves as 0.03 percent of a disappointing monthly active user chart. They experience a thing working or not working.
If somebody reports a broken import, a wrong vocabulary entry, or an upstream change that stopped a download, I usually fix it. Not because every report proves product-market fit. Because I made the product, it is still public, and standing behind it is part of the work.
Maintenance preserves accumulated thought
A mature small product contains decisions that are expensive to recover after neglect.
The category model in a finance tracker, the destination data behind a travel tool, the language variants in a vocabulary deck, the compatibility knowledge inside a downloader — those are compressed thought. Keeping the software healthy preserves that thought in a form people can use.
Deleting the product does not merely remove hosting cost. It throws away the operating knowledge, edge cases, and user corrections that accumulated around it.
Sometimes that is still the right call. Security can make abandoned software irresponsible. Infrastructure can cost more than the value. A dependency can become impossible to support. Stewardship does not mean pretending maintenance is free.
It means making the decision based on the product’s real life, not a startup slogan.
A body of work is not a startup portfolio
A startup portfolio is evaluated by outcomes: exits, revenue, growth, returns.
A body of work tells a different story. It shows recurring interests, better judgment, techniques learned, mistakes repeated less often, and the distance between what somebody could build then and what they can operate now.
Earth Roulette matters partly because it pulled me back into serious hands-on engineering. My first commercial website matters even though Google Panda broke the business. Viddl matters because the deliberately boring interface is the product decision. BudJet matters because daily use forces honesty that a launch demo never will.
Calling all of that a graveyard would be tidier. It would also be false.
Keeping software alive does not mean constant expansion
Some projects are evolving. Some are maintained. Some are long-running systems where the right work is compatibility, dependency updates, support, and the occasional repair. One is formative history.
Those are different relationships. They do not need to masquerade as “active development” to deserve a place.
The discipline is knowing which relationship each product has now. A maintained tool does not need a quarterly roadmap. A primary focus does. A formative project needs an honest record, not a fake relaunch.
This is why I prefer “last tended” to “last commit.” A commit measures repository motion. Tending can be fixing data, answering a user, renewing an integration, checking a deployment, or deciding that the correct change is no change.
The standard is stewardship
I do not promise that every product will grow. I do not promise that every rough edge will disappear quickly. I do promise not to present abandoned experiments as living software.
If I say a product is maintained, I still look after it. If it is imperfect, I should say where. If somebody finds a problem, there should be a way to tell me.
That is a quieter standard than startup success, but it compounds. The result is not a row of trophies. It is a living portfolio: commercial successes, small utilities, hard lessons, and software I continue to stand behind.