Two different things
A browser prototype is a web page that makes sound with the Web Audio API. It runs in Chrome, Firefox or Safari, reloads instantly, and needs nothing installed. You can play it and record its output into any DAW using an audio interface loopback or a virtual audio device.
A native plugin (VST3, AU, AAX, CLAP) is compiled code, usually C++, that a host like Ableton Live, Logic, Reaper or FL Studio loads into a track. It receives audio and MIDI from the host, saves its state in your project, and supports automation.
There is no button that converts one into the other. Going native means rebuilding the idea in a native framework — most commonly JUCE — using the prototype as a reference.
Why prototype in the browser at all?
- Speed. Change a number, reload, listen. No compile step.
- Safety. A crash closes a tab, not your DAW session.
- Clarity. You find out whether the idea is musically worth it before investing in build tools.
- AI-friendliness. JavaScript and Web Audio are well represented in what AI assistants know, and small projects fit comfortably in their context.
Plenty of ideas stop here, and that is fine. A browser drone box you record from is a real creative tool.
What carries over
| From the prototype | Carries over? |
|---|---|
| The idea, scope and Build-next list | Fully — this is the most valuable part |
| Parameter list, ranges and defaults | Fully — becomes your plugin parameters |
| Signal flow (osc → filter → envelope → out) | Conceptually — rewritten in C++ |
| Sound design decisions you made by ear | Yes, as a reference to match |
| JavaScript code | No — it must be re-implemented |
| Web Audio nodes (BiquadFilter, etc.) | No — replaced with JUCE DSP classes or your own code |
| HTML/CSS interface | Not directly; JUCE has its own UI system (it also supports web-based UIs in newer versions) |
In other words: the prototype is a spec you can hear. That’s genuinely useful when porting — you always have a reference for “is this right?” — but it is not code you can compile.
What the native path involves
1. Toolchain setup
You’ll install a C++ compiler and IDE (Xcode on macOS, Visual Studio on Windows), the JUCE framework, and usually CMake. Getting a blank example plugin to build and load in your DAW is a milestone in itself — budget an evening or two.
2. Plugin structure
A JUCE plugin has an audio processor (sound) and an editor (UI). Parameters are declared once and exposed to the host for automation and saving. Learning this structure is the core of the JUCE learning path.
3. Real-time rules
The audio callback runs on a high-priority thread with a deadline measured in milliseconds. You must avoid allocating memory, locking, file I/O or logging inside it. Web Audio hid this from you; native code doesn’t. Tell your AI assistant these rules explicitly — it will not always follow them by default.
4. Rebuilding the DSP
Each Web Audio node gets a native equivalent: JUCE’s dsp module includes oscillators, filters, gain, reverb and more. Expect small differences in character; match by ear against the prototype.
5. Testing in hosts
Different DAWs behave differently: buffer sizes change, sample rates vary, state is saved and reloaded, plugins get bypassed and duplicated. Test in at least two hosts, and use the JUCE AudioPluginHost for quick checks.
6. Distribution (if you share it)
Sharing beyond your own machine adds code signing and notarization on macOS, installers, and formats like AU vs VST3. Many hobby plugins never need this — they live happily on the builder’s own computer.
Realistic effort
Every project and person differs, but as a rough guide for a beginner using an AI assistant:
- Browser prototype of a small idea: an evening to a few weekends.
- First JUCE plugin that builds and makes a sound: a few days to a couple of weeks, mostly setup and learning the structure.
- Porting your prototype to a stable native plugin you use daily: weeks to a few months.
Anyone promising a finished, compiled, cross-platform plugin from a single prompt is overselling. AI makes each step faster; it doesn’t remove the steps.
How to use AI well on the native side
- Start from an official JUCE example or the Projucer/CMake template rather than asking the AI to invent project structure.
- Paste the prototype’s parameter list and signal flow into your scope file so the assistant knows the target.
- Port one stage at a time: oscillator, then envelope, then filter. Build and listen after each.
- Paste compiler errors in full. AI assistants are good at fixing them when they can see the whole message.
- Name the JUCE version you’re using; APIs have changed across major versions.
Where Spec → Scaffold fits — honestly
Spec → Scaffold covers the first part of this path: a written scope for your idea, a playable browser prototype, an ordered prompt chain for extending it, and a JUCE learning path for when you want to go native. It does not include a compiled VST/AU plugin. If that matches what you need, it’s $49 on Gumroad; if not, everything on this page still applies.
For a gentler comparison of the two worlds, see the blog post Web Audio vs plugin for beginners. Before porting anything, make sure the idea is tightly scoped and clearly written.
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