The first three months feel like winning. Month four is when most indie SaaS dies. Per the broad indie-hacker public record: roughly 70% of audience-funded creator SaaS launches die between month 3 and month 6, with month 4 the modal collapse point. The cause is not product-market fit - that fails earlier. The cause is the maintenance reality every operator under-models on day one: 5-12 hr/week per product, every week, forever. Customer support. Bug fixes. Edge cases. Stripe disputes. Feature requests. Onboarding. By month 4 the operator's total weekly load (current SaaS + newsletter + community + next product idea + life) exceeds sustainable capacity. They either burn out, sunset the product, or revert to single-product focus. This lesson installs the eight maintenance categories, the month-by-month collapse mechanics, the seven survival patterns of the 30% that makes it past month 6, the product-retirement decision protocol, and the cross-product shared infrastructure that lets operators sustain a Pieter Levels-style 5-8 product portfolio without drowning.

What Actually Counts as Maintenance (And Why Operators Underestimate)

Operators model product as: "build it, ship it, collect MRR." Reality is much broader. Maintenance includes:

(1) Customer support: 1-5 tickets per 100 customers per week. At 500 customers: 5-25 tickets/week × 5-10 min each = 25-250 min/week. Average 1-3 hr/week.

(2) Bug fixes + edge cases: 2-5 bugs per 1,000 user-actions. Operator fixes 1-3 hr/week ongoing.

(3) Infrastructure monitoring: Lovable + Supabase + Stripe status checks; investigate intermittent issues; performance tuning. 0.5-2 hr/week.

(4) Feature requests: Customer requests "could you add X?" Operator triages, batches into roadmap, ships 1-2 per month. 1-2 hr/week.

(5) Content marketing per product: Newsletter cross-mentions, occasional dedicated content, SEO blog posts, social proof updates. 1-2 hr/week per product.

(6) Payment + refund + dispute handling: Stripe chargebacks, refund decisions, subscription disputes. 0.5-1.5 hr/week.

(7) Customer onboarding: New customers need onboarding even if automated; some require operator touch. 0.5-1.5 hr/week.

(8) Quarterly business reviews: Pricing review, churn analysis, feature prioritization, competitive monitoring. 8-15 hr/quarter = 0.6-1.2 hr/week amortized.

Total per-product maintenance: 5-12 hr/week at 100-500 customer scale. Operator underestimates by typically assuming 2-3 hr/week. Reality 2-5x.

The Month-4 Collapse Point: Mechanics

Why month 4 specifically? Compounding factors:

Month 1: Honeymoon. Product just shipped. Operator energized. 30-50 founding customers. Maintenance 2-4 hr/week (lower because customer base small).

Month 2: Growth. Customer count climbs to 75-150. Maintenance 4-7 hr/week. Operator still energized; product feels viable.

Month 3: Stabilization. Customer count 100-250. Maintenance climbs to 5-9 hr/week. First fatigue signals: bug list growing, feature requests accumulating, support inbox creeping.

Month 4: Inflection. Customer count 150-350. Maintenance reality at 6-12 hr/week. Operator notices: (a) other products / newsletter / community attention dropping; (b) operator hours/week climbing 55-70 vs. sustainable 35-50; (c) excitement of launch faded; (d) new product ideas pulling attention. Some products die here from operator focus loss + slow degradation.

Month 5: Crisis. If month 4 didn't trigger pivot: month 5 shows degradation in churn (rising 2-4%), engagement drop (active users -10-20%), support response time (increasing). Operator faces decision: invest more time + recover, accept decline, or sunset.

Month 6: Resolution. Either operator installed ghost team support + restored balance, OR product is dying or already dead.

The 70% mortality at month 4-6 is the structural friction between launch enthusiasm and ongoing operational reality. Operators with mature ghost team (Lesson 5.1.1) + leverage curve discipline (Lesson 5.1.2) survive at 80-90% rate; operators without infrastructure die at 70-80% rate.

The 30% That Survives Past Month 6: What They Do Differently

