There is a particular kind of insanity involved in deciding to build professional audio plugins by yourself. The audio plugin market is dominated by companies with teams of DSP engineers, UI designers, QA testers, and marketing departments. Competing with that as one person from a home studio in Copenhagen sounds, on paper, like a terrible idea.
I did it anyway. Here is what that actually looks like.
The tools
The stack is C++ and JUCE — a framework that lets a single codebase produce AU, VST3, and AAX plugins for both macOS and Windows. The DSP runs on the audio thread, so everything has to be real-time safe: no memory allocation, no locks, no blocking calls. The GUI is custom-drawn from code, not pre-rendered images. It is a demanding toolchain, but it gives full control over every pixel and every sample.
The iteration cycle
Building an audio plugin is not like building a web app where you can ship fast and fix later. Users load plugins into sessions that they work on for weeks or months. If a plugin update changes the sound even slightly, it breaks the trust that the user's saved sessions will play back correctly. If a plugin crashes, it can take down the entire DAW session and potentially lose unsaved work.
This means the iteration cycle is slow by modern software standards. I write code, compile, load the plugin in a DAW, test it with real audio material, listen critically, adjust, recompile, test again. A single parameter change in the DSP might require hours of listening across different source material before I am confident it is an improvement.
There is no A/B testing with real users. There is no analytics dashboard showing me which features get used. It is me, a pair of studio monitors, a set of headphones, and a collection of reference tracks that I know intimately. The feedback loop is my own ears, which is both the strength and the limitation of working solo.
Testing across DAWs
This is the part that nobody warns you about. Every DAW implements the plugin API slightly differently, and each one has its own quirks that can expose bugs you would never find in isolation.
Logic Pro is my primary development environment, and it is generally well-behaved with AU plugins. But Logic has its own opinions about things like parameter smoothing, sidechain routing, and how it handles plugin bypass, and you need to account for all of them.
Ableton Live handles audio buffers differently from Logic and has a unique approach to plugin delay compensation. Things that work flawlessly in Logic sometimes need adjustment to feel right in Ableton. The GUI rendering can also behave differently because Ableton uses its own windowing system for plugin interfaces.
Pro Tools is the most demanding host. AAX plugins have stricter requirements around real-time safety, and Pro Tools is less forgiving of anything that even approaches undefined behaviour. But Pro Tools is the industry standard for professional studios, so supporting it is non-negotiable.
FL Studio has one of the largest user bases in electronic music production, and its plugin scanning and loading behaviour is different enough from the others that it needs dedicated testing. Reaper, Studio One, Bitwig, Cubase: each one is another environment where things might work differently.
I test in all of them. Not just "does it load," but "does it sound exactly the same, does the GUI render correctly, do the parameters automate smoothly, does undo/redo work, does it handle sample rate changes gracefully." It is tedious, time-consuming work, and there is no shortcut.
Cross-platform: macOS and Windows
Building for both macOS and Windows as a solo developer means maintaining two build environments, two sets of code signing certificates, two installers, and two sets of platform-specific edge cases.
On macOS, you need to handle Universal Binary builds (supporting both Intel and Apple Silicon), code signing with an Apple Developer certificate, and notarisation through Apple's servers. On Windows, you need to deal with MSVC compiler differences, code signing with an Authenticode certificate, and an installer that handles the various VST3 installation paths that different users might expect.
The C++ code itself is almost entirely cross-platform thanks to JUCE, but "almost" hides a surprising number of small differences. File path handling, font rendering, high-DPI display scaling, and thread behaviour all have platform-specific considerations. Every release cycle includes a full round of testing on both operating systems.
The advantage of being solo
Reading all of this, you might wonder why anyone would choose this path. The answer is creative control.
When I decide that Tonality EQ should have five distinct EQ modes, there is no committee to convince. When I decide that Warmth Engine's saturation should be perception-tuned rather than using a standard waveshaping approach, there is no product manager asking for a simpler feature that ships faster. When I hear something in the DSP that is not quite right, I can spend three days refining it without justifying the time to anyone.
Every decision in these plugins reflects a single, consistent vision of how they should sound and feel. That coherence is hard to achieve in a team, and it is something users can sense even if they cannot articulate it. The plugins feel opinionated rather than designed-by-committee, and in a market with hundreds of EQs and saturators, having a clear point of view is what makes a plugin worth reaching for.
Solo development also means I can be honest about what the plugins are and are not. I am not trying to be everything to everyone. Tonality EQ is not a mastering-grade linear-phase EQ with 64x oversampling. Warmth Engine is not a multi-algorithm saturation suite with fifteen different emulation modes. They are focused tools that do specific things well, and that focus is a direct result of having one person making all the decisions.
The reality
Building audio plugins solo is slow, demanding, and occasionally isolating. There are days when a cross-platform bug takes eight hours to track down and turns out to be a single misplaced cast. There are weeks when the DSP work feels like it is going nowhere and the mix bus just does not sound right no matter what I try.
But there is also a clarity to it that I find deeply satisfying. Every line of code, every design decision, every dB of gain staging exists because I decided it should be there. The plugins are exactly what I wanted them to be, and when someone writes to say that Tonality EQ solved a problem in their mix or that Warmth Engine added exactly the character they were looking for, that feedback goes directly to the person who built it.
If you want to see what opinionated solo development sounds like, check out the plugins.