Solo Studio Monetization Overview

Learning goal: Understand that AI agents have sharply lowered the cost of building but not the cost of distribution and attention, and explain the order in which the eleven documents of this track tackle the problem of "many prototypes, few launches, little revenue".

As of: 2026-09-29 (shared by all eleven documents of the track). Fees, policies and statistics are values checked on 2026-09-28 to 29, and the access dates in the references are the days they were actually checked. Every document lists its sources with dates. All example numbers are assumptions.

Key Concepts

This track teaches, in textbook order, how a developer or PO who can build anything quickly chooses what to build, ships it and gets paid for it.

Principles

Costs AI Lowered and Costs It Did Not

Product revenue can be written roughly as this product:

Monthly revenue = people who reach the product × paid conversion rate (or ad exposure) × revenue per person

An AI coding agent does not directly raise any term of this formula. What shrinks is the build time that sits outside the multiplication.

Evidence of rising supply already exists. According to Appfigures, worldwide app releases across the App Store and Google Play rose about 60% year over year in Q1 2026 (reported by TechCrunch, 2026-04-18). SteamDB counted more than 19,000 games released on Steam in 2025, almost half of them with fewer than ten reviews (2025-12). The easier building becomes, the less the mere fact of having built something brings anyone to your door.

The Core Problem: Many Prototypes, Few Launches

Building is fun and, thanks to AI, fast; the work just before launch is dull and shrinks less with AI. So starting a new prototype always looks more attractive, and hours are spread thinly across many products.

1. No selection criteria — there are no numbers to compare which product is worth more (01, 02).
2. Building without validation — build time is spent without knowing whether demand exists (03).
3. No way to get paid — even after launch, no payment or ads are attached (04–07).
4. Shipping is not a habit — there is no repeatable launch procedure (08).
5. Unable to stop — without kill criteria, products stay "in progress" forever (02, 09).

Learning Map

Part 1 (00–04) covers concepts and theory; part 2 (05–10) covers revenue models in depth and execution. The measurements in 09 and the D90 triage in 10 feed back into the portfolio decisions of 02 and become the next quarter's allocation.

flowchart TD
    D00[00 Overview] --> D01[01 The Economics of a Solo Studio]
    D01 --> D02[02 Product Portfolio Theory]
    D02 --> D03[03 Choosing Opportunities and Validating Demand]
    D03 --> D04[04 Revenue Models: An Introduction]
    D04 --> D05[05 Advertising Revenue in Depth]
    D04 --> D06[06 Paid Sales, Subscriptions and Pricing]
    D04 --> D07[07 Game Monetization]
    D05 --> D08[08 A Shipping System]
    D06 --> D08
    D07 --> D08
    D08 --> D09[09 Measurement and Portfolio Decisions]
    D09 -->|next quarter allocation| D02
    D09 --> D10[10 A 90-Day Plan, Worked Through]
    D10 -->|D90 triage| D02

Applied: The Example Studio

The whole track uses the same example studio. Every number below is an assumption and does not describe any real business.

Runway divides operating cash by the money that leaves each month.

Runway = KRW 18,000,000 ÷ (KRW 3,000,000 + KRW 500,000) = 18,000,000 ÷ 3,500,000 ≈ 5.14 → about 5.1 months

With no revenue, the operating cash runs out in about five months. The goal of this track is to design a path to KRW 3,500,000 of monthly net revenue (living cost + fixed cost) before then. Taxes are not included in this calculation (see the Business section).

Connections to Other Sections

This track does not re-explain the site's other sections; it points to them by name where needed.

Going Deeper

Why "build more" is not the answer. Product outcomes follow a power-law distribution in which a few take most of the total (01 checks this with data). In such a distribution the number of attempts matters, but an attempt that never ships does not count as an attempt. A prototype that is on no store and in no search index has no chance of drawing the big win from the tail. So the default strategy of this track is not "build more" but "choose few, ship to the end, and judge quickly".

Common Misconceptions

• "AI made building easy, so monetization got easy too" — Building got easy. So did it for every competitor using the same tools.
• "A good product spreads by itself" — A product without a designed discovery path (search, stores, communities) stays invisible however good it is.
• "Pick the revenue model after users arrive" — Ads and subscriptions need completely different traffic, trust and retention. The model changes the product design (04).
• "Twelve prototypes are assets" — Unshipped prototypes are closer to inventory that consumes upkeep and attention (02).

Self-Check Questions

1. Can you name two costs AI agents reduced and two they did not?
2. Of the three terms in the monthly revenue formula, which is weakest for your product right now?
3. Compute the example studio's Runway yourself. How many months would it be if the monthly fixed cost were KRW 800,000?
4. Which of the eleven documents should you read first in your current situation, and why?
5. Can you explain in one sentence why an unshipped prototype is at a disadvantage in a power-law distribution?

References

• The App Store is booming again, and AI may be why — TechCrunch (2026-04-18, citing Appfigures data, accessed 2026-09-28)
• Steam Game Release Summary by Year — SteamDB (accessed 2026-09-28)
• More than 19,000 games launched on Steam this year—but almost half have fewer than 10 reviews — PC Gamer (2025-12, citing SteamDB data, accessed 2026-09-28)
• Default Alive or Default Dead? — Paul Graham (2015-10, accessed 2026-09-28)