Pattern 1: Ghost team installed before product launch. Operators with Custom GPT Support handling 60-80% of inbox (Lesson 3.5.1) at launch absorb support load without operator-time explosion. Operators launching without ghost team handle 100% of support manually.

Pattern 2: Pre-defined maintenance ceiling. Operator pre-commits "8 hr/week maximum per product." Anything beyond either gets automated/delegated or product gets repositioned. Operators without ceiling let maintenance creep to 15-25 hr/week before noticing.

Pattern 3: Customer self-service architecture from launch. Stripe Customer Portal (cancel/update billing); searchable FAQ KB (Lesson 3.5.3); automated onboarding sequences (Lesson 3.5.2). Each adds 1-2 hr Sunday afternoon during build but saves 4-8 hr/week ongoing.

Pattern 4: Quarterly product audit + retirement readiness. Every 90 days operator audits: is this product still earning vs. its maintenance cost? Products consuming 8+ hr/week at <$3K MRR get retirement consideration. Operators willing to retire 1-2 weak products preserve capacity for stronger products.

Pattern 5: Bug + feature batching discipline. Bugs + feature requests not addressed real-time. Operator batches into weekly 2-hour maintenance window + monthly 4-6 hour feature shipping window. Prevents constant context-switching that doubles operator time investment.

Pattern 6: Founding customer relationship maintenance. First 25-50 customers receive ongoing personal touch (monthly check-in, beta access, roadmap influence). These customers become long-term ambassadors, lower churn, higher LTV. Costs 1-2 hr/month; produces 30-50% LTV uplift on this segment.

Pattern 7: Product portfolio composition for sustainability. Operators don't run 8 products simultaneously without maturity. Year 1: 1 product. Year 2: 2 products. Year 3: 3 products. Year 4-5: 4-6 products. Each addition only after prior products at sustainable maintenance.

Maintenance Cost by Customer Scale

Per-product maintenance scales non-linearly:

50-100 customers: 3-5 hr/week. Mostly support + occasional bugs. Manageable solo.

100-300 customers: 5-8 hr/week. Support volume climbing; feature requests accumulating; bug rate increasing. Manageable with ghost team Support automation.

300-500 customers: 6-10 hr/week. Onboarding load; quarterly business reviews; pricing adjustments. Requires mature ghost team.

500-1,000 customers: 8-12 hr/week. Multiple feature streams; refund/dispute volume; competitive monitoring. Operator's portfolio cannot scale beyond 4-5 products at this customer scale per product.

1,000-5,000 customers: 10-15 hr/week. Approaching ceiling. Operator should consider partial automation upgrades (Custom GPT Support advanced training, customer success automation tools) or strategic hires (fractional support, $1-2K/month part-time).

5,000+ customers: 12-20 hr/week. Single product at this scale dominates operator portfolio. Operator may have only 1-2 products at this scale.

Strategies to Survive Month 4

Strategy 1: Install ghost team BEFORE first product launch. Custom GPT Support trained on FAQs + product docs + refund protocols handles 60-80% of inbox automatically. Operator review 15-20 min/day. Pre-empts month 4 support overwhelm.

Strategy 2: Build customer self-service from Day 0. Stripe Customer Portal + searchable KB + onboarding automation. Investment: 2-4 hours during Sunday build (Lesson 5.2.2). Ongoing savings: 4-8 hr/week.

Strategy 3: Set strict maintenance ceiling per product. 8 hr/week per product maximum. Track weekly. Anything beyond triggers automation or pricing adjustment.

Strategy 4: Schedule maintenance windows. Operator's calendar has dedicated maintenance blocks (e.g., Monday 9-11 AM Support review; Friday 2-5 PM bugs + features). Outside windows: no maintenance work. Prevents context-switching tax.

Strategy 5: Customer support escalation tree. Tier 1 (Custom GPT) handles 60-80%. Tier 2 (operator review) handles 15-30%. Tier 3 (operator personal) handles 5-10% (refunds, disputes, high-stakes). Most queries never reach operator.

Strategy 6: Quarterly retirement review. Every 90 days audit each product: MRR / maintenance hr ratio. Products below threshold ($300/maintenance hour) considered for retirement, repositioning, or acquisition-out.

Strategy 7: Founding customer ambassador investment. First 25-50 customers get monthly check-in + beta access + roadmap influence. Costs 1-2 hr/month; produces 30-50% LTV uplift + 70-85% referral rate on this segment.

The Pieter Levels Pattern Survival Math at 5-8 Products

Pieter Levels pattern (Lesson 5.1.3) requires 5-8 products at 4-8 hr/week maintenance each = 20-64 hr/week ongoing maintenance alone. Plus content engine 12-18 hr/week. Plus strategic 4-8 hr/week. Total 36-90 hr/week.

How operators sustain this:

(1) Mature ghost team Support handles 70-90% of inbox across products combined. Without: drowning.

(2) Strict maintenance ceiling enforced. Operators tracking weekly. Products exceeding ceiling get repositioned or retired.

(3) Cross-product Ops automation. Shared analytics, shared support routing, shared content distribution. Operator builds shared infrastructure once; reuses across portfolio.

(4) Founding-customer relationship maintenance across all products simultaneously. Operator scales relationship investment via batched outreach (e.g., monthly cross-product founder note).

(5) Quarterly portfolio review. Operator retires 1-2 weakest products annually to preserve capacity for 1-2 new launches. Net portfolio size stays 5-8.

Operators who attempt Pieter Levels without these patterns hit maintenance ceiling at 3-5 products and either burn out or revert to single-product focus. The 30% survival rate at month 4-6 per individual product translates to ~10-20% Pieter Levels portfolio success rate without infrastructure discipline.

The Product Retirement Decision Protocol

Operators emotionally resist retiring products they built. This emotional resistance kills more portfolios than failed launches. The 2026 retirement protocol provides objective criteria that bypass emotional reasoning:

Trigger 1: MRR-to-maintenance-hour ratio below $300/hr. Product generates $1,500 MRR but consumes 6 hr/week = $250/hr. Below threshold. Either reposition (price up to $29 from $19 = ratio improves to $400/hr) or retire. Operators who let products run below $300/hr accumulate maintenance debt that starves higher-leverage products.

Trigger 2: Customer base declining 3+ consecutive months. 3 months of net negative customer movement (new signups < churn) signals product-market fit erosion. Either invest in product revival (2-4 weeks operator-time test) or initiate sunset (Trigger 4 protocol).

Trigger 3: Operator-time creep above maintenance ceiling for 2+ quarters. Pre-committed ceiling 8 hr/week per product. Actual creeping to 12-18 hr/week. Either install additional ghost-team Support capacity or retire. Sustained ceiling violation signals product can't be sustained at portfolio scale.

Trigger 4: Sunset protocol (90-day wind-down). Day 1-30: stop new acquisitions; email customers with 90-day timeline + alternative tool recommendations + offer to export their data; refund unused subscription portions. Day 31-60: maintain support; help customers migrate; document any IP for potential resurrection. Day 61-90: final support window; shutdown infrastructure; archive code repository. Day 91+: domain redirects to operator's main site.

Trigger 5: Acquisition path (alternative to sunset). Product generating $500-$5K MRR but consuming operator capacity may be acquirable by another operator or aggregator (Lesson 5.4.2). Acquisition often $5K-$50K depending on MRR + customer concentration + tech stack. Time to acquisition: 30-90 days via founder networks or marketplaces (MicroAcquire, Acquire.com). Operator recovers capacity + capital.

Retirement decision discipline: Quarterly portfolio audit explicitly considers each product against Triggers 1-3. Operators committed to making 1-2 retirement decisions annually protect portfolio integrity. Operators who never retire products accumulate 8-12 products in 4-5 years with 30-50% generating most revenue and 50-70% consuming disproportionate maintenance. Net result: operator at $200K MRR could be operator at $400K MRR with disciplined retirement.

Cross-Product Shared Infrastructure

