Tell us about yourself and what you're working on.
My name is Jason, and I like music and coding. I was born in South Africa and moved to California just before the start of high school, graduating from the University of California, San Diego in 2007 before working a corporate job in DC that ultimately landed me a sweet gig at Google. My responsibility once there was to figure out how much to pay the company's executives, which meant I was lucky to enjoy face time with many of the top brass.
While in DC, I kicked off a music blog called Indie Shuffle (as a hobby). I quickly became hooked on the "game" of generating more visits, and in the process started to teach myself the fundamentals of front-end development. By the time 2013 rolled around, the blog had become a full-fledged online publishing company, and I was ready to make it my main focus.
How'd you get started with SubmitHub?
One of the biggest frustrations of running my music blog was that by the time I took it full-time, I was receiving upwards of 300 email pitches a day from artists, record labels, and publicists, all looking to have their music featured on Indie Shuffle. After a while I simply started ignoring them, though I knew in the back of my head that there had to be a better way.
Then, toward the end of last year, I decided that a good way to learn some new coding languages would be to try and solve this problem by developing a website to streamline the process. And thus, SubmitHub was born.
The idea was simple: interested parties could send their songs (SoundCloud or YouTube) to Indie Shuffle on SubmitHub. We would then receive the submissions in a consistent feed from which we could either give it a "thumbs up" or "thumbs down" — the former meant that we were planning to blog it; the latter meant that we weren't interested. In the back of my head, I figured it might be possible to one day charge a small fee in exchange for a few words about why we weren't interested. (e.g. "You can't sing in tune.")
At the time, my main focus was on solving my own problem. I hadn't given much consideration to the thousands of other music blogs who might want to use it. I suppose in that sense I was lucky: I was already "part of the problem", and therefore had a good understanding of what was needed to "solve" it.
What did it take to build SubmitHub?
I chose Meteor and ReactJS to build the initial prototype, investing roughly eight hours a day (including weekends) over the course of one month, and allotting an additional ~2 hours to the upkeep of Indie Shuffle (which was keeping me afloat financially). It was a lot of effort, but as one often does, I became "obsessed" with the project and couldn't stop working on it.
For a long time now I've been a big fan of "launch and iterate" (i.e. I'm impatient), so once the bare fundamentals of the project were working (send a song; make a decision regarding that song), I put it online and began funneling some of the ~300 emails a day I was getting in its direction.
How did you start getting users for SubmitHub?
I always knew I was sitting on a great source of users with the ~300 daily emails, and sure enough, as soon as I started pointing them to SubmitHub they latched on. The value was clear: whereas before they were shooting their emails into an empty void from which they heard no response, they were now getting a response every single time they reached us. Even if the decision was a "thumbs down", at least they knew.
Given Indie Shuffle's prominence in the digital music industry, word spread fast. Before I knew it, roughly ten other blogs had reached out asking if they could use the platform to streamline their submissions as well. And, given that Meteor is such a fast and flexible environment to code in, it took me virtually no time to "expand" the product to facilitate their arrival.
More blogs using the platform meant more users being sent its way, and more users being sent its way meant that more blogs learned about the platform. And so the loop was closed and the snowball began to gather size and strength. This rapid growth led me to "phase 2" of the project: how to generate revenue for myself and the other blogs using it.
What's the story behind your revenue?
Over the course of my ~7 years running a blog, I had learned a few things about what folks were looking for when they sent music to blogs:
- a quick response
- a decision about whether it was worthy of being blogged
- and, if not, some detail as to what needed improvement
Therein lied the business model: by paying a small amount ($1), SubmitHub would be able to guarantee that all three of the aforementioned boxes were checked. If not, the user would receive a refund.
I decided to use a "credits" system (virtual currency) whereby one credit ($1) would allow you to send a "premium" submission to one blog; ten credits ($9) would let you send your song to ten blogs. If only eight of them responded within the allotted time (48 hours), you'd get two credits back that you could use to send your music to other blogs. The blogs, meanwhile, would get a flat $0.50 USD per submission that they responded to.
The payments processing was one of the harder projects I've coded. I chose to use Braintree, primarily for their support of PayPal. While their API was pretty straightforward, I struggled with the server-side async requests that had to be made from Meteor. It took me roughly a week to get it up and running, but once I did I found myself quite surprised at how smoothly it worked (and grateful that I was consistently backing up to GitHub — there's no way I'd want to code all that again!).
When I launched the "premium" system on the site in February, the uptick was almost immediate. Where a traditional publicist can cost thousands of dollars, musicians were now able to reach a blog like Indie Shuffle and get an actual, human response for only $1 (or less, if they bought credits in bulk). Clearly the model had legs.
Flash forward eight months, and the growth hasn't slowed. There are now ~135 blogs and ~90 record labels actively sifting through submissions on the site. Last week alone, more than 17,000 premium credits were used to send music, meaning a potential payout of $8,500 for the bloggers and labels.
Get a Beautiful Mockup. No Photoshop required!
Choose from 5000+ templates.
What are your goals for the future?
While there are ways to differentiate the pricing model, I like to operate under the KISS principle: keep it simple, stupid. I've recently brought on someone to help run the company's financials (a CFO, if you will), and one of his first questions was around increasing the cost of credits with an eye for increased earnings. I confess: I hadn't really been thinking that way. From my perspective, a simple $1 per credit is part of the reason people find value in the site: it's a straightforward and easy-to-swallow pricing model.
Instead, I think that there are three things that are core to the success of the business:
- having more blogs, labels and playlisters sign up
- keeping the platform fast, responsive, and constantly improving to fit the needs of its users
- fostering a community and avoiding the "trap" of becoming a company with no human touch
If I hit my goals on those three, I'm confident that revenue will grow.
Oh, and then there's the obvious path of expansion: applying this same model to different industries.
If you had to start over, what would you do differently?
Nothing, actually! I learned a lot while running Indie Shuffle, and I feel like that knowledge has allowed me to grow SubmitHub without incident from the get-go. At this point, I think my main focus needs to be on growth.
What have been your biggest advantages?
As mentioned before, being "part of the problem" provided the best advantage possible. There were a few competitors trying to solve similar problems, but none of them were actually part of the equation. As such, they struggled to convince others to sign up, and didn't have a steady funnel of users to push their way.
What advice would you share with aspiring indie hackers?
Launch and iterate! Don't delay! I've seen a number of startups try to build the perfect product before launching, rather than putting something out there and adapting to the needs of its users. My experience has been that building a platform around real-life, participating users is much more valuable than trying to guess what they'll need before you've even put the product out there.
Where can readers learn more?
One very important lesson that I learned at Google was that it's easier to respond to your emails straight away than it is to sit on them. In that vein, if you ever want to chat, you can reach me at email@example.com and I'm pretty much guaranteed to respond within 24 hours — often quicker :)
You can also reach me below in the comments: