Running a Dozen Products Solo: Portfolio Operations for Indie Developers in the Vibe Era

AI has driven the cost of "building a product" to the floor, and a new species has emerged among indie developers: one person running 5, 8, even a dozen products at once. Marc Lou's public revenue dashboard lists 14 products; Pieter Levels' name sits on Nomad List, Remote OK, PhotoAI, and a string of others; Tony Dinh maintains TypingMind while having sold BlackMagic. But the flip side: an indie developer running 4 SaaS products wrote on dev.to that his burnout didn't come from lack of time, but from shredded attention quality — deep UI work for product A in the morning, onboarding emails for product B by noon, debugging product C's integration in the afternoon, waitlist questions for product D at night. "Productive by every time-tracking metric. Only the morning counted as good work."

That is the new challenge for indie developers in the vibe-coding era: AI solved the capacity to build; the complexity of running things is growing exponentially. This guide is about "portfolio operations" — managing your dozen products like a fund manager manages positions: a three-tier structure, time allocation, shared infrastructure, and a decision matrix. Note the boundaries: this is not "how to pick ideas" (that's the validation guide's job), nor "when to quit" (the kill-list guide covers that). It's about how your time, attention, and infrastructure get allocated when multiple products coexist.

Portfolio math: your expected value comes from count, not polish

