Seeking advice on choosing JUCE developer

I have a concept for an innovative audio plugin (VSTi) and I’m in the process of hiring a JUCE developer to build it. It’s rather complex. The guy I’m considering seems has experience with software development, but is still learning the ins and outs of JUCE. In other words, he has no examples to show me as to how well he would fare using JUCE, particularly with this project.

Is it reasonable to expect a developer who has never done anything substantial with JUCE to be able to develop a large project with JUCE? Can it be a learn-as-you-go situation, or should the programmer already have numerous JUCE projects under their belt first?

It depends! Here are a few things I would be thinking about…

First and foremost, the budget. Are you paying this developer for their time? If so, normally a complex VST instrument done properly would require a sizable budget (5 figures and up depending on the spec).

If you have this type of budget and are paying them an hourly or daily rate, then it needs to be considered that there’s going to be a significant amount of time they’re going to be dedicating to learning to use JUCE. There’s a balance here because every project is going to have its share of unique challenges and need for research, so just because a person hasn’t developed product x doesn’t mean they aren’t capable.

Now, the problem here is that most people don’t have that type of budget. This means that agreements need to get more creative, and you can work out an agreement where you pay a reduced rate in exchange for a partnership. It sounds like there could be risk for both sides - the dev needs to learn JUCE and you need a product, and if you do a royalty split on the product, it’s a win for everyone.

Second is the communication. Do you get along with this person and do they understand and agree with your vision for the product?

Third is realistic expectations. Many people mistakenly believe that one audio developer can deliver a product from start to finish and that’s not the case. You have so many considerations depending on the product - digital signal processing (DSP), user interface (UI), user experience (UX), graphic design, product vision, security, architecture and so on. It’s RARE to find one person who has a great understanding of all the areas you’ll need to create a complete project. I’ve seen many people lean heavily on developers to understand what the customer wants or expects. I think that’s a lot to expect out of one person. Most times, building a successful plug-in of relative complexity is a multidisciplinary pursuit that involves a team.

I hope this helps!


Super helpful! Thanks!

thanks for the awesome information.

In addition to the excellent points by @theaudioprogrammer it’s also worth taking into account how closely the programmer’s experience maps onto audio plugins and JUCE. A large portion of plugin dev is UI. A C++ programmer with substantial experience with a comparable framework (Qt for example) is going to become productive with JUCE much more quickly than someone who has mainly worked on system libraries, for example.

So even if they have no examples of JUCE projects, I would look for examples of projects that involve solving similar types of problems (managing communications between UI and backend, handling state, multi-threading etc). For me, understanding the problem domain and the approaches to solutions is probably more important than knowledge of a particular framework.


i’m on the other side. almost no programming experience except for JUCE, and i’d say JUCE is easily understandable. basic ideas can be laid out quickly with it. but there are a lot of edge cases and platform-specific bugs that can happen in the process of bigger things, where it’s probably useful to have encountered some of them already. i have a friend who didn’t have JUCE experience, but many years of c++ experience already, and still made a huge plugin in just some months though, bigger than everything i ever made yet. so apparently that is a more than valid way to get into it, too.

1 Like

This is a BIG topic. Background: my bread-on-the-table gig is advising and consulting on software acquisitions and doing diligence on companies receiving investment from private equity, so this is my field. I can at least give you some things to think about briefly.

You have four things here you want from your dev. Which are most important depends on your project: its goals, scope, duration, complexity, and how you want it to do business.

  1. Experience with JUCE
  2. Experience with C++ development
  3. Experience with audio development
  4. Experience being a software consultant/dev shop

For a small, simple project, the beginning of the list is most important, and as the project gets bigger, more complex, and expensive, the end of the list is most important, with 2 & 3 ranking against each other differently depending on the specs. Ideally, and for any substantial project, you find a team with all of these, and that team is 2+ people, even if it’s 1 person and their junior helper. Better if is they work well together but both work for you. (You need truck number > 1, seriously.)

Finding the right person/team is super important, as is the relationship and type of business arrangement you have with them. If your person checks out well on 2-4, and you will be in this for the long haul, the time they need to learn JUCE (assuming professional level C++ chops) is the least of your concerns. If you’re planning on making a business of this, you’re basically starting a micro-startup and it would be wise to read widely on the business side of tech startups - it’s a very easy place to lose money if you aren’t careful.