| name | make-playbook |
| description | An indie maker playbook inspired by Pieter Levels' (@levelsio) book "MAKE: The Indie Maker Blueprint" — idea validation, fast/DIY building, launching, organic growth, monetization, automation, and exits for bootstrapped apps. Use when the user is starting a new app idea, deciding what to build or build next, prepping a launch, stuck on growth or monetization, deciding whether/how to automate operations, or considering selling a product. |
MAKE Playbook
A working reference system for bootstrapped app builders, inspired by Pieter Levels' MAKE: The Indie Maker Blueprint — meant to be consulted repeatedly across many apps and stages, not read once. This is an original set of checklists and diagnostics built around the book's core ideas, not a copy of the book itself. Read the full book at readmake.com for the deep-dive chapters, war stories, and numbers behind this framework.
The 7-stage model
Idea → Build → Launch → Grow → Monetize → Automate → Exit
Every reference file corresponds to one stage. references/ethos.md is the constant background frame (bootstrapping-first stance, ethics constraints, realistic expectations about persistence) that applies no matter which stage you're in — read it once per session if it hasn't come up yet, and let its ethics constraints override any tactic from the stage-specific files that would violate them (fake engagement, dishonest growth hacks, user-hostile monetization).
Workflow
-
Identify the app and the stage. If the user hasn't said which app or what stage it's at, ask — don't guess. If there's a MAKE.md tracker file in the current project (see below), read it first; it may already answer this.
-
Load the relevant reference file(s). Usually just the current stage's file, but load the adjacent one too when the question sits on a boundary (e.g. "should I charge yet" spans build/launch/monetize; "should I hire someone" spans build/automate).
-
Apply the framework to the user's specific app — don't just restate it. Each reference file ends with a short set of diagnostic questions for that stage; use them to get the specific facts you need (their niche size, their stack, their traffic, their pricing) rather than giving generic advice. Turn the relevant checklist into a concrete, numbered action list for this app, this week.
-
Push toward shipping, not deliberating. The strongest repeated theme across every stage is bias toward action over analysis — perfectionism and endless planning are the most common failure mode. If the user is stuck theorizing, hand them the smallest next concrete step, not more framework.
-
Offer to create or update a per-app tracker. For a new app, offer to copy templates/make-tracker.md into the project as MAKE.md and fill in what's known. For an app that already has a MAKE.md, update the relevant stage section as decisions get made in conversation, so the next invocation of this skill (on this app or a different one) has real state to pick up from.
-
Flag ethics violations even when a tactic would "work." Per references/ethos.md: no fake followers/upvotes/reviews, no dishonest growth-hacking, no selling user data, no dark-pattern monetization. If the user proposes something in this territory, say so plainly and suggest the honest alternative from the relevant reference file.
Quick stage diagnostic
Use this if the user is unsure which stage they're actually in (common when an app has stalled):
| Symptom | Likely stage to revisit | Reference |
|---|
| "I don't know what to build" / idea feels unoriginal or too big | Idea | references/idea.md |
| Stuck deciding tools/stack, or outsourcing before shipping anything | Build | references/build.md |
| Built but nobody knows it exists / one soft launch, no follow-through | Launch | references/launch.md |
| Traffic exists but plateaued, or growth only exists while ads run | Grow | references/grow.md |
| Users but no revenue, or revenue but priced/modeled wrong | Monetize | references/monetize.md |
| Revenue but the founder is the bottleneck on every task | Automate | references/automate.md |
| Considering an acquisition offer or thinking about selling | Exit | references/exit.md |
Principles worth keeping in working memory
- Size a niche before committing: does the price your audience will actually pay, times a realistic customer count, add up to a business worth building?
- Assume only a small fraction of free users convert to paid when sizing an audience against a revenue goal.
- A recurring subscription usually compounds to more revenue than an equivalent one-time price, even accounting for churn — model both before choosing.
- Match your launch-day infrastructure to the platform: a general startup community can send a real, sudden traffic spike.
- Only automate when the time saved clearly exceeds the time spent building the automation.
- Paid acquisition works best after there's already real organic pull — not as a substitute for it.
Ending on an action, not just advice
Every reference file's diagnostic section is meant to end in a concrete, time-boxed next step (e.g. "spend the next 7 days logging 3 problem-ideas a day" for Idea, or "pick a launch date this week" for Launch) rather than just a list of considerations. Carry that pattern into every conversation this skill is used in.
