Ship-or-Kill Score: An Eight-Month Side Project Gets Graded

The hardest decision in a solo project is when to stop. Founders ship past the "kill" point because killing feels like admitting failure. They also commit past the "ship" point because they want certainty before going all in. The Ship or Kill Score exists to produce a numeric verdict that defuses both biases. This article runs an 8-month, 640-hour side project through the Ship or Kill Score engine and shows what the 50/100 verdict actually means.

1. The 8-month, 640-hour snapshot

The scenario: solo founder, 8 months into a side project, 12 hours per week of invested time (640 total hours), 22 paying customers, $410 MRR, 480 free users, 1.4% WoW growth, $180 monthly cost, 6 competitors, weak distribution, moderate differentiation. The engine returns:

# ship-or-kill-score (computed live from /engines/ship-or-kill-score.js)
Engine input
  hours_spent           = 640
  hours_per_week        = 12
  paying_customers      = 22
  mrr                   = 410
  free_users            = 480
  wow_growth            = 1.4
  monthly_cost          = 180
  monthly_revenue       = 410
  competitors           = 6
  distribution          = weak
  differentiation       = moderate

Engine output
  composite             = 50
  verdict               = ITERATE
  dimensions[0].name    = Traction
  dimensions[0].score   = 65
  dimensions[0].weight  = 0.35
  dimensions[0].insight = 22 paying customers means you've found something. Time to systematize acquisition.
  dimensions[1].name    = Economics
  dimensions[1].score   = 70
  dimensions[1].weight  = 0.2
  dimensions[1].insight = You're profitable but not by much. Raise prices or cut costs before scaling.
  dimensions[2].name    = Momentum
  dimensions[2].score   = 40
  dimensions[2].weight  = 0.15
  dimensions[2].insight = 1.4% WoW growth is decent. Sustain it for 8 weeks and you'll have real compounding.
  dimensions[3].name    = Efficiency
  dimensions[3].score   = 20
  dimensions[3].weight  = 0.15
  dimensions[3].insight = 12h/week with 640 hours invested. Make sure each hour is moving a metric, not just shipping code.
  dimensions[4].name    = Market
  dimensions[4].score   = 30
  dimensions[4].weight  = 0.15
  dimensions[4].insight = 6 competitors in a market where you're not clearly unique. You need a wedge — a specific use case or audience nobody else owns.
  summary               = Score 50/100. There's something here, but not enough to go all-in. Run 2-3 focused experiments over the next 4 weeks. If the score doesn't move, it's time to kill.
  nextSteps[0]          = Track hours by activity type (building vs. selling vs. marketing). Shift ratio toward revenue-generating work.
  nextSteps[1]          = Define your wedge: the specific use case or audience where you're 10x better than alternatives. Make that your entire positioning.
  nextSteps[2]          = Set a 30-day checkpoint with specific metrics. If the numbers don't improve, make a hard call.

50 is the worst possible verdict. A 30 means "kill cleanly." A 70 means "ship and double down." 50 is "the experiment isn't done yet, and continuing to commit time without a sharp test is a way to spend another 8 months at 50." The engine is right to recommend a 30-day decision window.

2. Score 50/100 — the iterate verdict

The composite is the weighted average of the five dimensions: 65×0.35 + 70×0.20 + 40×0.15 + 20×0.15 + 30×0.15 = 22.75 + 14.0 + 6.0 + 3.0 + 4.5 = 50.25, which rounds to 50. The math tells the strategic story: Traction (the most heavily weighted dimension) is the highest score, while Efficiency, Momentum, and Market are dragging the composite down.

The "iterate" verdict acknowledges that traction proves something but the other dimensions kill the case for full commitment. CB Insights' analysis of startup failure mode places "no market need" and "ran out of cash" as the top two reasons^[1]. Neither applies cleanly here — there is market need (22 paying customers prove it), and the project is bootstrapped and cash-positive ($410 MRR vs $180 cost). The failure modes that apply: too slow growth, too much time, no clear wedge.

3. Traction 65: 22 paying customers

22 paying customers is the single piece of unambiguously positive evidence. People are paying real money for the product. It is not 220 customers, not 2,200, but it is not zero. The Indie Hackers products database shows the long tail of solo SaaS clustering at $300-$2,000 MRR^[2]; this product sits at the low end of that band.

The engine scores Traction at 65, which is "you've found something." The insight line — "22 paying customers means you've found something. Time to systematize acquisition" — points at the next move: stop building features, start finding customers. Most solo projects at this score-band have a product good enough to sell and a founder uncomfortable with sales. The 30-day experiments should be acquisition experiments, not feature experiments.

4. Economics 70: profitable but thin

