blakerson.com

This post is much more in the startup tradition of analyzing where things went right and wrong, for anyone who might be interested. There is some business discussion, but it's primarily technical in nature.

My time on Musivu comes with 5 main lessons:

The primary cause of death for Musivu was the education market. The always-intelligent Patrick McKenzie frequently discourages would-be entrepreneurs from going into the education market. He is correct.

Whether you sell to students, parents, or teachers, you are always selling to someone who is strapped for cash and, on average, a low level of technical sophistication. 

Our best customers were those who were none of the above: they were adult hobbyists or retirees who wanted to get back in touch with music. 

Going after teachers was a terrible idea and a particularly lethal trap for our attention. Teachers loved the idea of the site, and they loved Kris's ability to speak to the educational benefits of assigning video lectures and using class time for discussion and time on the piano. The catch: none (OK, literally one) had the wherewithal to formally assign us. "The deal" always died at some administrative level above the teacher. 

Does your idea have any audience?

This is why Microconf speakers frequently talk about starting an idea as a Wordpress plugin or as an add-on in an established ecosystem such as Salesforce or Shopify. 

One of the things we did very right was to test by putting a course on Udemy to test the waters. They had a captive audience, a Music section just getting off the ground, and a need for high-quality music content. 

Our early Udemy revenue was so substantial that it funded our early development of our first subscription site, as well as our most ambitious marketing moves that we'd ever undertake. (This was a fluke with early Udemy circa early 2013 - this is now highly unlikely under their model in use since 2014.)

Content libraries have certain advantages. As Jason Cohen put it in 2013, a content site can be "done" and then be left to run on autopilot.

Our content was video, and video is tricky to do on the cheap. Musivu came up at the same time that YouTube morphed from "video depository" to "cultural phenomenon" and the bar for good video went from a webcam to rigs more in common with professional setups.

The differences in lighting between our first and last videos were telling, especially in terms of resolution and lighting. But we never went to the trouble to reshoot our earliest videos, despite those having the widest audiences. 

This probably kept our visit-to-trial and trial-to-paid conversion rates lower than potential.

Another thing left undone was to hire a video consultant to help us establish solid technique for videos that would last a few years without looking dated. For a typical online teacher who does one course lasting about 5 hours, a reshoot is feasible in terms of schedule and workload. For us, the video library spanned a couple hundred hours of finished footage - much harder to reshoot, edit and upload. 

Our first home-grown subscription site (we called it Subscription 1.0) was a hand-written Rails app where the paywall just barely worked, then served up a static page with the link to each lesson, and a simple view for each video in sequence.

This was a wonderfully simple system - our server bill was $7 for the smallest persistent Heroku instance. 

But once Kris and I agreed that "classes" and "quizzes" and "scoring" needed to be among the feature set, it was time to re-examine our architecture. It turned out that the technology we wanted was a Learning Management System, or LMS. In 2014, this was not exactly well fleshed out in the Rails ecosystem.

I had gotten 1.0 shipped on my own, but didn't have the programming skill to write a LMS. Speccing this out and hiring out our external engineer David to handle it would have been extremely costly - following my back of the envelope calculation, thousands of dollars. More than we could realistically spend.

Amazingly, the feature was done over in Wordpress world, in the form of Sensei, and cost a mere $130. The great thing about WooCommerce plugins is that they're insane value for money. All in for plugins, we spent less than $500 a year on software and never had to hire a custom coder. 

The Hacker News crowd might mock the Wordpress ecosystem, but very, very few small software startups need the performance differential between Node.JS and a well-run Wordpress site on a CDN. Wordpress is "slow" compared to the modern software frameworks, but guess how many customers ever called our site slow? 

After discovering Sensei for our LMS purposes, it was almost inevitable that we'd migrate to Wordpress. This would become Subscription 2.0.

It turns out, there is one correct way to run a Wordpress site that collects money. 

There are many incorrect ways:

• Trying to run Wordpress on Heroku: Sounds clever, is a nightmare. Wordpress's heavy reliance on a local filesystem will never play nice with Heroku.
• "Shared" hosting (eg anything costing $1-$10 a month): These are vulnerable servers with unpredictable performance and security. You will be a common tenant with hardware running Estonian fake news sites. Do not put a moneymaking venture on such hosting.
• Running on a container: AWS, Microsoft Azure, and Digital Ocean all offer Wordpress images that spin up instantly for $5 a month. This is a tempting offer, but you'll be left holding the bag for bandwidth, security, sysops failures, DNS, SSL, and a number of other things that can very economically be passed on to others. 

• Use a managed host. We paid Flywheel $15/month for managed hosting with dope support, and had all the aforementioned issues just handled. $15 even included SSL at the end, there. Easiest spending decision I ever made. Compared to a $5 container, the marginal $10 removed a whole lot of potential stressors.

• Piracy protection: Turns out it's not easy to remove the ability to right click > Save As on your video behind the paywall
• Responsive web design: Turns out it's not easy to have a player that's always the right size
• Dynamic quality switching: Turns out this requires identical, separate videos of different quality levels
• Transcode: To serve the above, we need one baseline video converted into all those separate quality levels
• iOS playback: Turns out Apple has quirks here and demands their own special snowflake streaming video format

These guys made it all possible and earned every penny.

Many of these things I now explain to my subordinates. 

• Git, Github
• Stripe
• Languages: Ruby on Rails, PHP
• Wordpress, plugins and The Wordpress Loop
• WooCommerce
• SSL
• Analytics: tag containers, Mixpanel
• Infrastructure: Heroku, Amazon S3, Cloudfront, AWS in general
• Time-savers: Managed WP hosting, Wistia for video
• Practice: Staging environments
• Web technologies: Bootstrap, templating systems

The learning was challenging, and the introverted nature of tech work even messed with my psychology at times. But I look forward to the next opportunity to learn more while building something.