The maintenance math at 5-8 products improves 30-50% when operator builds shared infrastructure rather than per-product implementations. The 2026 shared-infrastructure layer:

Shared customer database. Single Supabase project (or multi-project with shared user table) tracking customers across all operator products. Enables: cross-product user identification, unified subscription view, cross-sell triggers, consolidated customer support context. Setup: 8-15 hr one-time. Saves: 1-2 hr/week per product after 3+ products.

Shared support routing. Single support inbox routing to product-specific Custom GPT Support based on product mentioned + customer subscription. Operator reviews one inbox not 5-8 separate inboxes. Setup: 4-8 hr one-time via Help Scout or Front automation. Saves: 30-60 min/day across portfolio.

Shared analytics + metrics. Single PostHog or Mixpanel workspace tracking events across all products. Weekly metrics pull populates single dashboard. Setup: 4-8 hr one-time per product. Saves: 1-3 hr/week metric aggregation.

Shared payment + billing. Single Stripe account with products configured as separate Stripe Products. Unified Customer object across products. Tax handling (Stripe Tax) handled once. Setup: minimal additional vs. per-product Stripe accounts. Saves: 30-60 min/month per product accounting.

Shared transactional email. Single Resend or Postmark account sending across all products. Brand-consistent templates. Setup: 2-4 hr per product. Saves: 30 min/product per template change.

Shared brand-memory + voice. All product marketing copy uses operator's voice corpus (Lesson 2.1.1). All product positioning aligns with operator brand standard (Lesson 3.7.1). Setup: voice corpus + brand standard built once. Saves: 1-2 hr/product per launch.

Operators with shared infrastructure across 5-8 products spend 25-40 hr/week total portfolio maintenance vs. 35-65 hr/week for operators with per-product implementations. The infrastructure investment (40-80 hr one-time + 6-12 hr/quarter maintenance) pays back within first quarter of operating 4+ products.

Customer Success vs. Support: The Distinction That Cuts Churn

Operators model "support" as reactive ticket-handling. They miss the proactive customer-success layer that distinguishes products with 3-5% monthly churn from products with 10-15% monthly churn. The 2026 customer-success discipline at audience-funded micro-SaaS scale:

Activation tracking. Each new customer monitored for first-week activation (did they complete primary user flow? did they use product 3+ times?). Customers who don't activate by Day 7 receive personal operator outreach: 2-sentence DM asking what blocked them. 40-60% reply; 30-50% activate after the outreach. Without: those customers churn within 30 days.

Usage-decline early warning. Customer who used product 8+ times/month for 3 months drops to 0-2 uses/month signals impending churn. Automated alert triggers operator outreach: "Noticed you haven't been using [tool] lately. Anything broken or am I missing a use case for you?" Recovers 30-50% of would-be-churners.

Quarterly customer-success NPS. Lightweight NPS or 1-question survey every 90 days to active customers. Identifies promoters (refer + testimonials), passives (at-risk), detractors (immediate outreach). 5-10 min/quarter per product across full base.

Onboarding cadence. Beyond Day 1 welcome: Day 3 "did this work for you?" check-in; Day 7 use-case suggestion; Day 14 "what would make this 10x more valuable?" feedback request. Automated sequence builds activation + feedback loop. 4-6 hr one-time setup per product.

Founding-customer ambassador program. First 25-50 customers get quarterly personal check-in + roadmap influence + beta access. These customers refer 3-5 peers each at 60-85% close rate. Lifetime value 2-3x baseline customer.

Products running customer-success discipline alongside support: 3-5% monthly churn = 30-50% annual gross retention. Products running support-only: 10-15% monthly churn = 70-90% annual gross retention. At $20K MRR product, the difference between 5% and 12% monthly churn = $5K-$8K MRR uplift annually = $60K-$96K annual revenue protected by 4-6 hr/week customer-success investment.

Month-by-Month Indie SaaS Mortality (Per Indie-Hacker Public Patterns)

