How did you grow from POC to mature product and company?

[nlaroche]

I’m curious to hear about people’s experience who have started projects in JUCE and taken them to the finish line and beyond. It will soon be 1 full year since I’ve had my own idea and managed to develop it, but there’s really so many aspects to figure out and put in place it’s quite dizzying. For example, I’m learning the hard way that I should have started better defensive coding earlier and have implemented much better local logging as the random combination of DAW/System/Soundcard/etc. that users have really cause everything to go wrong that it should.

1. How have you managed your QA process without having to spend crazy money on every flavour of DAW in order to test properly?
2. What are some of the unexpected pitfalls you guys have run into, and how have you gotten over them?
3. Have you realized at some point you were lacking some of the skills necessary to complete your vision - what were they?
4. What would you do differently if you were restarting?

I’m of course very curious for the business side of things such as how did you grow and maintain your user base, funding, etc. but since this is a development forum lets stick to JUCE development related items - I think the responses could be interesting and enlightening for all of us!

[adamwilson]

Bumping this post as the subject is also relevant to me and my product development.

[lcapozzi]

There are many factors, but you NEED to spend a lot of money to get things done. You don’t have to spend them all of a sudden, but these are necessary steps to grow.

To answer your questions:

1. Most DAW companies will provide NFR licenses of their DAWs to developers. It’s important that you already have a little brand with products out, otherwise it’ll be a long shot to get the NFRs.

2. When a product you spent lots of time and money won’t sell as expected. It hurts, but it’s important to learn how to manage your feelings on these kind of episodes, otherwise you won’t find the energy to keep going on.

3. Every day! I try to learn something new every day and to do so, you have to schedule a study time. Once of my lacks, years ago, was for the GUIs. I wanted realistic interfaces, but the available graphic designers where too expensive for me back then. So, I decided to learn how to work with 3D modeling, dedicating 1h per day every day. I started with simple things and now I do all the GUIs in 3D.

4. Honestly, almost nothing. My past mistakes are as much valuable as my accomplished goals. Maybe I would convince myself to go back coding C++ few years earlier than I actually went.

About the business side… it’ll take too much time to talk about it, but the most important thing you can own is a well maintained newsletter.

My 2 cents!
Cheers

[anthony-nicholls]

@nlaroche

1. How have you managed your QA process without having to spend crazy money on every flavour of DAW to test properly?

As already mentioned you should be able to get NFRs by contacting each manufacturer. Also, I would initially suggest testing in a select few DAWs.

For VST3 use Cubase (you shouldn’t need to worry about VST2 if you’re developing a new plugin)
For AU use Logic - If you can’t get it free consider GarageBand, and AULab - additionally use auval
For AAX, obviously use ProTools - however, it might be worth considering leaving AAX development until after you have released a VST and AU as you have the extra steps to overcome with signing.

Other notable mentions.
Reaper has good support for just about everything and lots of options to simulate all sorts of situations. I would probably use the demo version of this if I couldn’t access anything else.
pluginval should help reduce the risk of risky behaviour.
Ableton might be one to check out depending on your style of plugin
Studio One is pretty popular in some regions
If you manage to get an NFR for Logic also be sure to ask for one for Final Cut, although you may have fewer users using this it’s a great stress test due to the way it treats plugins. Every time you change a parameter it will launch several instances of your plugin on multiple threads to generate some waveforms.

@nlaroche

2. What are some of the unexpected pitfalls you guys have run into, and how have you gotten over them?

Final cut as mentioned above.
Consider what happens when the plugin is not running in realtime such as an offline bounce.
Avoid static variables if possible - these will be shared between instances for DAWs that don’t load the plugin in separate processes, but not for those that do (you can change settings in Reaper to test the different cases). There are cases when a static variable is useful, just give it careful consideration.
Avoid modal dialogs, actually, avoid all dialogs they are easily missed by users!
Any type of copy protection that impacts the sound can be a pain for users as it can be hard to know which plugin is the problem when opening an old DAW session. Consider disabling the GUI only.
Concentrate on delivering value to the user rather than too much copy protection, it’s extremely time-consuming!
However, adding new features to a plugin is hard it often means breaking backwards compatibility. Consider what happens when someone is using the latest and greatest version and they open an old session, or what about when they share the session with someone on an older system that is unable to update to your latest and greatest version.

I’ve only worked for existing companies so I’m not sure the other points are ones I can help with as much. Hope the above helps though.

[ImJimmi]

@nlaroche

How have you managed your QA process without having to spend crazy money on every flavour of DAW in order to test properly?

I test my products with Reaper on windows and Logic on Mac, I test with pluginval as part of my CI to catch any common issues. I very very rarely have any bug reports specific to certain DAWs so I wouldn’t worry too much about that.