$410 MRR against $180 monthly cost is technically profitable. Net is $230/month, or $2,760/year. Below the founder's loaded hourly cost on the time invested (640 hours × $80/hour = $51,200 of accumulated opportunity cost), but as a standalone cash-flow business, it pays for itself.

The engine scores Economics at 70 with insight "You're profitable but not by much. Raise prices or cut costs before scaling." That is the right read. At $18.6 ARPU ($410 / 22 customers), the product is at or below the bottom of the micro-SaaS pricing band — meaning the founder is leaving money on the table. A test price increase to $24 or $29 on new sign-ups would clarify whether the willingness-to-pay supports the broader business case.

5. Momentum 40: the 3% WoW threshold

1.4% week-over-week growth is the data point that drags the score below 60. Annualised, 1.4% WoW compounds to roughly 110% annual growth — not catastrophic but not breakout. Bessemer's 2024 cloud benchmarks place efficient-growth SaaS at 100-200% annual growth in early stages^[4]; ChartMogul places the median early-stage SaaS at 5-10% monthly (roughly 1.2-2.5% weekly)^[3]. 1.4% is at the bottom of the "alive" band.

The 3% WoW threshold the engine implies as healthy compounds to roughly 365% annual growth. At 1.4%, the product would take 18 months to triple, and 18 months is longer than most solo founders have patience for at this score band. The strategic question is whether 1.4% is the true ceiling (in which case kill) or whether 1.4% is what 8 months of zero-distribution work produced and a focused 90-day distribution push could lift it to 3%+ (in which case iterate).

6. Efficiency 20: 640 hours on 12h/week

The lowest-scoring dimension. Efficiency 20 reflects 640 hours invested for $410 MRR — roughly $0.64 of MRR per hour invested. At 12 hours per week of continued investment, the next month of work needs to produce $200+ of net new MRR (12 × 4 = 48 hours × ~$4-5/hour of expected new MRR per hour) to keep the efficiency score from declining further.

The engine's insight: "Make sure each hour is moving a metric, not just shipping code." That is the most important line in the entire report. Most solo founders default to building because building feels like progress; distribution and sales feel like rejection. The 30-day experiment plan should pre-allocate hours into "code" and "sell" buckets, with a hard 50/50 split for the first two weeks of the experiment window.

7. The 30-day kill checkpoint

The engine's next steps are blunt and correct:

• Track hours by activity type. Distribute the next 48 hours of investment between building, selling, and marketing. If the 30-day check shows more than 60% on building and less than 25% on direct customer acquisition, the founder has not actually changed behaviour and the verdict at day 30 is kill.
• Define a wedge. 6 competitors in a category where differentiation is "moderate" means the product is competing on neither price nor distinct positioning. Pick a single sub-segment (smaller, more specific than the current target) and rewrite the landing page, pricing, and outbound for that segment only. If the conversion rate inside the new segment doubles, the wedge is real; if it doesn't, the wedge does not exist.
• Set day-30 metrics in advance. Concrete numbers: net new paying customers, new MRR, WoW growth rate in the final week. The day-30 decision is "if the score hasn't moved from 50 to 60+, kill." Pre-committing the threshold removes the emotional question on day 30.

The honest framing for solo founders: 50/100 at month 8 is not a tragedy. It is a signal that the next 30 days have to look very different from the previous 240. The same energy that built the product needs to flip into selling it. If it cannot, the project is not the right one for this founder at this time.

A few patterns worth pre-empting before day 30 arrives. The "one more feature" trap: a founder convinced that the next feature will fix conversion is rarely right. Conversion problems are almost never feature problems; they are positioning, audience-targeting, or price problems. If the day-30 plan includes shipping a new feature as a primary acquisition lever, the plan is probably wrong. The acceptable use of features in the 30-day window is fixing existing-customer churn or removing onboarding friction — both of which compound traction without spending acquisition cycles.

The "wait and see" trap: solo founders sometimes treat 30 days as a passive observation period rather than a sharp experimental window. The right framing is the inverse: every day of the 30 should have a concrete outcome (X outbound emails sent, Y landing-page variations tested, Z customer interviews booked). Days that pass without measurable activity are signal that the founder has already mentally killed the project but is delaying the explicit decision. Day 14 is the right time for a midpoint review; if behaviour has not changed, calling the kill on day 14 is more honest than waiting through day 30.

One additional pattern. Killing cleanly is its own skill. Founders who treat the kill as "I failed" suffer. Founders who treat the kill as "I learned the price of a problem I now understand much better" extract genuine value from the 640 hours. The same founder shipping the next project at month 9 has a 2-3x better starting point than they had at month 0, because they have learned distribution lessons that no MVP teaches. Use the scope-creep calculator to formalise the lesson-extraction, and the unit-economics engine to set the next project's baseline targets. See the methodology for the full derivation^[5].