Month	Customer Range	Maintenance Hours/Week	Operator State	Cumulative Mortality
Month 1	30-80	2-4	Energized, honeymoon	5-10% (pre-launch defects)
Month 2	75-150	4-7	Growth, still excited	10-15%
Month 3	100-250	5-9	Bug list growing, first fatigue	20-30%
Month 4 (modal collapse)	150-350	6-12	Excitement gone, hours 55-70/wk, new idea pulling	40-55%
Month 5	flat or declining	8-14	Crisis decision: invest, accept, or sunset	55-65%
Month 6	varies	resolved or 0 (dead)	Ghost team installed OR product dead	65-75%
Month 12 (survivors)	200-1,000	8-12 sustainable	Mature product, ghost-team support	~25-30% still alive

Pattern: month 4 isn't where the product fails functionally; it's where the operator runs out of capacity to keep it alive on top of everything else.

Real Founder Patterns (Per Public Reporting)

Per Pieter Levels' open public reporting: maintenance discipline is reportedly the largest underrated factor - he has publicly shut down or wound-down products that no longer cleared his per-product maintenance ROI threshold, freeing capacity for products that did. Per Marc Lou's public X posts: a recurring theme is killing products that don't pay back maintenance hours, even when they have customers. Per Sahil Lavingia's writing on Gumroad's early years: trying to scale features at small revenue created exactly the month-4 collapse pattern; survival came from ruthlessly scoping down. Per Andrew Wilkinson (Tiny Capital acquisitions): the businesses Tiny acquires almost always show this same pattern - survived month 4 because the founder installed support systems before launch, not after the crisis hit.

"Indie SaaS dies in month 4 because the founder believed shipping was the hard part. Maintenance is the hard part. Shipping is the warm-up."

Composite Case: Anil, Three SaaS Products, Two Surviving

Anil shipped Product A (a sales-email scorer at $19/mo) in March 2025. Month 1: 42 customers, 3 hr/week maintenance. Month 4: 210 customers, maintenance crept to 11 hr/week - but he had installed Custom GPT support before launch (handled 70% of inbox), set an 8-hr ceiling, and built customer portal + searchable FAQ on day 1. Product A survived; today 380 customers, $9,500 MRR, 7 hr/week maintenance.

Product B (a content-calendar generator at $29/mo) shipped July 2025 without ghost-team support pre-installed. Month 4: 145 customers, maintenance at 14 hr/week, simultaneously trying to ship Product C, newsletter slipping. December 2025: Anil ran the retirement protocol. MRR-to-maintenance ratio was $240/hr (below $300 threshold). He sunset Product B over 90 days - migrated customers to an alternative tool, refunded unused subscription portions, redirected the domain.

Product C (an AI-prompt library at $39/mo) shipped February 2026 with full ghost-team support + cross-product shared infrastructure from Product A. Month 3 (current): 198 customers, $7,720 MRR, 6 hr/week maintenance - already trending toward survival.

Pattern: the two products with ghost-team-before-launch survived. The one without died at month 5. Anil's net portfolio: 2 products, $17K combined MRR, 13 hr/week combined maintenance. Sustainable.

The Most Common Failure Mode

Operator skips ghost-team support setup before launch because they want to "see if the product has traction first." The pattern: operator ships Lovable weekend MVP, gets 30-50 founding customers, decides "I'll set up Custom GPT support once I hit $5K MRR - for now I'll just handle support myself." Month 1: operator handles 12 tickets/week personally, 90 min/week, fine. Month 3: 50 tickets/week, 6 hr/week support alone, operator starting to dread the inbox. Month 4: 90 tickets/week, 11 hr/week support, operator is in inbox bankruptcy, response time slipping from 2 hours to 2 days, churn rising because of slow support. Operator now tries to set up Custom GPT support reactively in the middle of crisis - but training a Custom GPT on past tickets takes 6-10 focused hours operator doesn't have because they're drowning in current tickets. Product dies at month 5-6 from operator capacity collapse, not from market failure. The fix: install ghost-team support BEFORE launch, even with 30 founding customers. Custom GPT trained on product docs + FAQ + refund protocols at Day 0. Stripe Customer Portal enabled. Searchable FAQ deployed. Up-front cost: 6-10 hours during the build weekend. Ongoing savings: 4-8 hr/week starting month 2. Operators who pre-install survive at 80-90%. Operators who plan to "add support later" survive at 25-35%.

