# Product Requirements Document — Ship Not Code

**Version:** 1.0  
**Date:** 2026-09-16  
**Status:** Shipped MVP  
**Source idea:** [@s_chiriac on X](https://x.com/s_chiriac/status/2099065120022306894) — “A tool that stops you from coding more features and forces you to do marketing instead.”

---

## 1. Problem

Solo founders default to building. Shipping another feature feels productive. Talking to users, posting, outreach, and asking for money feels optional.

That bias keeps products at $0 revenue long after they are usable.

The product exists to invert the default: **today you do distribution, not code.**

## 2. Insight

Growth work is not mysterious. At each revenue stage the next useful actions are a short list:

| Stage | Goal | Dominant work |
|---|---|---|
| 0 | First sale | Conversations, manual outreach, asking |
| 1 | $100 MRR | Repeatable channel, social proof, pricing |
| 2 | $1,000 MRR | Consistency, referrals, content that compounds |

Founders do not need another analytics suite. They need **one mission today**, sized so it can be finished in under 45 minutes, and a lock on “just one more feature.”

## 3. Product

**Ship Not Code** is a local-first web app.

1. Founder describes the product in one sitting.
2. They pick their current revenue stage.
3. Each calendar day the app issues **three missions** (primary + two backups) tailored to stage + product.
4. Completing the primary mission is the only “win” that day.
5. Opening the Feature Lock records an urge to code and redirects to a growth action instead.

No account. No backend. State lives in `localStorage`.

## 4. Goals

### Business / product goals (this repo)

- A founder can go from empty state to first mission in under 90 seconds.
- Missions are specific enough to execute without another tool.
- The Feature Lock makes “I should add X” visible as a pattern.

### Non-goals (v1)

- OAuth to GitHub / Stripe / analytics
- Team accounts
- Automatic posting
- LLM generation at runtime (templates + interpolation only)
- Mobile native apps

## 5. Personas

**Primary — Solo technical founder**  
Has a working MVP. Has tweeted twice. Has not DM’d 20 people. Believes the product is “not ready.”

**Secondary — Indie hacker mid-funnel**  
Has a few customers. Wants $1k MRR. Keeps rewriting the landing page.

## 6. User journeys

### First run

1. Land on dashboard → empty state CTA “Connect your product.”
2. Fill: name, one-liner, who it is for, URL (optional), channel preference, current MRR, stage.
3. Save → today’s missions generate immediately.

### Daily use

1. Open app.
2. Read primary mission + why it exists at this stage.
3. Do the work outside the app.
4. Mark done. Optional note (who you talked to, link posted).
5. Streak increments if at least the primary is done.

### Urge to build

1. Click Feature Lock.
2. Type the feature they wanted to add.
3. App stores the urge and shows a substitute growth mission.
4. They can still ignore it — the point is the pause.

## 7. Functional requirements

| ID | Requirement | Priority |
|---|---|---|
| F1 | Product profile CRUD in localStorage | P0 |
| F2 | Stage model: `zero`, `first_sale`, `hundred`, `thousand` | P0 |
| F3 | Deterministic daily mission set from seeded templates | P0 |
| F4 | Interpolate `{product}`, `{audience}`, `{url}` in copy | P0 |
| F5 | Complete / undo mission; persist notes | P0 |
| F6 | Streak based on consecutive days with primary complete | P0 |
| F7 | Feature Lock log with timestamp and substitute mission | P0 |
| F8 | History view of last 14 days | P1 |
| F9 | Export / import JSON backup | P1 |
| F10 | Reset product (destructive, confirmed) | P1 |

## 8. Mission engine

Missions are data, not model calls.

```
seed = hash(YYYY-MM-DD + productName + stage)
pick 3 unique templates from the stage pool
```

Each template has: `id`, `title`, `why`, `steps[]`, `minutes`, `channel`, `stage[]`.

Pools include at least 12 templates per stage so a two-week stretch does not feel identical.

## 9. UX requirements

- Dark, dense, workbench UI.
- One primary action per screen.
- Mission cards show time estimate up front.
- Never hide the Feature Lock.
- Soft lock: honor system, not a git hook.

## 10. Technical requirements

- Static files only. No build step. `file://` works.
- State in localStorage key `ship-not-code.v1`.

## 11–14. Metrics, risks, backlog, acceptance

See repo README. MVP is accepted when a new user can save a product, see three missions, complete the primary, use Feature Lock, refresh without losing state, and find this PRD in the private repo.