MVP Podcasting platform
by Mark MoriartyI had limited savings, but plenty of enthusiasm.
I'd quit my job, but I couldn't actually code. So initial progress was understandably slow.
I hadn't enough confidence I would succeed to ask another person for their hard-earned money. And I would't ask a friend to "quit your job to join me in building X" until I decided what X should be. So I set about building it myself.
I had too many ideas and figured I put something out there, and iterate based on feedback and early users. That's what some startup advice said.
My main challenge building the platform was needing to code. This made things slower than if I had been able to code. But, it wasn't a deal-breaker. I had done some C++ in college, and a little bit of python, and Django was proving to be quite understandable. In fact Django was python, though I'm not entirely sure which commands are python and which commands are Django specific. It doesn't matter though, because users don't care about these details either.
A key feature of an audio publishing platform, I decided, should be the ability to upload audio. Indeed, this seemed like a rather critical thing to figure out.
Thankfully, Google offered over 200 million results for "audio uploader add to website". I learned I should be storing files on S3, separate from the code of the website. I picked a library called s3-fine-uploader because, well, that sounded fine.
I remember following the documentation for s3-fine-uploader. They seemed well-written; that's part of what drew me to using it. Unfortunately, though they boasted that many people use s3-fine-uploader, their documentation had typos, or I was mis-interpreting it somehow: I pasted the example code EXACTLY into my html file, and it didn't work. Hm.
After checking that I had indeed pasted the code exactly as in the docs, prepared to make my first contribution to the world of open source software: my first post in Stack Overflow, explaining how the documentation was wrong, and how it doesn't actually work. As I checked the details, to ensure I explained myself correctly, I realised something very important: the code I was pasting was "JavaScript", and I was pasting it into a .html file. This is possible, but you have to put the javascript inside <script></script> tags. Ahhh.
Learning the different between javascript and html turned out to be very useful, and I remember it to this day.
I felt they could have done a better job in the documentation, by saying something like, "the following lines are javascript" before just sharing the code snippet. Perhaps the author of the documentation thought it would be obvious to the reader. If so, I looked forward to the day when I'd know whether a code snippet was JavaScript or HTML, just by looking at it.
I persevered for several weeks or months like this: focused on some core set of functionality – log in, log out, upload, press play, press pause – no matter how the platform evolved, those seemed appropriate to build.
I used Google to reveal millions of answers to literally every question I had.
"Change the tiny image in the browser tab for my website".
"Make corners of button roundy".
"Make corners of button less roundy".
Google had it all.
I even used git for the codebase, like a programmer would. If I made a mistake or confused myself, no worries; just restore from Dropbox, create a new repo and start again.
Speaking of Dropbox, did you know you can use Dropbox as a CDN? Simply set the permission on a file to be "public" and you can embed .css or .js files right into the <head> of your page. This means you can make a file change to the .css file while testing on your machine ("local host"), and any users of your website will also see the change in real time – ideal! No need to worry about re-deploying. This way, you can use your users as testers: if you make a bad change, your users can let you know right away.
The only snag is that Dropbox has limits on how many times a public file can be accessed per hour, so if you have more than about ten users, sometimes the .css file won't load at all for some users. Thankfully this isn't really a problem if you have few users.
After gradually to learn to "code" (copy-paste) from Google like this, I eventually had a fledgling beta. It didn't feel worth of a "launch", so I guess I "soft-launched", without any fanfare or publicity, to get my first users: indie podcasters. By "soft-launch", I mean I messaged a few podcasters and asked them to try it; they warmed to me, and are excited to use it. Woo, that was easy. But for the most part, they're not paying customers.
I've built a Libsyn alternative. I believe I can build much more detailed analytics than Libsyn offers, and I have a future vision of building a dynamic targeted ads marketplace in future when I reach scale. For now the focus is grow the number of podcasters on the platform, and build out core features like robust analytics, automatic distribution to other platforms, and building time-saving tools for podcasters.
Awesound so far is an alternative to Libsyn. Better in some ways, worse in some ways.
I start to build some cool new features, like transcription with auto-advancing transcripts. But, transcription (with Speechmatics) costs me, and I pass this cost on to the podcaster. Turns out most podcasters don't care about this feature.
First podcasters using Awesound include Gregg Clunis and Jennie Friedman. I am grateful to everyone who takes a chance on me.
I confuse myself a little with what pricing makes sense, and wind up offering a very generous "free tier", which includes the first 100 hours of uploads for free (only transcription costs extra).
Having never built a website before, I'm excited people are actually using this thing I've built, though revenue is limited to a handful of folks on the $5/mo. plan and a handful on the $39/mo. plan. In some cases, people are on a paid plan when they don't need to be. They're as confused about pricing as I am.