Decision Rule: Iterate, Sunset, or Sell

Iterate (keep investing) when: (a) MRR/maintenance-hour ratio is above $300/hr or trending up; (b) customer count is growing or flat with healthy retention; (c) operator's portfolio has capacity for this product's maintenance load. Sunset (wind down over 90 days) when: (a) MRR/maintenance-hour ratio is below $300/hr and operator can't reposition pricing; (b) customer base declining 3+ consecutive months; (c) operator's portfolio is at scope ceiling and this product is the weakest. Sell (acquisition exit) when: (a) MRR is $500-$5K with stable customer base + clean tech stack; (b) operator wants to recover capacity but product has clear acquirer fit on MicroAcquire/Acquire.com; (c) acquisition value ($5K-$50K typical) is more useful to operator than sunset (zero recovery). Default: review every product against these criteria quarterly. Operators who commit to making 1-2 retirement decisions annually protect portfolio integrity. Operators who never retire accumulate dying products that starve the surviving ones.

Key Takeaways

• 70% of indie SaaS launched by audience-funded creators dies between month 3 and month 6; month 4 is modal collapse point. Cause is NOT product-market fit failure (fails earlier); cause is the maintenance reality: 4-8 hr/week per product ongoing forever.
• Eight maintenance categories: customer support (1-3 hr/wk); bug fixes (1-3); infrastructure monitoring (0.5-2); feature requests (1-2); content marketing (1-2); payment + refund handling (0.5-1.5); customer onboarding (0.5-1.5); quarterly reviews (0.6-1.2 amortized). Total: 5-12 hr/week per product at 100-500 customer scale.
• Month-4 collapse mechanics: month 1 honeymoon → month 2 growth → month 3 stabilization → month 4 inflection (operator hours 55-70 vs. sustainable 35-50; excitement faded; new ideas pulling attention) → month 5 crisis if not resolved → month 6 resolution (ghost team installed OR product dying/dead).
• Seven patterns of the 30% that survives: ghost team installed before launch; pre-defined maintenance ceiling (8 hr/wk per product); customer self-service architecture from launch; quarterly product audit + retirement readiness; bug + feature batching discipline; founding customer relationship maintenance; product portfolio composition for sustainability (1 product Y1, 2 Y2, 3 Y3, 4-6 Y4-5).
• Maintenance cost by customer scale: 50-100 customers (3-5 hr/wk); 100-300 (5-8); 300-500 (6-10); 500-1K (8-12); 1K-5K (10-15); 5K+ (12-20). Non-linear scaling; operator portfolio caps at customer scale per product.
• Seven survival strategies: install ghost team before launch; build customer self-service from Day 0; set strict 8 hr/wk maintenance ceiling per product; schedule maintenance windows; customer support escalation tree (60-80% Tier 1 Custom GPT, 15-30% Tier 2 operator review, 5-10% Tier 3 operator personal); quarterly retirement review; founding customer ambassador investment.
• Pieter Levels pattern survival math: 5-8 products × 4-8 hr/week = 20-64 hr/week maintenance alone. Plus content (12-18) + strategic (4-8) = 36-90 hr/week total. Requires mature ghost team Support handling 70-90% + strict maintenance ceilings + cross-product Ops automation + relationship batching + quarterly portfolio review.
• Without infrastructure discipline: 30% individual product survival rate → ~10-20% Pieter Levels portfolio success rate. With infrastructure: 80-90% individual + 60-70% portfolio success rate.
• Maintenance is not "build cost extra"; it is the actual cost of running a SaaS business. Operators who model only build cost (Lesson 5.2.2) and skip maintenance modeling fail predictably at month 4-6. Operators who model both succeed at structural Pieter Levels pattern (Lesson 5.1.3) and $1M solo math (Lesson 5.1.4).