How to Scope Your First Audio Plugin Idea (Will / Won’t)

Why scope matters more with AI

AI coding assistants are eager. Ask for “a synth” and you’ll get oscillators, a filter, an LFO, presets and a half-working arpeggiator — none of it quite right, all of it tangled together. Every additional feature is another place for a bug to hide, and another thing the assistant has to keep track of between sessions.

A tight scope fixes that. It gives you a definition of “done,” lets you test each change by ear, and gives the AI a document to re-read whenever it starts drifting.

The one-job test

A good first plugin does one job that you can describe in a sentence and hear within seconds. Try finishing this sentence:

“When I ______, it ______, and it sounds ______.”

“When I hold a key, it plays a slow evolving pad, and it sounds warm and blurry.”
“When I press start, it plays a click with an accented downbeat, and it sounds crisp but not harsh.”
“When I click a pad, it plays a sample from a random start point, and it sounds glitchy.”

If you need “and” three times, the idea is probably two or three plugins.

Good first ideas

Type	Small first version	Why it works
Pad / drone	One sustained chord with attack, release and a tone knob	Forgiving; mistakes still sound musical
Click / practice	BPM, accent on beat 1, start/stop	Easy to verify by ear and with a stopwatch
Drum machine	Four voices, 16-step grid, one pattern	Clear visual feedback; timing teaches a lot
Sample pads	Three pads, each loads one WAV and plays it	Teaches file loading and triggering simply
Simple effect	A single delay with time and feedback	One signal path, obvious results

Will / Won’t / Build-next

Write three short lists before you write a prompt. This is the most useful ten minutes of the whole project.

Will (day 1): one or two behaviours the first version must have. Nothing else.
Won’t (not now): things you are deliberately leaving out. Writing them down stops both you and the AI from sneaking them in.
Build-next: two or three small features, one per line, in the order you’ll add them.

Worked example: a drone box

It’s a: drone generator
I use it to: record long beds under ambient tracks
First it must: play a two-note drone in a key I pick

Will:
1) Root note + fifth, key selectable
2) Slow fade in / fade out on start/stop

Won’t:
- No compiled VST/AU yet
- No MIDI input
- No presets, no effects rack

Build-next:
1) Slow filter drift (LFO on cutoff)
2) Add an octave layer with its own volume
3) Simple reverb

Notice how boring the Will list is. That’s the point. The interesting parts arrive one at a time through Build-next, and each one is small enough to test.

Worked example: a practice click

Will: 1) Click at a chosen BPM  2) Accent beat 1
Won’t: no DAW sync, no phone app, no sound library
Build-next: 1) Tap tempo  2) +2 BPM every 8 bars  3) Swing

Anti-patterns that stall first projects

Scoped “A pad that plays one warm chord, with attack, release and a darker/brighter knob.”

Unscoped “A wavetable synth with a mod matrix, 200 presets and an AI that writes melodies.”

The everything-plugin

Combining a synth, a sequencer and an effects rack means three projects with three sets of bugs. Pick the part you care about most; the others become Build-next or a later plugin.

Format-first thinking

Starting with “it must be a VST3 and AU, signed, on Mac and Windows” front-loads the hardest, least musical work. Prove the sound first. See browser prototype to VST/AU.

Clone-a-classic

“Make it exactly like a famous hardware synth” sets a bar you can’t measure against and invites endless tweaking. Describe the qualities you like instead: “gritty low end, slow filter, slightly unstable pitch.”

UI before sound

Beautiful knobs on a silent instrument are demoralising. Use plain sliders until the sound is right; styling is a great Build-next item.

Moving goalposts

Changing the core idea mid-session confuses the assistant and you. If a new idea is exciting, write it down for later and finish the current Will list first.

Batching requests

“Add reverb, presets and MIDI” in one prompt makes it impossible to tell which change broke things. One feature per request, test, save.

A five-minute scoping checklist

Can I describe it in one sentence with at most one “and”?
Can I hear whether it works within ten seconds of pressing play?
Does the Will list have two items or fewer?
Have I written down what it won’t do?
Is every Build-next line a single feature?
Have I named the sound with adjectives or references, not just technical terms?

If you can tick all six, you have a first plugin. For a fuller template, see writing your plugin idea.

What to do with the scope

Save it as a file in your project (for example SCOPE.md) and tell your AI assistant to read it before making changes. When a session drifts, point back to it: “Check SCOPE.md — reverb is Build-next #3, not now.” It sounds simple, and it is remarkably effective.

Want to see how a scope maps onto a working project? The free sample pad is a small example to poke at. Then read the honest guide for the bigger picture, or browse the blog.

Keep going

Learn hub — the full path map
What vibe coding audio plugins really means
How to scope your first plugin
From browser prototype to VST/AU
A JUCE learning path
Writing your plugin idea (intake guide) · Blog

Scope your first plugin