Five reasons I refuse to write my own software to deliver my screencasts

So you want to sell screencasts on the web…

Junsheng from Chicago asks, regarding RubyTapas:

Do you mind sharing with me how you deal with the subscription payment? Do you use service like “Recurly” , or just roll your own  with stripe API integration? Also how do you enforce access to paid content? Do you check, say, “paid” flag in the users table?

This may seem like a simple question, but to answer it I feel like I need to first fill in some background on one of the most important business decisions I’ve ever made. (It’s also a nice excuse to write up something I’ve only explained in conversation prior to now).

You should “eat your own dog food” …right?

Let’s say you’re an aspiring pro screencaster. You want to sell educational videos about programming. So you need a way to process payments, deliver content, and control access.

And you’re a programmer. Which means there is an obvious plan of action that immediately presents itself: you will use your programming skills to create a web application to host your content. After all:

• It’s a pretty simple set of requirements. It can’t be that difficult.
• How can you present yourself as a programming teacher, if you’re not “eating your own dog food” and writing your own delivery software?

I have always found these arguments to be quite persuasive. But when I was first creating RubyTapas while simultaneously working as a consultant, I knew that I didn’t have the immediate personal bandwidth to create multiple high quality videos a week and at the same time write and maintain the software for delivering them. So at the beginning, I chose to use a completely hosted service which took care of all of the billing and delivery.

This hosted service later turned out to be quite limiting, as these things often do. And so for several years I slowly and quietly worked on building the mostly-static sales site into a full-fledged content-delivery application that I hoped I could eventually shift over to completely.

Reasons not to roll your own software

What I discovered, though, is that creating high-quality, frequent training content; marketing that content; and staying responsive to the customers of that content is a more than full-time job all by itself. It doesn’t allow a lot of spare time for hacking.

And there was a lot more hacking needed than I would have estimated at first.

Reason #1: You will underestimate the features you need… and that your customers want.

I became intimately familiar with the kind of small but important features that take a service from being adequate to being delightful. (I mostly learned about these due to their conspicuous absence). Things like really good search that understands the semantics of the content. Or having a way to tie episodes together into “learning trails”. Or a members-only RSS feed. Or a quick way to re-send someone’s receipt. Or an easy way for them to make sure their tax ID appears on the receipt. Or even having a fun little button that brings up a random episode every time you press it.

If I thought about it for a while I could list dozens and dozens of these little features. Hundreds even.

Reason #2: You will underestimate the features you need to grow

I’m not talking about growing into a million-dollar company; I’m talking about relatively short-term growth that’s essential to go from a side-gig to a sustainable business. I’m talking non-trivial features, such as a team administration panel for corporate accounts. You can get by for a while with hacks and manual procedures, but if you want your customers to tell their friends about you, you need to make their experience feel smooth and professional.

Reason #3: You will underestimate the importance of software support for marketing needs

I started to learn that when it comes to marketing, website software can help you out… or it can get in the way. For instance, if adding a special referral URL takes a couple lines of code, a test run, and a deployment, you’re going to be less eager to take advantage of marketing opportunities than if adding that URL is just a matter of a few clicks. It may seem like a small thing, but these opportunity costs add up over time.

Reason #4: You won’t think about the cost of delegation until it’s too late

Later, as the screencasting business became more than a full-time job, I started looking for ways to delegate nontechnical parts of the work. And I realized something else: when a programmer sets out to build a system to scratch an itch, they don’t usually do it with an eye towards how easy or difficult it will be to offload parts of the work onto someone else.  Then when it comes time to delegate, they realize they have a nightmare of training and/or remedial feature-work to deal with.

And in the back of their mind, they probably realize this. So they put off delegation longer than they should. This is one of the ways developer/founders accidentally render themselves irreplaceable. It’s not a recipe for a scalable business.

Reason #5: You can be a full-time educator, or a full-time code monkey. Pick one.

I realized that it was taking me forever to create a merely adequate system in my spare time. Let alone a delightful, full-featured system.

I also realized something else: I had drawn the inspiration for a number of my episodes from this behind-the-scenes work. And I’m quite proud of all those episodes.

But I realized that if all of my spare hacking time forever forwards would be devoted to creating this content delivery system, then I stood the very real risk of becoming a programming screencaster who trains his customers in the art of making software to be a programming screencaster.

Now, as someone doing screencasts about a programming language which is commonly used for web-based e-commerce systems, that wouldn’t be completely unforgivable. But it wasn’t who I wanted to be. It wasn’t the service I wanted to deliver.

The zero-code rule

I’m proud of the fact that my video scripts are drawn from both my personal experience in a diverse set of domains, as well as my experience working with countless students and consulting clients. Who in turn have introduced me to problems from an even wider array of backgrounds.

Yes, I do believe it’s important for me to “get my hands dirty” in code in order to keep my content relevant and useful. But I don’t want all of my current hands-on experience to be drawn from the single domain of “delivering screencasts”. That doesn’t strike me as a strategy for bringing the most possible value.

And so, when it came time to plan for RubyTapas 2.0, I made a decision: I would shelve all the work that I had put into creating my own application to host it. I would stop telling myself “one of these days I’m going to manage all this with my own code”. Instead, I would go all-in on a new rule: I will write zero code for the delivery of RubyTapas.

Or at least that I will exhaust all other non-code possibilities—including changes to my process—before writing code.

Practicing what I preach

So does delivering my screencasts on someone else’s code make me an impostor and a charlatan?

In my opinion, no. In fact, my choice not to write code to deliver my show falls directly in line with one of the core principles I teach my viewers: that one of the most important skills of a mature developer is the ability to identify opportunities to avoid writing new code.

Delivering paid, members-only content on the web is a solved problem. A very, very solved problem. Anyone who says that none of the solutions out there does quite what they need is probably secretly looking for an excuse to write some code. If I were to re-invent this wheel out of sheer programmer pride, it wouldn’t just hobble my ability to deliver the best possible content. It would be a failure to model the very kind of pragmatic, business-justified technical decision-making that I try to teach on my show.

What I use

All that was a very roundabout way of answering the original question, which was: what kind of software/services do I use to deliver and charge for RubyTapas?

The short and sweet answer is: WordPress for the content, along with the fantastic MemberPress plugin for managing memberships and payment gateway integration.

That leads into a number of other questions, such as:

• Why WordPress?
• Why MemberPress?
• What other plugins do you rely on?
• Have you really written zero code to deliver RubyTapas?

I hope to write articles addressing each of these questions, and others, in future installments of this brand-new Kitchen Tour series. If you have more questions, feel free to pipe up in the comments.

Happy hacking!