3 Questions Before You Kill (or Keep) a Stalled Side Project

You’ve sunk three months into a side project that should be working. The data says it’s not.

You can feel where this is going. Every week, another problem surfaces. You fix it. The project is “almost ready.” Three months in, you’ve spent money on bugs and time on rewrites. Revenue: zero. But you’ve LEARNED something. The question that keeps you up: when does “learning” become the excuse to keep working on a bad idea?

This post is the kill-vs-keep audit I ran on a side project of my own three days ago: $2,770 spent on infrastructure bugs, $0 in profit, 7 failed strategies, 3 months of work. The framework is general; the case is mine. If you run a solo project that isn’t paying off yet, the three questions below decide for you.

TL;DR

The trap is confusing SUBSTRATE value (the discipline, tools, and knowledge a project builds) with STRATEGY value (the revenue, users, or outcome the project produces). They are different assets. Most “almost there” feelings come from a project that’s accumulating substrate but no strategy. Three questions sort the two and tell you whether to kill, keep, or pivot.

The trap: confusing substrate value with strategy value

A side project produces two kinds of value. Substrate value: everything you learn, every tool you build, every discipline you encode. Strategy value: the actual outcome (revenue, users, traction, working product). Both are real. But month-three operators confuse the two and use substrate progress to justify staying past the point strategy is landing.

The pattern: revenue is zero, but you list ten things you’ve learned. You count the learnings as “almost there.” A month later, revenue is still zero; the list is fifteen. Substrate grows. Strategy doesn’t. Each new learning feels like progress, which keeps you in the project, producing more substrate, feeling like more progress.

If you’ve ever caught yourself saying “but I’ve learned so much,” you’re feeling this. The learnings are real. The strategy isn’t landing. Three months of substrate accumulation without strategy progress is signal, not noise. Most rational-sounding framings tell you to push harder. The honest answer: substrate alone does not pay rent.

This is not the same as “you should always kill failing projects.” Substrate can be valuable. It can become a content stream, a credential, a foundation for the next project. But you have to know which kind of value you’re producing, and you have to be honest that substrate-only is not strategy-success.

“Just push harder” usually fails (and these are the failure modes)

The reflex when a project stops working is to allocate more time. Focused weekend, hired help, new tools, public deadline. Some of these work for some operators. None work when the underlying problem is substrate-vs-strategy confusion. Push-harder approaches produce more substrate, rarely more strategy. The gap isn’t effort.

Four push-harder patterns I tried before separating substrate from strategy:

• Allocate a focused weekend. Same brain, same problem space, same blind spots. The weekend produces a draft of the next attempt, not a working strategy.
• Hire a consultant. Consultants at the price a solo operator can afford do parameter tuning on the SAME premises that produced the failed versions. The output: another version that “should work.”
• Switch tools. Tool-churn is procrastination disguised as setup. The strategy-failure logic doesn’t live in the tool.
• Set a public deadline. The deadline creates pressure. Pressure on solo projects often triggers shutdown and avoidance, not motivation. The deadline hits, you miss it, you feel worse, the project bleeds another month.

What works instead is the substrate-vs-strategy audit. The three questions below.

The 3-question audit

Run these three questions before you decide kill, keep, or pivot. Each one separates substrate value from strategy value or names the precondition for continuing.

Question 1: Is your project producing substrate value, strategy value, or both?

Make two lists. List A: every learning, tool, or discipline the project produced. List B: every dollar of revenue, paying user, or shipped product. If List A is long and List B is empty, you have a substrate project pretending to be a strategy project. That’s mis-classification, not failure. Decide which one it actually is, and reset expectations.

Question 2: Can you separate “lost to bugs” from “lost to bad strategy”?

Audit your costs (time AND money). Tag each: lost because infrastructure broke (bug class), or because the strategy failed (strategy class). Different problems, different fix paths. If bug-class dominates, the failure mode is engineering rigor, not edge discovery. You need a tighter pre-deploy gate, not a new strategy.

Question 3: Do you have pre-committed re-entry criteria?

If you decide to pause rather than kill, what specific trigger would re-open the project? “I’ll know when I see it” is not a trigger. Pre-committed re-entry criteria are explicit, written down BEFORE you pause, falsifiable. Without them, sunk cost wins every internal debate at the 12-week mark.

If your project answers Question 1 as “substrate-only,” Question 2 as “mostly bugs,” and Question 3 as “I don’t have re-entry criteria,” you have a “pause and convert to research” decision, not a kill decision. That distinction matters and the rest of this post is about why.

My own case: a crypto trading bot that earned $0 across 7 strategies

I ran this audit on my own crypto trading bot three days ago. Started in February 2026. By May, it had tested seven strategies; every one failed the pre-deploy quality check I had built. The bot cost $2,770 in bug-related losses (infrastructure failures during early live runs) and earned zero dollars in profit.

Three strategies illustrate the three lesson archetypes that came out of the audit. The full kill-list is seven; the three below cover the universal failure modes the others repeated. A reader without a trading project can substitute “strategy” with “feature” or “experiment” and the same lessons hold.

Strategy	What the gate caught	Universal lesson
sharp_move	“Lookahead bias”: the test I was using to validate the strategy depended on data I wouldn’t have had in real-time	Any test you can adjust after seeing the data to make it pass is not a real test. The strategy passed every backtest; it failed the moment the test was specified before the data
cheap_side	“Sample-size” failure: the strategy predicted a 50% success rate; in 16 real attempts it produced 0 successes	When the math says “0 wins in 16 tries at predicted 50% is 1-in-65,000,” your prediction is wrong, not your sample. Trust the math over the narrative
accumulator	“Risk-adjusted return” floor violation: the strategy’s positive return was below my pre-set safety threshold relative to the volatility	Returns alone don’t tell you if a strategy is safe. A 10% return with 50% volatility is worse than a 5% return with 5% volatility. Always check risk-adjusted, not raw

