Hi! My name is Nathan Tiddy, I'm 26 years old and I live and work on my parents goat farm in New Zealand. Farmer you say? What's a farmer doing on Indie Hackers?? Well before late last year I would have asked myself the same question!
Farming isn't the only thing I've done. Before this I spent 5 years living and working in cities as a recording engineer. In late 2015 this interest in producing music led me down a path to developing my own tool to help with the recording process.
menuBUS is an application that lets you process all of the sound that your Mac produces, before it goes to the speakers. This lets you do things like equalize your speakers to better match your room, boost the volume of the movie you are watching, or add bass to your headphones for more thump. menuBUS isn't the first app to do this — if you use a Mac you've probably heard of Audio Hijack, or Boom; but menuBUS is the first app that does this and lives in the menu bar to get out of your way.
It is designed with the professional audio engineer in mind, but any Mac user that uses audio could find utility from menuBUS.
menuBUS started out as a simple app that I was building for myself. After building it I thought I could sell it for $5, but as I added more features and saw its popularity rise during the month it was in public beta, I ended up settling on a price of $40 USD.
This sounds like a lot for a simple menu bar app, but for many professionals who spend upwards of $200 for the plugins menuBUS hosts, $40 isn't much.
As I am writing this in mid January 2018, after being on sale for nearly a year, menuBUS has earned me $12,000 USD, and after the initial bump you often get at the start, I'm happy to report that menuBUS has pretty steady sales, averaging around $1,000 a month.
You can see by the chart that after the initial spike after release, sales have been pretty consistent.
I came up with the idea for menuBUS after downloading a piece of software called Sonarworks Reference 3.
Sonarworks is an amazing plugin for the Digital Audio Workstation (DAW). It takes a calibrated measurement of your speakers in your room and applies a tailored correction curve so that all the audio passing through the plugin is adjusted to sound completely neutral once is comes out of your speakers. When you are mixing and mastering music, the speakers and room have a big impact on how something sounds. It's important to remove those distortions so that something sounds great on someones iPhone, in their car, and on their Hi-Fi stereo.
The one problem with this plugin was that it only worked on the recording workstation. I wanted this correction to be over every app. Not just my recording software, but also iTunes and Safari.
At the time, a quick Google search would lead you to two possible solutions to the problem. One of them was to use a piece of software called Audio Hijack, and the other was to use a combination of Apple's free "AU Lab" and the open source virtual audio device "SoundFlower".
The AULab + Soundflower combo worked OK and showed me this was a real possibility, and the Audio Hijack approach was super slick but felt a little heavyweight for something I wanted to be running all the time.
I knew that the ideal app for me would need to be easily accessible, but not in the way. I'm a fan of menu bar apps for exactly this reason.
I had the idea, but now I needed to learn to code. The idea of learning to program was very daunting, but fortunately I got put onto a piece of software called maxMSP by a programmer friend of mine. It was really intuitive for me to get started and use. Thanks to maxMSP's visual programming environment it only took me a couple of hours to build out a working app. It did almost everything I wanted, barring a few critical things.
At this point I'm only tying to solve this problem for myself — no intention at all of making this for anyone else, but this just bothered me, and by this point I'd caught the programming bug!
With a working app idea I was now less intimidated by the idea of coding, so I dug in, downloaded Xcode and started to learn Swift.
When I wasn't outside on the farm, I was inside hacking in Swift. I started by downloading and extending functionality of example applications I found on GitHub. Sometimes I would face a problem that seemed too hard to solve. This happened a lot when I started having to work with the low level C API's of Core Audio, and often I would just give up on the project for a month. I found that any time I came back to Xcode after a big break, I had renewed energy to solve the problem, and to keep learning.
So after months of backward and forwards I had built a Mac menubar app that interfaced with Core Audio and let me run plugins, just like I wanted!
The launch of menuBUS was a great success. I announced the beta of menuBUS on Gearslutz, a pro audio forum. The download link on my website required an email before downloading, and after a month I had over 1,000 emails from people who had downloaded the beta to try. I was open with everyone on the forum participating in the beta that there would be a significant discount for helping me out with testing.
When it came time to put menuBUS on sale I had a bunch of emails and a thriving Gearslutz thread which meant that I sold 250 copies in the first week. I launched menuBUS at half price for a week, so this really encouraged people to jump on and buy the app.
menuBUS has attracted people all on its own. All the income I have earned to date has mostly come through that one forum post I wrote in February announcing the app, and the rest of my sales have come via word of mouth or people writing about it on social media.
I know I could and should do way way more here, but I've focused on being very attentive to that forum thread, fast to respond to support emails, and continuously fixing bugs and building out features of the app.
I've had three pricing models since launching menuBUS:
1. menuBUS
At first I went for a very basic model with menuBUS. I had it available as a 14 day free trial, with a $40 ticket price at the end of that.
I saw pretty great success with this simple model.
2. menuBUS + menuBUS lite
Around 3 months into sales I decided to make a more stripped back version of menuBUS, called menuBUS lite. My goal with menuBUS lite was to capture more of the casual market, the people who like the concept of menuBUS, but only needed something with a more basic feature set.
3. menuBUS Pro V2 and the discontinuation of 'lite'
I wouldn't say 'lite' was a failed idea, but with the launch of the menuBUS v2 I decided to stop selling it, as I wanted to reduce the purchasing decisions a potential customer needed to make.
At the time of pulling lite, it was only selling around 5 copies a month, and I couldn't help but wonder if those 5 copies might have become the full $40 if I had never given the option.
So in October last year I launched version 2, increased price to $55, pulled lite, and at the same time gave people an even more stripped back, but totally free forever version of menuBUS.
If I look back over these three distinct periods of menuBUS, nothing major changed in regards to sales. It always seemed to wash out with me making around $1000 a month. Nice pocket money, and maybe enough to support me if I lived in Thailand, and didn't have a family to support, but ultimately I'm still sitting here at the end of the year knowing there's so much more potential for this app.
I have dabbled a little bit in Google AdWords and Facebook placements. I didn't get any direct sales from these efforts, and It became hard to justify the expense. I started my advertising testing in December, and December was my lowest earnings to date! If you take the cost of advertising into account, I basically came away with nothing in December :(
So what are my plans for the coming year?
The biggest challenge and probably my biggest mistake was building menuBUS using Swift for low level audio processing.
Swift is great, don’t get me wrong — It’s what helped me learn to program! But when it came to putting menuBUS into the wild I faced so many problems with buffer overruns. I was getting emails from customers daily complaining about clicks and pops in their audio. It was a nightmare.
When interfacing with CoreAudio you are given a very high priority thread in the form of a callback that supplies your app with an audio buffer. If you do anything to block this thread, or if you are naive enough to use Swift to interface with this callback, you are going to have a bad time…
Something fortunate happened though. About 3 months into menuBUS being on sale, a customer of mine contacted me with a few gripes regarding the audio quality of menuBUS, and he said that if I took the time to convert all my audio processing code to C++, then he would be willing to look over my code and help make the performance optimisations required. This man was my saviour! Thank you Daryl Fortney!!
Since converting this code to C++, working on menuBUS became a dream. The interface is still written in Swift, but where it really counts the code is now super performant.
The biggest advantages I had with this app was my experience as an audio engineer and the knowledge of the audio community.
My experience as an audio engineer is what gave me the idea in the first place, and because I knew the community, when it came time to release this product, I knew exactly where I would push the news first, because that’s the exact same place I had got all my news from over the years.
I should also add, that another major advantage has been the passionate user base that have stuck with me through some pretty rough moments in development, especially in the case of that one user — Daryl Fortney, who really pulled me out from the deep end!
Start. Stop when it gets hard. Start again.
You can learn more about my app at menubus.audio. Follow me on twitter @nathan_tiddy. Or like menuBUS on Facebook.
I'd love to answer any questions you hackers have!