One-person product exit checklist: sell, shut down, or hand off

Usage outgrows the operator before revenue does

If you run a product alone, the exit decision usually arrives when the hours stop fitting your life. SteamDB is the case that makes it concrete. It began in 2013 as a major PC-gaming tracker for releases, player counts, patches, backend changes, and sale prices. By 2023, traffic was estimated at roughly 140 million monthly pageviews. For about thirteen years, Pavel Djundik ran it as an independent, single-operator service until it joined Nexus Mods on September 2, 2026. Burnout had set in, but he kept working through it. He had tried several years earlier to find a successor, but could not identify a team he trusted. By January 2026, he started seeking a buyer after the workload stopped being viable.

The acquisition price was not disclosed. Nexus Mods said the site needed to generate revenue, but it would not rely on display or programmatic ads. Before the sale, donations covered Steam key purchases. The new owner promised to keep existing features free, not sell user data, avoid login requirements, and not degrade the site to extract value. The acquiring platform had changed hands in June 2025, ending Scott's nearly 24-year tenure as managing owner. Steam's growth in games and players eventually reached a level that could not be sustained.

The sequence is the pattern: a product earns trust, usage grows, and the operator keeps absorbing the difference. The exit question is whether you can set continuity terms before the workload sets them for you.

Run the checklist before burnout sets the terms

A solo developer exit strategy is a continuity plan. The growth plan belongs to the buyer, not to your users. The list below is short because each item is a tripwire. Run it after a rough week, not after a crisis, because the earlier you catch the gap, the cheaper the fix. Several failed items mean you are already past the point where casual maintenance is safe.

• Count the hours you spent on the product recently; if you cannot, you have no margin.
• Name the tasks that would break if you disappeared for a stretch.
• Point to a usage metric where support, incidents, or data quality now require daily attention.
• Name a buyer, partner, or successor who would keep the core promise intact.
• Write the continuity terms you would require in plain language.
• Choose a default if no buyer appears: shut down with notice, or hand off to a community maintainer.
• Say what a revenue requirement would change for users.
• Set a date to revisit this checklist.

Hours and breakage are the early tripwires. Keep going only when the hours fit your life; otherwise choose shutdown or handoff before the workload decides for you. Burnout is usually a lagging indicator; by the time you feel it, the product has already become a job. Continuity is the middle test: a buyer or successor is only useful if they inherit a promise, not just the code. The terms you write down are the difference between a handoff and a surprise.

Revenue and the revisit date keep the decision honest. A revenue requirement is a constraint on the buyer. Put the date in your calendar and treat it as a maintenance task.

Continuity terms are the real price

When a buyer says a product needs to make money, read that as a constraint on how they run the product. It does not automatically mean the product should change for users. Ask what the constraint will touch: pricing, features, data, support, or the way users reach it.

In a small acquisition, the promise is the part users can verify. Vague terms turn the product into a negotiation after the sale. Written terms tell the buyer what they bought and tell users what they keep.

Shutdown is a continuity choice, not a failure. You can stop a product with notice, preserve data where possible, and leave a clear path for users to move. Handoff is similar, but it requires a maintainer who accepts the same terms. Without either option, the product is already running on your remaining margin.