Indie VST Developer Expectations

I think PACE don’t show pricing because they tend to setup custom deals dependant on the arrangement with them, there’s just too many variables for them to have a set price for everything.

What do you mean by meat and potatoes? GarageBand and others tries to make it accessible, but at some point the folks want to advance to the same power tools that the professionals use, and then it’s hard, and indeed it is catered to professionals, by definition. But isn’t it like that in any field? It’s also hard to transition from Excel to C++.

When I was in uni studying IT, there was a class called Human Computer Interfaces or something like that. It was all about the art and science of increasing the intuitiveness of apps. It’s a mix of design, psychology and other fields. And a guy gave a talk about this at the JUCE conference in 2017.

But I don’t see many people adopting this philosophy. And it doesn’t make sense. We know that most plugins don’t sell very well, so a new developer has nothing to lose in trying to be innovative. But instead the common philosophy is to just copy other designs that have sold well before.

This idea that we have a binary choice between beginners tools and expert tools is just not true. There’s a lot of room in between.


This idea that we have a binary choice between beginners tools and expert tools is just not true. There’s a lot of room in between.

This is true. Although I think most released music is made using “expert” DAWS and tools, there have also been entire genres spawned from people making music with “beginners” tools. For example, Grime was born from people making beats on their Playstations with Music 2000; Lots of the guys making early dubstep were using Reason and Fruity Loops (they often had good mastering engineers doing the final push and polish!)

1 Like

@ncthom Thank you so much for continuing to come back to the forum with updates and replies. They have been very helpful to read!

Also, the video was awesome and I had one follow-up question from it.

What do you think about getting started in the indie plugin business with a partner or two? Surely, you won’t make as much as doing it alone because you have to split revenue, but maybe the encouragement and accountability of a passionate team might expedite the process. What might have been different for you if you started your business with a small group of people that you loved to work with?

1 Like

Hey, cheers, really glad to hear it’s been helpful!

Great question… considering that I didn’t go the route of a small team, there are definitely some unknowns here for me. For example, if it takes a few years to develop a reasonable revenue stream for a solo dev, maybe it takes longer to develop a reasonable revenue stream for each member of a team. Or maybe it takes less time because of the increased productivity. Similarly, I think making a plugin can be a pretty creative/artistic endeavor, so maybe if your team aligns well behind a single, shared creative vision then I imagine that’s a huge win, and if not, potentially a hindrance (or if you’re part of a team and you aren’t aligned on the creative vision you might not feel very invested).

But on that I can only really speculate. I can say a few things that I think would be clear wins, based on my own experiences trying to do stuff mostly solo. First, as I said in my talk, there’s a ton of different hats that you have to wear to get a new business into the game with a new product. For me, the context switch between those hats turned out to be pretty costly (i.e. if I spend a morning writing code and try to write a blog post that afternoon, sometimes my brain just doesn’t come with me, and I lose time). I think that’s generally the case as well, but the more hats you wear, the more frequently you make that switch, and I think sharing some of those responsibilities means paying the context switch price less often. Second, when you’re trying to run the show yourself, any day that you don’t make good progress hurts… it’s like if you have an off day then your entire company has an off day, and that’s a lot of pressure. I’ve been on several teams in the past and I’ve realized now that it’s a nice feeling to be able to have an off day but still see your team making strides.

At the end of the day, my personal goal is to get my company to a point where it can sustain a small, closely invested team, just because I think that will be the most fun and fulfilling form that my project can take. Of course your own viewpoint depends on your own wants/needs/goals :slight_smile:


The point about context switching is important. In the last 9 months I’ve had some crazy times with overlapping projects (mainly due to underestimating!), and the context switching between projects, project/client management, estimating, keeping track of time spent vs client budget, plus trying to make time to develop my own products has been exhausting.

1 Like

Contexting switching is a good point, however I don’t think this really goes away until your company is quite large. If you’re still a multi-person but small company you’ll probably have to deal with support, forums, website, graphics, marketing, distributors, testers, NFR requests, content, sound design etc. even before you’ve got to your code.

And then code has many different hats depending if you’re doing your actual product, your own libraries, 3rd party libraries, UI, real-time, platform specific, other languages, build systems, server-side stuff (maybe for authorisation, update checkers or download manager) etc.

I guess my point is context switching is an inevitable part of small to medium scale development which is most of the audio dev industry. If I can get 3+ hours working on a single thing it’s bliss!



Definitely agree. I suspect also though that the marginal returns are pretty significant for the first few hires– by which I mean that if I have N responsibilities when solo and can entirely delegate M of them when my team moves from 1 person to 2 people, I would imagine that has a very noticeable impact, even if it doesn’t eliminate the cost of context switching completely.

1 Like

Totally agree. The other thing that’s very difficult to quantify but very significant is how beneficial it can be to have someone else to either bounce ideas off or simply share knowledge with.

One team member can be stuck on something for hours simply because there’s a small gap in their knowledge that someone else could have the answer for immediately. This isn’t limited to junior or inexperienced developers, knowledge sharing goes on forever.


If there’s a fairly steady support workload then the ability to take a couple of weeks of holiday without inconveniencing customers is very welcome!

1 Like

Two weeks of unattended KVR :exploding_head:


Do you have any names of Resellers with good reputations?

1 Like

I’m going on 8 months of unattended KVR, with no ill effects.