The Explicit Out-of-Scope List

"Guitopia died of ambition in six days. Bonfire survives by writing its ambition down — in the OUT column."

What Killed the Predecessor

Guitopia, the dormant predecessor, had the same dream as Bonfire and shipped none of it. The reason wasn't laziness — it was the opposite. It chased the most ambitious parts: audio-sync to playback, real-time pitch detection, fine-tuning. Six days in, it had a pile of half-started hard problems and nothing usable. Ambition without a scope boundary is how a project freezes: every hard feature feels essential, so none of them get finished.

The OUT List Is the Discipline

Bonfire's defense is almost embarrassingly simple: write the out-of-scope list explicitly, and treat it as binding.

v1 IN                                  v1 OUT (decide after v1)
-----                                  -----------------------
load song -> tempo/key/chords (Tier A) Live bridge / DAW sidecar
the music model + its API              audio-sync to playback
polymorphic views (fb/kb/staff/tab)    real-time fretboard-follows-audio
scale + chord dictionaries             MIDI auto-patcher (RC-600 etc.)
easy-mode + scaffolding ladder         LoRA fine-tune for song-JSON
Pippa Sidekick + practice loop         low-latency live monitoring

Notice that the OUT column is exactly Guitopia's old ambition. That's not a coincidence — it's the point. The features most likely to freeze the project are named and quarantined on the right, so they can't creep into v1 disguised as 'just one more thing.'

An OUT List Is a Commitment Device

Writing down what you're not building is as load-bearing as writing down what you are. An explicit OUT list turns 'we'll get to that later' (which silently becomes 'we're doing it now') into a real boundary you have to consciously cross. It's a commitment device against your own enthusiasm. The discipline isn't having good ideas for v2 — everyone has those. It's keeping them out of v1 on purpose.

Code

v1 IN vs OUT — the OUT column is the discipline·text

v1 IN                                  v1 OUT (decide after v1)
-----                                  -----------------------
load song -> tempo/key/chords (Tier A) Live bridge / DAW sidecar
the music model + its API              audio-sync to playback
polymorphic views (fb/kb/staff/tab)    real-time fretboard-follows-audio
scale + chord dictionaries             MIDI auto-patcher (RC-600 etc.)
easy-mode + scaffolding ladder         LoRA fine-tune for song-JSON
Pippa Sidekick + practice loop         low-latency live monitoring

# The OUT column IS Guitopia's old ambition -- named and quarantined
# so it can't creep back into v1 as 'just one more thing'.

Exercise

For a project of yours, write two columns: IN (this version) and OUT (explicitly deferred). Force at least three genuinely tempting features into the OUT column — things you actually want but will not build now. If your OUT column is empty or full of things you didn't want anyway, you haven't made a real boundary yet.

Hint

A real OUT list hurts a little — it contains features you're excited about. If everything exciting is in the IN column, that's the unbounded-ambition pattern that freezes projects. The discipline is putting an exciting thing in OUT and meaning it.