Plus four more strategies in the same three lesson categories (lookahead bias, sample-size insufficiency, risk-adjusted return floor). The pre-deploy quality check correctly caught every one. The bot’s gate worked. The bot’s strategies didn’t.

Translated to Question 1’s substrate-vs-strategy audit: my List A had a calibrated quality-check gate, a bug-discipline ledger, postmortem notes on 7 strategy attempts, and a content stream (this post). My List B was empty. The project was producing substrate value at a high rate and strategy value at zero. Mis-classification confirmed.

# What the pre-deploy quality check output looked like
# for one of the kills (translated to universal terms)

Strategy: accumulator (version 2)
Window: last 30 days
Capital: $100 hypothetical
Checks:
  Pre-test signal degradation:    PASS
  Market-regime stability:        PASS
  Sample size sufficient:         PASS (n=922 trades)
  Risk-adjusted return floor:     FAIL (computed 0.38, floor 0.5)
  Deploy safety:                  n/a (gated by previous check)
VERDICT: NO-GO
Reason: risk-adjusted return below the safety threshold set BEFORE
        running this data.
Action: KILL this strategy or recalibrate from scratch.

That output is the substrate the project produced. The strategy is not.

What stays operational (the substrate keeps running)

The kill-vs-keep decision isn’t binary. A third option most operators miss: pause the strategy work, keep the substrate running as research. The bot still runs in no-capital simulation mode, generating telemetry. The discipline I encoded over three months (pre-deploy gate, bug-discipline lessons, postmortem patterns) stays operational and feeds content.

What changed: live capital deployment, new-strategy authoring, parameter tuning, “let me try X” cycles. Those stop for 90 days. The bot runs; I don’t work on it. Simulation telemetry feeds this post and the next ones. The substrate pays for itself in learning and content; it doesn’t pay rent in revenue.

The pattern if you reach the same verdict: don’t shut down (you lose substrate), don’t keep working (you keep producing substrate and zero strategy). Run it in a no-stakes mode. Whether that’s “no capital” for a trading bot, “no marketing” for a SaaS, or “no recording” for a podcast: separate the substrate’s existence from the operator’s attention.

FAQ: Side-project kill-vs-keep decisions

Five questions I get most often about the audit, paired with self-contained answers. Each answer makes sense without reading the rest of this post. AI engines extract these capsules; human readers skim them as recap; both audiences are served by the same shape. The fifth is the one most operators don’t ask but should.

How do I know my “substrate value” isn’t just sunk-cost rationalization?

Two tests. (a) Can a third party use the substrate without you? If yes (tool, doc, content stream is portable), it’s real. If no (lives in your head as “I learned a lot”), it’s rationalization. (b) Does it produce a measurable outcome (content, credential, next-project foundation)? Yes: real. No: sunk-cost dressed up as value claim.

When is “just push harder” the right answer?

When Question 2’s audit shows the cost is mostly bugs (engineering rigor), not strategy. Bugs have a different fix path than strategy failure: write tests, encode discipline, ship infrastructure improvements. The “harder” effort goes into reliability, not into another strategy attempt. If your audit says strategy is failing too, “harder” usually means “more of the same wrong thing.”

What counts as a real pre-committed re-entry trigger?

Three properties: explicit (written down somewhere specific), falsifiable (you can tell whether it happened), pre-set (committed BEFORE you pause, not designed retroactively). Real trigger: “Re-open when a new strategy passes all 5 pre-deploy criteria with the test specified BEFORE data runs.” Fake trigger: “When I feel like the time is right.”

Does pausing the project mean I’ve failed?

No. A pause with explicit re-entry criteria is project hygiene, not failure. Failure is unconscious continuation: spending more attention on something that won’t pay off because you haven’t decided to stop. The discipline of running the audit, writing the answers, and choosing pause-vs-kill is the asset that survives whatever happens to the specific project.

What do I do with the 80% of attention I free up?

Revenue lanes you’ve been under-investing in. The lanes where the math is clearer: someone is paying, the funnel is visible, unit economics are positive. For me: an AI-visibility consulting offer, a content site that turns substrate into traffic, a freelance pipeline. Whichever lanes have a clearer 90-day path to dollars deserve the freed attention.

What to do next

Three actions, ordered by how fast they surface signal for your own decision. The first runs in 20 minutes and gives you the substrate-vs-strategy audit on YOUR project, no trading required. Each is independent; pick the one that matches where you are.

1. Run the substrate-vs-strategy audit on one project this week. Make List A (substrate produced) and List B (strategy produced). If List A is long and List B is empty, you have the mis-classification. Decide: is this a substrate project pretending to be a strategy project? Reset expectations accordingly.
2. Audit your last 90 days of project costs. Tag each by bug-class vs strategy-class. If bugs dominate, your fix path is engineering rigor (tests, gates, postmortems), not new strategy. Different work, different timeline, often a different skill to develop.
3. Write pre-committed re-entry criteria for any project you’re considering pausing. Three properties: explicit, falsifiable, pre-set. Without them, sunk cost wins every debate at the 12-week mark.

The harder version of this work is doing the audit honestly when the answers point to “this project is substrate-only and I should pause it.” Most operators can run the audit. Fewer can act on the verdict.

---

Drafted from my own side-project audit on 2026-05-12, when a 3-month trading-bot project hit the substrate-vs-strategy decision point. The framework is general; the bot is the case study. If you want the AI-visibility framework I built alongside this, see chudi.dev/framework.