# Ship It

**A 30-Day Build System for Indie AI Apps**

*by Theo Park · v1.2 · free, redistribute freely · theopark.substack.com*

---

## What this is

A short, opinionated playbook for building and shipping a small AI tool
in 30 days. Not a tutorial on transformers. Not a hype book. A system
for going from idea → live URL → first users without spending six months
on perfect architecture.

Three principles run through everything:

1. **Decide before you code.** Most failed indie projects don't fail in
   the IDE — they fail in the head, weeks before the first commit.
2. **Ship one slice end-to-end.** Auth + the model call + a deploy.
   Everything else is detail.
3. **Find one real user.** Friends don't count. The first time someone
   you don't know pays attention, the rest of the project becomes
   different.

---

## What you'll have at the end of 30 days

- A working tool, deployed, with a domain.
- At least one user who isn't you.
- A 200-word write-up of what you learned. Whether you keep the project
  going is a separate decision — most shouldn't.

---

## Table of contents

- **Week 1 — Decide.** Idea filtering. The "would I use this every week?"
  test. The single-sentence pitch. Killing the ideas that won't survive
  the build.
- **Week 2 — Build the spine.** Auth, persistence, one model call,
  one deployment. Everything else gets cut.
- **Week 3 — Show one person.** The first real user. The first real
  feedback. The first time you cut something based on what you actually
  learn, not what you imagined.
- **Week 4 — Public ship.** The launch post. The pricing decision. What
  you do on day 31 and how to know whether to keep going.

---

## Sample — Week 2, Day 9

By day 9 you should have:

- A repo with auth working. Clerk, Auth0, whatever — don't waste a week
  rolling your own.
- A deployed URL that 200s for a signed-in user.
- One model call that produces *one useful output*. Not a workflow. Not
  a pipeline. One call.

Common mistakes I see when readers send me day-9 builds for review:

1. **Over-routing.** Eight routes before any of them do anything useful.
   You need `/`, `/sign-in`, and one workflow route. That's it.
2. **Database overdesign.** A `users` and a `runs` table is enough. Add
   columns later when you actually need them.
3. **Wrong model.** Don't reach for the SOTA model on the assumption
   that you'll need it. Most v1s work fine on a fast, cheap model —
   you can upgrade in week 4 if eval data tells you to.
4. **Polish.** Tailwind defaults are fine. Linear's not perfect on day 9
   either. Polish is week 4 work.

Cut everything that's not in that day-9 list. Resist the urge to "set
up properly" — proper setup happens *after* you have one user, because
you'll know what's worth setting up.

---

## Sample — Week 3, Day 18

You found a person. They tried your thing. Now:

- **Watch them use it.** Don't talk. Don't help. Note where they pause.
- **Ship a fix the same week.** Not "Q2." Not "next sprint." Same week.
- **Stop adding features.** Until the friction your one user hit is gone,
  no new functionality is allowed. This is the hardest discipline in the
  whole book.

The fastest way to lose momentum on an indie project is to not narrow
down based on feedback. The fastest way to keep momentum is to act on
one specific bit of feedback within 7 days.

---

## What this book deliberately doesn't cover

- LLM theory. Read the Anthropic / OpenAI papers and Karpathy's videos.
  Better resources exist; I won't repeat them badly.
- Specific framework tutorials. Frameworks change. The decisions in this
  book don't.
- Anything pre-2024. The ground shifted; I rewrote everything for v1.2
  in late 2025.

---

*(continued in the full ebook — 78 pages, free at theopark.substack.com.
Subscribe and I'll send the rest. No upsell. No course at the end. Just
the book.)*