@nlaroche

What are some of the unexpected pitfalls you guys have run into, and how have you gotten over them?

There’s a lot more to it than just writing some plugins in C++.

• Testing.
• Building installers.
• Writing documentation.
• Testing.
• Building a website to host your products.
• Contacting influencers to do reviews.
• Testing.
• Other marketing.

Writing the actual code is only about 50% of the job.

@nlaroche

Have you realized at some point you were lacking some of the skills necessary to complete your vision - what were they?

There are a lot of extra skills involved other than just programming (see above) so you’ll learn a lot of stuff along the way.

@nlaroche

What would you do differently if you were restarting?

Start simple. Just try to get one decent, stable, well received product out there and to start getting some attention to your name and then build from there. I had 3 plugins released within my first year of trading and it quickly became too much to manage. I was still learning in the process and when I realised I’d made a silly mistake in my code I then had to go and fix the same mistake in multiple places across 3 projects. Not fun.

@nlaroche

I’m of course very curious for the business side of things such as how did you grow and maintain your user base, funding, etc.

If you do literally everything yourself then the only costs will be your own living costs. In terms of growing a user base I can’t stress enough how important marketing is. I had a YouTuber with around 100k subscribers post a review (and not even a very positive review) of one of my products and made more money in the following 2 days as I had in the previous 18 months combined.

[pstitt01]

@anthony-nicholls

For VST3 use Cubase (you shouldn’t need to worry about VST2 if you’re developing a new plugin)

Is there any particular contact at Steinberg worth contacting to request this? With Avid it was very clear what to do to request NFRs but I don’t see anything but generic contacts for Steinberg. I’m sure I am probably missing something.

[anthony-nicholls]

To be honest any company I’ve ever worked for has already had a contact. However my first call would probably be to jump on the forums Developer - Steinberg Forums.

[Verbonaut]

If you can’t easily get an NFR, remember to check out the base versions of these DAWs as usually they’re pretty low cost and will do all you need for testing purposes.

[anthony-nicholls]

Just to add to this another surprise I’ve had over the years is the complexity around bypassing!

Ask yourself these questions.

Should bypassing be glitch free?
Should bypassing maintain the plugin latency?
Should bypassing free up processing resources?
Bonus question, should bypassing maintain a perceivable level?

Why do I ask this? because different DAWs have different ideas.

Most DAWs include two concepts.
Normally bypass is glitch free and maintains the same latency.
Additionally there is often an option to enable/disable the plugin to free up its resources.

However some DAWs have only one of these.

Most plugin formats have a way to either announce a bypass parameter or link to a bypass parameter. However not all DAWs pay attention to this. VST2 is a bit of an odd one out that makes things very difficult.

As a result in a plugin it’s often good to offer a glitch free latency maintaining bypass and link it to the host bypass where-ever possible.

Logic is possibly the worse culprit as AU offers a way to link to a host bypass but Logic doesn’t implement it. It does however have a bypass parameter which acts more like an enable/disable (it’s not glitch free and does free processing resources).

You may also want to consider if bypassing your plugin should maintain consistent processing, this can reduce sudden processing spikes that can lead to unintentional glitches.

For me this is a topic that when I first started I had no idea had so many hidden complexities, it seems so simple from the user perspective.

To be fair after the JUCE team have implemented a way to report a bypass parameter which should help in most cases, I highly recommend you implement a bypass parameter and implement the function to indicate which parameter it is.

I would also warn against implementing your own preset manager in a plugin, it’s doable but it’s another one in which you have to think carefully about different DAWs and plugin formats. How does it work with session saves and host presets (you’ll have a hard time telling the difference between the two).

[gustav-scholda]

I’ve implemented a preset system and had no problem so far. Or are you just advising against ut because the user could get confused?

[jellebakker]

I wonder when do you choose to delegate and when do you try to learn things yourself. There is lots of stuff involved with product development like design, marketing, webshop, legal and much more that might not be within the skillset of an average plug-in developer. Should you pay someone for all of that, should you partner up, or do it yourself? A young company might not have the resources to pay for that. I’m interested in experience of others.

[connorreviere]

A very interesting question that I’m sure has many different, but equally valid answers!

Obviously budget is a huge factor. If you have limited resources for outsourcing, you’re going to need to be versatile.

In general, though, I like the typical startup advice: Figure out your “core competency” as a person/team/company, and outsource as much of everything else as possible. If you have a team of signal processing wizards who don’t know much about UI/UX, there’s no sense in having them design a modest UI when outsourcing that would allow the valuable signal processing work they did to shine more brightly!

There are a few things (like legal matters) that you should always outsource to a professional, imo.