One of the top questions we get at The Audio Programmer is: how much does it cost to develop an audio plugin?

The annoyingly accurate answer is: it depends.

On what the plugin does, and everything it needs around it to become a finished product.

That isn’t much use when you’re trying to plan, though. So when I’m looking at a project, I like to start with a different question: how much should you spend?

Start with what the plugin can earn

One way to think about development budget is to work backwards from a target break-even point.

If you price a plugin at $79 and want to have covered your investment by the time you’ve sold 1,000 copies, that’s $79,000 in gross revenue to work with.

That doesn’t mean you should spend $79,000 on development. Payment processing fees, reseller or marketplace commissions, discounts, tax, marketing and ongoing support all have to come out of that too. But it gives you a useful starting point for thinking about what you can afford to invest.

One big advantage software has over hardware is that most of the cost of making it is upfront. There’s no bill of materials for every copy you sell. Once you’ve covered the initial development, each extra copy costs you almost nothing to make, and that changes the economics quite a lot.

How many copies do you realistically think you can sell, at what price, and over what period?

We’ve worked on plugins that took time to build an audience, and others that passed 1,000 sales within a couple of months of launch. We’ve also seen debut products sell many times that over the years and become the foundation of a whole brand.

There isn’t a perfect formula. But working backwards gives you somewhere useful to start.

So what does an audio plugin cost?

If you’re commissioning an experienced team to take a plugin from idea through to commercial release, I’d expect to be thinking in the region of $20,000 and up.

It can absolutely be done for less – particularly with a tightly defined scope, an independent developer, or if you’re able to take on parts of the project yourself. But there’s a difference between hiring someone to develop a plugin and commissioning a team to deliver the finished product.

A simple effect using established DSP is a very different development job from an instrument with original DSP, a large content library and a complex interface.

It really does come down to what you’re building, what you can do yourself, and where you need help.

What actually drives the cost?

A plugin that looks simple isn’t necessarily simple to build. Something with five controls and difficult DSP can take considerably more development than something that looks much more elaborate.

A few things tend to make the biggest difference:

• DSP complexity. An effect using established techniques is one thing. Developing a new algorithm, an analog model or a sample engine that streams large libraries from disk is another. Original DSP can involve a lot of research, tuning and listening.
• The interface. A clean interface with standard controls is relatively quick to build. Animation, visualizers, custom interactions and more complex resizing add work. So does the design itself, whether that comes from your designer or ours.
• Presets and content. Presets take time to make well. Instruments can also involve sample libraries and the tools needed to build and manage them.
• Formats and platforms. VST3 on Windows and macOS, plus AU on Mac, is fairly standard for a commercial release. Adding AAX, CLAP or a standalone version means more development and testing. AAX has additional Avid and PACE requirements, while iOS and Android are a bigger undertaking.
• Licensing. Trials, activation, subscriptions and rent-to-own all need setting up and testing. Using an established licensing service is usually quicker than building your own.
• Installers, signing and notarization. Unglamorous, but essential.
• Testing. Testing on a development machine isn’t the same as testing a finished product. Different DAWs, operating systems, sample rates, buffer sizes and hardware all create combinations to test, ideally across clean machines and different setups.
• Revisions. There will be feedback and changes. They’re much cheaper to make early than when everything else has been built around them.
• Ongoing maintenance. Operating systems and DAWs keep changing. If you keep selling the plugin, someone needs to keep it working. And then there are the feature requests – some of which you may want to build!

Deciding where the money goes

There’s another part of this that has changed quite dramatically over the years – what people expect to pay for software.

Earlier in my career, I worked on virtual instruments that took years to develop. There might be several developers involved, alongside product specialists, UI/UX designers, QA and sound designers. Development budgets could easily run well into six figures.

But the finished instrument might sell for $299 and have a multi-year lifecycle between updates.

Today, customers are used to seeing sophisticated plugins selling for far less, and often heavily discounted. Development is faster in plenty of ways too, but a commercial product still needs to be designed, built, tested, packaged, marketed and supported.

If something that might once have sold for $299 is now expected to sell for $79, the numbers have to work differently.

Development effort doesn’t always map neatly to customer value either. You can spend weeks perfecting something that barely gets noticed, while a relatively simple feature ends up being the thing people love about the product.

So you have to decide what matters.

What will people pay for your plugin? How many people are likely to want it? Do you already have an audience, or will you need to build one?

Then decide where the money goes. Maybe the DSP is what makes the plugin special, so that’s where you spend. Maybe the interface can stay simple. Maybe you start with a focused first release and build on it once you know what people actually value.

We recently went through exactly this exercise with a prospective client: what’s the least expensive plugin we could make that would still be genuinely relevant to their audience?

We got it down to a matter of days of development: one clear job, a minimal interface and nothing it didn’t actually need.

That kind of focus often makes for a better plugin, too.

The one thing a small plugin can’t skip is a reason to exist. There are a lot of plugins out there. Maybe yours looks different, sounds different, or fixes an annoying problem people have been putting up with for years.

And sometimes you look at all the numbers, decide they don’t really add up, and make it anyway because you just really want it to exist.

Most of us working in this industry are here because we genuinely love it. We make music, obsess over sounds and build things we want to use ourselves.

The point is to understand the numbers, then decide what you want to do with them.

How to get an accurate quote for your plugin

You don’t need a finished specification before you talk to a developer or agency.

However, it definitely helps to know:

• what the plugin does, and who it’s for
• anything already out there that’s similar to what you have in mind
• which formats and platforms you need
• when you’d like to launch
• roughly what you’re comfortable spending

And if you’ve already made something, share it.

An Ableton rack or effects chain that gets somewhere near the sound, a prototype you’ve vibe coded, UI sketches with a feature list – none of it needs to be polished. Quite often, something rough tells us much more about what you have in your head than another page of written description.

If you’re using an AI agent to help write up your spec, make sure it hasn’t helpfully invented extra features you don’t actually want!

A rough budget is helpful too. There are often several ways to approach the same idea, and knowing what you’re comfortable spending helps us shape the right version of it.

From there, you should usually be able to get an indicative range after a first conversation and firm it up as the scope develops.

And whoever you work with, experience matters. Building the plugin itself is only part of getting a commercial product out of the door. It helps to work with people who have designed, built, tested and shipped plugins before, and know where the work actually goes.

That’s certainly part of what we bring at The Audio Programmer. If you have an idea you’d like to explore, get in touch. We’re happy to talk it through.

‍