Thirteen products are alive at LFH Lab. That isn't the number I've built.
The difference is a rule I apply on a schedule, not a feeling I act on when I'm frustrated. Products that don't earn their place get shut down. Not paused, not "on the back burner," not left running in case. Shut down, cleanly, with the users told and the domain released. The rule matters because the alternative is a portfolio that only grows, and a portfolio that only grows is one person's attention divided by an ever-larger number.
The criteria
A product gets reviewed every quarter against three questions.
Does it cost more than it earns? Hosting, domains, the odd API bill, and the hours. If it's been underwater for 6 consecutive months, it's a candidate.
Is it strategically useful anyway? Some products are worth running at a loss. MyUptimeBot would be worth keeping if it never made a dollar, because it watches everything else. A product that generates client conversations, or feeds another product, or is a live demo of something I sell, stays.
Would anyone miss it? Not "does it have users." Does it have users who'd be worse off. A product with forty signups and no one who's logged in since spring has users in the database and none in the world.
Three yeses to "cost more, no strategy, nobody'd miss it" means it goes. Two means it gets another quarter and a note about what would change the answer.
The checklist
Shutting a product down badly is worse than leaving it running. So the process is the same every time.
- Tell users first, with a date at least thirty days out, in the product and by email. Say what's happening and what they should do. Don't apologize for four paragraphs.
- Give them their data. An export, in a format they can open. Even if you're certain nobody wants it, the offer is the point.
- Turn off billing before anything else. No one gets charged for a product that's ending.
- Set the date and keep it. On that day, the app goes read-only or off. Not "soon after."
- Revoke every key. Stripe, Mailgun, the API tokens, the OAuth apps. A dead product with live credentials is a liability with no upside.
- Archive the repo with a README that says what it was, why it ended, and what was learned. Future me reads these.
- Remove it from monitoring last, so the alert on the day it goes dark is expected.
- Decide about the domain. Usually release it. Occasionally redirect it to whatever replaced it. Never leave it pointing at a server that's gone.
What it's bought me
Room. Every product that's been shut down has freed attention that went into one that's working, and the ones that are working are working because they got it. [One sentence on a product you shut down and what came of the time.]
It's also bought a portfolio I can describe honestly. When I say thirteen products, they're thirteen things that work today, not thirteen domains and a pile of regret.
If you're hiring me
Every build should come with a plan for what happens if it doesn't work, and that plan is usually short: how users are told, how data comes out, how the bill stops. I write it into the handoff doc, because the client who never needs it loses nothing, and the one who does gets to end a product without ending a relationship.
The hardest part of a portfolio isn't starting things. It's stopping them on purpose.