The plugin is finished. That's about a third of the work.

There's a specific day on every plugin project that feels like the end. The DSP is right, the interface responds, someone plays music through it and grins. Everybody takes a screenshot.

Between that day and the day a stranger can buy the thing and use it, there are usually weeks (or months!). Nothing in those weeks is glamorous, almost none of it is DSP, and it's the part most teams haven't budgeted for.

Everything between the code and the customer

The DSP is just one of those boxes. All the others have to exist too before anyone can pay you, and each one finds its own way to fail.

Signing, notarizing, and the ways it fails quietly

A plugin is code that a stranger downloads and loads into their expensive workstation. Every operating system now treats that with suspicion (and they're right to).

On macOS the binary has to be signed with a Developer ID and then notarized, which means uploading it to Apple, waiting for their scan, and stapling the result. On Windows it needs its own signing certificate. And AAX, the Pro Tools format, has to be signed through PACE on top of all that, with a separate account, separate tooling and its own rules.

What makes this eat so much time is that the failures are silent. A wrong flag doesn't throw an error, it gives you a build that works perfectly on your machine, where everything is already trusted, and refuses to load on a customer's. We keep an internal list of these, and it's mostly things that fail with no message at all: a missing hardening flag that makes notarization reject the package, an option whose default quietly corrupts a symlink when the payload is copied.

One more that catches people: for AAX, the signing identity is ours as a studio, not the client's. Several repos we inherited assumed the opposite and lost days to it. If you build for other companies, write down who owns which identity before you need it at midnight.

The test matrix nobody wants to own

A plugin doesn't run in your app, it runs inside someone else's, and there are a lot of someone elses. Pro Tools, Logic, Ableton, Cubase, Reaper, Fender Studio Pro, Dorico and Sibelius if you are in notation, on two operating systems, on Intel and Apple Silicon, at whatever sample rate and buffer size the user picked.

• Pro Tools
• Logic Pro
• Ableton Live
• Cubase
• REAPER
• Fender Studio Pro
• Dorico
• Sibelius

They don't agree. Hosts differ on how they scan plugins, when they call you, what they do with state, how they handle a plugin that reports latency, whether they sandbox you at all. A bug that only appears in one host at one buffer size is completely normal and you find it by testing, not by reasoning.

Add to that the environment: antivirus software that quarantines your engine on first launch, corporate machines with locked down permissions, an old operating system nobody told you about. None of that is a bug in your code, but from the customer's side it looks exactly the same: the product doesn't work.

The systems that are not the plugin

Now the part that surprises people who have only shipped apps. A plugin business is a small software company wearing a trenchcoat, and all of these have to exist.

There's a website and a store, which means a checkout, tax handling, refunds and a customer who paid twice by accident. There's a license server, because someone has to decide whether this copy is allowed to run on this machine, handle activations and deactivations, cope with a user who reinstalled their OS, and keep working when your server is down. We ended up building our own (twice, actually), because the problem is pretty specific: the license check has to work offline, so the enforcement is a signature the plugin can validate with no network at all.

There are updates and installers, per platform, which have to upgrade cleanly over the previous version without stranding presets. There's a support desk with real humans on it, because the questions are real and a lot of them aren't bugs. There's usage data, so you know which features people actually use, not just the ones you enjoyed building. And there's marketing tracking, so you know which of your efforts brought customers and which just brought traffic.

Each of those is a system of its own, with its own maintenance and its own on call moments. And none of them show up in the estimate when someone asks how long the plugin will take.

Support is a product feature

The one I'd push hardest on is support, because it's the one most often treated as an afterthought, and it's where you find out how your product really behaves out there.

Half the tickets aren't bugs. They're an antivirus, a permissions dialog, a stale driver, a host that needed rescanning, a user who did exactly what the interface suggested and got something else. Every one of those tells you something about the design, and a team that actually reads its tickets ships a better version six months later than a team that just closes them.

It also changes the architecture. If your product can't tell you what happened on a machine you'll never see, every ticket turns into an archaeology project. Logs a user can send you in one click, with the version, the host and the settings in them, pay for themselves in the first month.

Why we do all of it

We build the whole path at Edge Audio Labs, not just the interesting third. The DSP and the plugin, yes, but also the signing and notarization pipeline, the installers, the licensing, the store, the site it sells from, the analytics behind it and the support process that keeps it honest.

I'm not saying this to sound busy. In practice, these pieces just don't come apart. How you license decides what your installer does. What your support tickets say decides what the next version fixes. Where the model runs decides whether you can sell the thing once or monthly. A team that owns the whole path can make those calls together, early, when changing them is still cheap.

The plugin is the part everyone can see. Funny enough, it's also the part we worry about least.