Tiny Revenue Stream

When to kill a side project that is not earning

How to tell a stalled hobby from a failed test, set kill criteria before you get defensive, and free attention for the next offer that might actually pay.

Side projects die of politeness more often than they die of bad ideas. You keep the repo warm, tweak the landing page on Sunday nights, tell friends it is "almost ready," and spend the only resource that does not regenerate: attention. Knowing when to stop is not cynicism. It is how you protect the next offer that might actually earn.

Killing a project is different from pausing it. A pause has a date and a reason. A kill means you stop investing evenings, stop pitching it as your main bet, and stop letting it occupy the mental slot where a real revenue stream could live. You can keep the code. You can even keep the domain. What you cannot keep is the fiction that activity equals progress.

Before you decide, get honest about what "not earning" means. A project that made $200 once and then stalled is in a different place than a project that has never been offered to a stranger with a price attached. Many so-called failed products were never products. They were portfolios with a Stripe button that nobody was asked to click. If you have not made twenty specific asks, you do not have market feedback. You have vibes.

Still, there is a point where more asks are not the answer. Use a short set of hard checks. Has a clear buyer shown up more than once, in their own words, without you explaining the vision for ten minutes first? Can you describe the paid outcome in one sentence that a tired small business owner would understand on a phone screen? Have you delivered a manual version of the result at least once for money, even ugly money? If the answers are no across the board after a real push, the project is teaching you something. Usually it is teaching you that the problem is vague, the buyer is imaginary, or the work only interests you.

Time boxes help because feelings lie. Give an active monetization push a fixed window, something like four focused weeks with a weekly outreach quota and a published offer. During that window, do not rebuild the architecture. Sell the outcome with the tools you already have. At the end, look at cash collected, serious conversations, and whether anyone asked when they could start. Vanity metrics can stay in the analytics account where they belong. Signups with no payment intent are soft. Calendar holds with a price on the table are hard.

I have watched people nurse the same dashboard idea for a year because a handful of Twitter likes felt like traction. I have also watched someone kill a polished side tool after six quiet weeks, turn the same skill into a $1,200 teardown offer for local service businesses, and have a paying customer before the next weekend. The second person did not become smarter. They stopped confusing build progress with buyer progress.

There are warning signs that show up early if you are willing to see them. You keep widening the audience because the original one did not reply. You add features whenever a conversation gets uncomfortable. You change the name more often than you change the offer. You feel relief when coding and dread when sending messages. That last one is especially useful. Relief during building and dread during selling usually means the project is functioning as avoidance with a GitHub badge.

Another warning sign is dependence on a future event that never quite arrives. The launch. The Product Hunt day. The SEO to kick in. The integration partner. The redesign. Tiny revenue streams that work tend to work in small, present-tense loops: ask, sell, deliver, learn. If your plan requires a spotlight before a stranger can pay you, you have built a hope machine.

Cost matters even when the dollar costs look small. A $12 host and a $20 SaaS stack are not the issue. The issue is the opportunity cost of evenings that could go to an offer with a pulse. If you already have a service that people pay for, and the side project keeps stealing the hours that would deepen that service, the side project is not a seed. It is a leak. Bootstrapped operators feel this in the body before they admit it on paper. You sit down to work and feel split. Split attention rarely ships either thing well.

Kill criteria should be written while you still like the project. Write them when you start the monetization push, not when you are tired and defensive. A useful set looks like this: after four weeks and at least thirty personalized outreaches, if there is zero cash and fewer than three conversations where a buyer discussed timeline and price in concrete terms, the project moves to archive. If there is cash but every delivery feels like custom misery you refuse to productize, the project also moves to archive, because a sale that destroys your week is not a foundation. Adjust the numbers to your life. Keep the spirit. Predetermined rules beat mood.

People resist killing projects because of sunk cost, identity, and public commitment. You told a friend. You posted a screenshot. You bought the domain in a burst of optimism. None of that is a customer. The respectful move toward your past self is not eternal loyalty to a dead path. It is using what you learned. The email scripts, the objection list, the parts of the problem that made people's eyes light up for thirty seconds, the skill you got sharper at while building. Harvest those. Then stop pouring new weeks into a vessel that does not hold money.

Archiving well is a skill. Write a one-page postmortem for yourself. What you believed at the start. What you actually tested. What buyers said. What you never tested and are tempted to romanticize. What asset is reusable. Then cancel the nonessential subscriptions, set the status page or README to "archived," and remove the project from your weekly plan. If you leave it in the same mental bucket as active work, you did not kill it. You put it in a soft coma.

Sometimes the right move is a pivot so sharp it is basically a new project with inherited parts. That is fine when the buyer stayed the same and the outcome got clearer. It is not fine when you keep the branding and change the entire premise every month to avoid admitting a miss. A real pivot names what died. "The self-serve tool did not sell. The done-with-you audit did." That sentence is adulthood. "We are evolving the platform" is often fog.

There is also a trap on the other side: killing too early because silence hurt your feelings. Silence in week one of quiet outreach is normal. Silence after a month of consistent, specific asks to people who have the problem is information. Learn the difference. If you only posted once in a Discord, you did not test demand. If you talked to fifteen operators who all said some version of "I would need this if you also did the setup for me," you may be holding a services business and calling it a failed SaaS. Rename it. Price the setup. Ship that.

A healthy portfolio for someone building tiny revenue streams usually has one primary earning motion and, at most, one experiment with a kill date. Two active experiments plus a day job is how months disappear. The earning motion pays for patience. The experiment borrows time against a clock. When the clock runs out, you choose with data. That rhythm feels less dramatic than startup mythology, and it produces more dollars.

If you are staring at a project tonight and feeling the fog, try this sequence in the next seven days before you decide. Publish a painfully narrow paid offer that uses what you already built, even if delivery is manual. Send twenty messages to people who already live with the problem. Track replies like an adult. At the end of the week, read the thread history out loud. If the story is curiosity without commitment, archive with gratitude. If the story is commitment with messy delivery, simplify and continue. If the story is nothing because you avoided the asks, do not kill the project yet. Kill the avoidance, run the week for real, then decide.

Stopping is not failure when the goal was earning. The goal was never an immortal repo. The goal was a small, reliable transfer of value for money, repeated enough times that you can plan around it. Some ideas help you get there by succeeding. Others help you get there by ending soon enough that you still have energy for the next one. Be kind to your future evenings. They are the actual scarce asset.