scope it before you build it

The compass, not the engine

AI will build anything. It won't tell you what's worth building.

AI collapsed the cost of writing code, and moved the hard part upstream: deciding what's worth building and what to leave out. A real risk now is to ship the wrong thing faster. Scoping first is how you set yourself apart.

Here are 3 articles that inspired me to build this, all about thinking before you write code and keeping things simple.

The bar moved

The code is cheap now. What's scarce is the judgment: what to build, what to cut.

Say no on purpose

Naming what you won't build is half the design. Constraints are the architecture.

Leave with a brief

A one-page spec you hand to your AI or a coach, so it builds the right thing.

Half an hour of honest scoping saves weeks of building in the wrong direction. It starts with two quick gut checks (is this worth building at all, and how you'll prove anyone wants it), then seven focused steps and a one-page brief you can act on.

See an example brief

create content from dev work (turn a merged PR into a draft post), scoped this way. Yours comes out in the same shape.

# create content from dev work ## Why it's worth building - Who feels it: developers who build a lot but market little, including me - Today they: let good work go unshared, or start a post and never finish it - My edge: my own PRs and voice; a generic "write me a blog post" prompt can't pull from my actual diffs ## Demand test (run this before building) - Cheapest test: offer it in two dev communities ("reply if you'd use this") and DM the repliers to see if they'd pay - Commit / kill signal: 5+ genuine "I'd pay" replies → build. Under 2 → shelve it. ## Problem I build cool stuff but don't post about it enough. Marketing doesn't come naturally to most developers. We'd rather build than promote. This lowers the friction from "merged a PR" to "shipped a post." ## Out of scope Multi-user, hosting, a framework, auto-posting to socials, OAuth/GitHub App. Just a local CLI that reuses my existing gh login. ## Success criteria Win: I publish 3+ posts from it in the first two weeks. Kill: I generate angles but never publish, so the friction was me, not the tool. Stop and keep it as a personal script. ## User journey 1. pick a repo from my gh account [MVP] 2. pick a recent merged PR [MVP] 3. get its diff [MVP] 4. AI proposes angles from the diff [MVP] 5. I pick an angle; AI expands it to a skeleton [MVP] 6. I write the prose; save the draft tagged to that PR [MVP] 7. run it on a weekly schedule 8. email me the drafts ## MVP boundary Build now: pick a repo from my gh account; pick a recent merged PR; get its diff; AI proposes angles from the diff; I pick an angle; AI expands it to a skeleton; I write the prose; save the draft tagged to that PR Defer: run it on a weekly schedule; email me the drafts ## Task breakdown ### pick a repo from my gh account - gh repo list ### pick a recent merged PR - gh pr list --state merged - numbered-list or fzf-style picker ### get its diff - gh pr diff <n> → stdout, verify in 30 seconds, then everything else composes onto it ← start here - no auth code, no httpx: gh is already logged in ### AI proposes angles from the diff - pipe the diff into claude -p, prompt returns 3 angles - each angle: hook, why-it-matters, 3 beats, format (tip | learning | blog) ### I pick an angle; AI expands it to a skeleton - second claude -p pass: chosen angle → outline + technical facts from the diff - skeleton, not finished prose, I write the voice ### I write the prose; save the draft tagged to that PR - save to drafts/<repo>-<pr>-<slug>.md with frontmatter (repo, pr, date, status) - state lives in the frontmatter, so the same PR isn't re-suggested ## Constraints - Single user (no auth, no permissions, no multi-tenancy) - Local only (no hosting, no deployment pipeline) - CLI is fine (no frontend to build or maintain) ## Storage - Plain text / Markdown files: human-readable, greppable, no schema ## Dependencies - gh (already installed and authed) - claude -p (uses my Claude subscription, no API key) - typer (CLI framework) ## First thing to build gh pr diff <n> → stdout, verify in 30 seconds, then everything else composes onto it --- Scoped with scopefirst. The simplest thing that works is often the real version.
≈30 min · nothing to install · your answers stay in this browser

Step 1 · Worth building?

Should this exist?

AI will build whatever you ask, which is exactly why this step comes first. Before you scope how, be honest about whether. Anyone can generate the obvious version in one prompt; the edge is knowing it's worth the weeks that follow.

This isn't a score to game. It's a check on your own thinking: if the answers come out thin, that's your cue to sharpen the idea or drop it.

Step 2 · Prove the demand

Belief isn't demand.

You just argued why it should exist, but that's a belief, not a signal. Before you build, decide the cheapest test that gets a real want-it/won't-pay answer from someone who isn't you: a pre-sale, a paid pilot, a landing page with a real signup. You run it after you leave here; naming it now is what stops you building on a hunch.

The tool can't run this for you. It makes sure you don't skip it, because building first and testing never is how most ideas quietly fail.

Step 3 · The spec

What are you building?

Write the spec before the code. One line, then the problem, then what you are deliberately leaving out.

Naming what you won't build is half the design.

Step 4 · User journey

What happens, in order?

Don't start with features. Start with the user. What happens when they first show up? What do they need next? What closes the loop? Aim for 4 to 6 stages.

    Press Enter to add. Features slot into these stages later.

    Step 5 · The MVP boundary

    Which stages make it real?

    The first two or three stages are almost always your MVP. Tap the stages a user needs before anything else makes sense. Everything else won't disappear, it just stops demanding your attention now.

    The moment you draw this line, you are not building everything.

    Step 6 · Break it down

    What's inside each MVP stage?

    Drill into each MVP stage and list its sub-features, until each one is something you could write an issue and PR for. Mark the one or two you would tackle first.

    This groups tasks, it doesn't rank them. You still choose the order, and often the first move is the manual version before you automate it.

    Step 7 · Constraints that set you free

    Each yes removes a class of problems.

    Good architecture is often less about what you build and more about what you decide not to build.

    Step 8 · Boring storage, few dependencies

    Pick the most boring storage that works.

    For small data you rarely need a database. Plain text is readable, editable, greppable, and backed up with standard tools.

      0 dependencies. Two is better than twenty.

      Step 9 · Your brief

      Here's what's worth building first.

      This is your design artifact. Hand it to your AI to guide the build, or to someone who has shipped this before.

      Want a human read first? Email it to Bob and he'll reply with a direction.

      Use AI? Copy the prompt. It makes the AI restate the plan and flag gaps before writing code.

      Already have a codebase? scopefirst is for new builds. If you're untangling, rescuing, or scaling something that already exists, that's where Bob's coaching comes in.

      Did this help you scope a build? Share it to help somebody else build the simplest thing first.