Start with real numbers from October 2026 (Marc Lou's public dashboard, via GreyJournal): CodeFast at $7,200/month, ShipFast $2,000, Ship or Die $2,800, Indie Page $640, Stalkr $290, SuperShrimp $238, LaunchViral $129, Zenvoice $138, ByeDispute $96, WorkbookPDF $67, Habits Garden $19, PoopUp $9, BioAge $0. Ten of fourteen products make under $1,000 a month — not failure, but the normal shape of a portfolio: one product carries the month, a dozen others cover the floor.

Two counterintuitive conclusions hide in that data:

• Expected value comes from shipped count, not single-product polish. A builder with 12 live products and a 10% breakout rate is running better odds than someone polishing one app into year three. Pieter Levels publicly committed in 2014 to "12 projects in 12 months" — Nomad List and Remote OK came out of it; he's said dozens of earlier projects went nowhere. Tony Dinh built TypingMind, DevUtils, Xnapper, and sold BlackMagic to HypeFury for $186K. Every product in the portfolio is an attempt, not a bet.
• Selling is a normal move, not surrender. Acquire.com's median is a 3.9× profit multiple with 81 days average time on market. A $2,000/month product at 71% margins converts to roughly $66,000 in cash — and more importantly, frees attention, your scarcest asset. Marc Lou sold MakeLanding ($35,000) and GameWidget ($4,000) and kept starting new things. That's the loop working.

Daniel Vassallo gave this playbook a name: Small Bets. The thesis in one line: trade count for odds, and use the portfolio to absorb variance. AI merely compressed the cost of "placing a bet" from "three months" to "a few weekends," making the strategy available to ordinary builders for the first time.

The three-tier structure: give every product a job description

Figure 1: The three-tier portfolio. The point isn't the number of tiers — it's that each tier gets different treatment. Spreading effort evenly is the portfolio's #1 killer.

Sort your products by "revenue potential × current state" into three tiers, each with an explicit operating strategy and time budget:

Cash cows: maintenance mode, ~20% of time

Validated products with steady revenue. The strategy is "don't touch it": fix bugs, renew servers, answer critical support — no new features. A cash cow's job is to pay you a salary so you can afford to lose time in the experiment tier. Marc Lou's CodeFast is the archetype — it doesn't need growth, it needs to not die. The anti-pattern is "feature addiction on the cash cow": every new feature is a permanent addition to maintenance cost. Cash cows should get thinner over time, not fatter.

Growers: double down, ~50% of time

Products with traction: users growing, people paying, feedback specific. This tier eats half your time on growth work: SEO content, integration ecosystems, pricing experiments, onboarding optimization. The bar: if 8 straight weeks at 50% time moves no core metric, it doesn't belong here — demote it to experiments or send it to the decision matrix.

Experiments: low-cost bets, ~30% of time

Weekend-scale products; options on ideas. The rules: an extremely low bar to launch, an extremely strict bar to survive. Launch bar: it runs, it can take money (or collect emails), it has a landing page. Death bar: 30 days live with no organic traffic and no willingness-to-pay signal → archive. Experiment-tier products don't get roadmaps; their mission is to quickly prove "this idea isn't worth it" or "this deserves promotion to grower."

20/50/30 is a starting point, not dogma. Just starting out with no cash cow, you might be 0/30/70; with a fat cash cow, 10/60/30. Rebalance quarterly based on actual tier performance, not your feelings.

Attention management: time can be sliced, attention can't

Back to the 4-SaaS developer's insight: burnout isn't a time problem, it's an attention quality problem. He found calm 45-hour weeks more draining than hard 60-hour ones, because he "burned his sharpest attention on one product, then expected the same sharpness for everything else." AI makes this worse: the cheaper execution gets, the more pits you dig, and the more fragmented your attention becomes.

Three field-tested methods:

• Schedule by cognitive load, not by product. Put deep work (architecture, pricing, core feature design) in the first 3 hours of the day, for exactly one product — usually the most promising grower. Afternoons handle shallow work: email, small bug fixes, dashboards — cross-product allowed. The principle: deep work is single-threaded; shallow work can be multi-threaded.
• Give each product an "on-call day." Mondays are product A's support-and-ops day, Tuesdays product B's. On non-on-call days, you don't read that product's non-urgent messages. Without on-call rotation, your day gets sliced by 4 products' Slacks and inboxes into 15-minute fragments — and nothing deep happens in 15 minutes.
• Use AI as a context cache. The biggest cost of switching products is recalling context. Keep a per-product AI-readable brief (status, this week's goal, todos, known pitfalls); before switching, have the AI "warm you up" in 2 minutes: where you stopped, what's next. An order of magnitude faster than digging through your own chat history.

Remember: AI lowers execution cost, not decision cost. Deciding "which product gets next week" is the one job AI can't do for you — it can only execute your decision faster. Attention allocation is the fund manager's only non-outsourceable work.

Shared infrastructure: economies of scale for a company of one

The biggest hidden cost of multiple products is reinventing the wheel: separate auth, separate Stripe integrations, separate monitoring per product. The core infrastructure thesis of portfolio operations: turn everything "every product needs" into a template, so a new product starts at 80 points on day one.

• Starter template: auth (login/signup/password reset), billing (subscriptions/one-time payments/invoices), landing page, analytics, error monitoring, transactional email — as a private scaffold. New product = clone template + write the core feature. Marc Lou's ShipFast is literally this template productized (and it makes $2,000/month on the side — two birds).
• Unified ops dashboard: every product's domains, SSL, billing, and backup status in one view. The most common death for a solo multi-product setup isn't "no users" — it's "forgot to renew a server, discovered it three days down." Automate "don't die": uptime monitoring + billing-expiry alerts covering all products.
• Unified support inbox: one email/ticket system collecting all products' complaints, tagged by product. Users don't care how many products you run; they care that someone replies. A central inbox lets you batch-process on on-call days instead of being interrupted all day.
• Separate P&L, unified view: each product accounts revenue and cost independently (otherwise you won't know who's actually making money), but the dashboard is unified. Spend 30 minutes monthly asking: whose margins are slipping? Whose server bill quietly grew?

This infrastructure costs roughly 1–2 weeks up front, but it's the dividing line between "a portfolio" and "a pile of side projects." Without shared infrastructure, every new product starts at linear cost from zero; with it, marginal cost approaches zero — which is precisely the premise that makes "placing bets" viable in the AI era.

The decision matrix: sentence every product once a quarter

Figure 2: The quarterly decision matrix. X-axis is maintenance cost, Y-axis is revenue potential. Plot every product each quarter; the quadrant decides next quarter's treatment.

Four quadrants, four sentences:

• High potential × low cost → double down. This is where your 50% goes. The bar: organic user growth, improving paid conversion, maintenance that's mostly "adding features" rather than "firefighting." Doubling down means "give it more of your time," not "hire for it" — you're still one person.
• High potential × high cost → fix or sell. The most agonizing quadrant. First question: is the high cost structural (rotten architecture, tech debt) or temporary (just launched, feature-incomplete)? Temporary high cost is worth fixing — spend 2 weeks refactoring, drive maintenance cost down, and it graduates to "double down." Structural and unfixable: list it for sale. Someone will pay 3.9× profit for a "promising mess," and walking away with cash beats bleeding out slowly.
• Low potential × low cost → keep for rent. Don't touch it; let it run itself. These products are the portfolio's "floor": a few hundred dollars a month, zero maintenance. Most of the sub-$1k entries on Marc Lou's dashboard live here. Their job is diversification — plus the occasional psychological comfort of "I still have income."
• Low potential × high cost → kill. Sunset with dignity: 30 days' notice to users, data export, a postmortem post. The kill criterion isn't "no revenue" — it's "sustained attention drain." A $200/month product demanding 3 firefighting hours a week has a negative hourly wage. The kill-list guide covered how to kill; here's when: two consecutive quarters in the kill quadrant, no hesitation.

Cadence: one portfolio review per quarter, one hour. Plot every product on the matrix, rebalance next quarter's time allocation, and produce the kill/sell/double-down list. Not monthly (too noisy), not semi-annually (zombies live too long).

A worked example: one quarterly review

The matrix is static; the plotting is alive. Suppose you hold 3 products — here's a quarterly review:

• Product A, "form widget": $300/month, zero support tickets and zero downtime in 90 days, you barely touched it. Plot: low potential × low cost → keep for rent. Next quarter's action: none. Quietly collecting money each month is its entire KPI.
• Product B, "AI meeting notes": $1,200/month and growing, but 3 firefighting hours a week (transcription failures, billing mismatches). Plot: high potential × high cost → fix first, sell if unfixable. Next quarter's action: 2 weeks rebuilding the transcription queue into something stable, then 4 weeks of observation. If maintenance cost comes down, it graduates to "double down" and eats 50% of your time; if it's still weekly firefighting, list it on Acquire.com — $1,200/month at a 3.9× multiple is a respectable exit.
• Product C, "habit tracker": 25 days live, 47 signups, 0 paying. Plot: still in the experiment observation window, not on the matrix yet. Next quarter's action: 5 more days — one pricing-page A/B test and one activation email. At the 30-day mark, no willingness-to-pay signal → archive, enter the kill flow.

One table is the entire output of the review: product / quadrant / next-quarter time split / tripwires (what promotes or demotes it). Print it and tape it next to your monitor — any mid-quarter impulse to "add a feature to C" gets checked against this table first. C is in its experiment window; it doesn't deserve the thought "add a feature."

The table's other job is fighting sunk cost. You wrote product B for 4 months; you're attached. But on the matrix it's just "high cost" — 6 weeks to fix or sell, no negotiation with your feelings at execution time, because the rule is already on paper.

Before you sell: the 30-day pre-listing checklist

Once the decision matrix sentences a product to "sell," don't list it immediately. Buyers buy verifiable cash flow, not your code. Four things in a 30-day prep window move the sale price:

• Clean the books: export 12 months (minimum 6) of revenue, refunds, and server/third-party bills into one clean P&L. Separate anything mixed into personal accounts first — a buyer's first move on seeing messy books is to cut the price.
• Technical handover pack: a README covering deploy steps, third-party key inventory, and known pitfalls. Buyers fear nothing more than "the project only the original author can run." This doc is also your own exit insurance: fewer post-sale questions means lower time cost.
• Growth evidence: compile organic traffic, conversion rates, and user feedback screenshots. The key proof is "it runs without you" — 30 days of zero involvement with revenue intact is the strongest selling point there is.
• Price anchor: Acquire.com's 3.9× annual-profit median is a starting point, not a ceiling. Growing products can command 4–5×, pure rent-collectors around 3×. Leave 10–15% negotiation room in the list price.

Note the division of labor with the exit guide: that one covers the transaction (negotiation, contracts, closing); this covers the portfolio view — why sell and what to prepare. Freed attention flows back to the "double down" quadrant per matrix rules. Selling isn't the end — it's ammunition to add to your winners.

Four anti-patterns

Anti-pattern 1: spreading effort evenly. Giving 5 products 20% each leaves all 5 half-dead. A portfolio's power comes from asymmetric bets: 50% to the most promising, 20% to keep the cash cow alive, 30% sprayed on experiments. Egalitarianism misunderstands what "portfolio" means.

Anti-pattern 2: life support for zombies. "The server's only $5/month, just leave it." The $5 is trivial; the real costs are the monthly glance at its flat dashboard, the occasional support email, the guilt. Every minute of life support for a low-potential, high-cost product is stolen from the double-down quadrant.

Anti-pattern 3: selling the cash cow too early. Seeing Acquire.com's 3.9× and getting tempted to sell the golden goose. Do the math: a $2,000/month product at 70% margin pays you $16,800 a year in passive income; selling nets ~$66,000 but destroys your "rain or shine" floor. Sell the high-potential, high-cost headache you can't fix — not the low-cost cash cow.

Anti-pattern 4: raising an experiment like a cash cow. Doing "brand refreshes," "multi-language," and "enterprise tiers" for a $19/month product is avoidance of the real decision (kill it, or admit it has no potential). An experiment has exactly one KPI: prove within 30 days it deserves promotion. Can't prove it — archive.

One-page checklist

• Tier assignment: every product is clearly cash cow / grower / experiment — no "neither" cases
• Time budget: 20/50/30 (or your version) set; this week's actuals can be checked against it
• Deep work: first 3 hours daily to exactly one product (the best grower)
• On-call rotation: each product has fixed on-call days; non-urgent messages ignored otherwise
• Shared infrastructure: starter template / unified ops dashboard / central support inbox / separate P&L in place
• Quarterly review: 1 hour per quarter, all products through the decision matrix, kill/sell/double-down list out
• Sell discipline: only sell "high potential, high cost" cases you can't fix — never the low-cost cash cow
• Kill discipline: two consecutive quarters in the kill quadrant → 30-day dignified sunset

Back to the fundamental question: why run a dozen products as one person instead of going big on one? Because in the AI era, the moat moved — it used to be "getting it built"; now it's "keeping it running." And the bottleneck of running things is attention, not code. The portfolio strategy admits "I don't know which one will hit," then turns "not knowing" into a managed asset: cash cows pay the bills, growers chase the upside, experiments buy options, and the decision matrix cuts losses on schedule. You're not running 12 products — you're running a system that produces hits. As long as the system survives, the hit is a matter of time.