Paywalling Your Premium Content with Jeremy Green

Intro: Hey everybody. Welcome to episode 94 of How I Built It. In this episode I talk to Jeremy Green about his paywall plugin Leaky Paywall. I thought it was an interesting project, and he happened to reach out to me around the same time that I heard him on another podcast, which I also thought was very interesting. I really enjoyed talking to him. We get pretty deep into developer stuff, local development, using GitHub and some of the workflows around GitHub and things like that. He also provides some interesting insights on how people consume information and the reasoning behind why you would put some stuff behind a paywall.

I also wanted to tell you about the new shop over at HowIBuilt.it/shop. We’ve got T-shirts and mugs, and I’m very excited to bring those things to market. We have all sorts of colors and we have both men’s and women’s cuts in the T-shirt options. Head over to HowIBuilt.it/shop to see everything we have to offer there. Today’s episode is brought to you by Pantheon, and a new sponsor, Techmeme’s Ride Home podcast. You’ll hear about both of them later. For now, on with the show.

Joe Casabona: Hey everybody. Welcome to another episode of How I Built It, the podcast that asks, “How did you build that?” Today my guest is Jeremy Green of Zeen101. Jeremy, how are you today?

Jeremy Green: I’m doing great.

Joe: Awesome. Thanks so much for being here. Jeremy, serendipitously you reached out to me on the same day that I listened to an episode of the Post Status Draft podcast where I heard about you and your product, Leaky Paywall. It was a little bit of repetition I saw there, so I’m very excited to have you on the show. Why don’t we jump right into it? Jeremy, why don’t you tell the audience who you are and what you do?

Jeremy: Sure. My name’s Jeremy Green. I’m in Fort Collins, Colorado and I’ve been building websites for clients for about the past eight years. About four years ago me and a couple other guys decided to start a little side project company called Zeen101, building plugins and tools for publishers. Right now we build websites and then also work on our products on the side, making improvements to them as we build sites with them.

Joe: Nice. When you say that you build WordPress sites for publishers, you mean people who are creating online magazines, or newspapers? Stuff like that?

Jeremy: Yeah. Our main focus is magazine publishers who are trying to go digital, and local newspapers who are trying to go digital.

Joe: Nice. Do you find that’s a good niche to be in? Niche, however you want to pronounce it.

Jeremy: Yeah, exactly. Absolutely. There’s a lot of people that need help in that space, so there’s definitely a ton of opportunity there. We’ve been pushing really hard for the last couple years in that space.

Joe: Nice. You have the client side of things, and then you have the product side of things. We’re going to be focusing mostly on Leaky Paywall today, but you do have several other products. Are these all products that came out of client requests?

Jeremy: Yeah, pretty much. It all started with a client request for our IssueM plugin which lets you create magazines online, gives you issues, and stuff. And from that a client wanted a way to do a Leaky Paywall-style functionality. Originally it was built just for that integration with IssueM plugin. Then we had another request for it that didn’t involve IssueM, and we decided, “This could be a cool idea for a plugin.” So we pulled it out as its own, and started doing development just on Leaky Paywall.

Joe: Gotcha. Very cool. That seems like a pretty regular path for the freelancers, or the people who are doing client services. They get enough of a request from enough clients to say, “This is probably a useful plugin.” Did you do any other research as far as creating–? Let’s change gears now and focus completely on Leaky Paywall.

Jeremy: Sure.

Joe: First, maybe you can tell us a little bit about what exactly that is, and then if you did any other research outside of client requests.

Jeremy: For sure. Leaky Paywall is a membership plugin, but it has a different way that it restricts content. Instead of having a hard paywall where content is completely locked down, it allows the user to choose what content they want to view before they reach that hard paywall and have to pay or give their e-mail address, or however you set it up, to be able to access the rest of the content. That’s basically how it works. And then– sorry, what was the other question?

Joe: About research. But I’m glad we paused there, because if we’re equating functionality. It’s like, you read five articles or three articles from the New York Times and then it says, “You hit your limit for the month. If you want to pay to read the rest, go on ahead.” That’s a good use case for this plugin, right?

Jeremy: Yes. That’s exactly what it does.

Joe: Perfect. Moving on to the second part of that question, you said that you had a few client requests for this type of functionality. Did you do any other research before or while developing the plugin?

Jeremy: Yeah. We looked around to see what other options were out there, and most of the other Leaky Paywall-style things were SaaS services that took a share of the revenue. So we decided to go the WordPress-plugin route, we don’t take any revenue share or anything from publishers. They keep all their subscriber revenue, we just make our money from add-ons and client services.

Joe: Gotcha. That seems like a very desirable model for the publishers, because making money as a publisher is hard. Especially if you’re going to go the paywall route. It’s very unappetizing to want to give up a share of that to have your main revenue driver, I would say.

Jeremy: Absolutely. That’s what we’ve found, too. Especially with the small and medium sized publishers, which is where we’re really focused on. They can’t afford to lose 30% of their subscriber revenue.

Joe: Wow, that is a lot more than I was thinking in my head.

Jeremy: Yeah. Different programs, different softwares do have different revenue shares. But that’s just kind of the general level.

Joe: Gotcha. Do you offer a free version of the plugin on the repository, and then sell the add-ons? Or is there a premium version of the plugin?

Jeremy: Yeah. We have Leaky Paywall which is free on the repo, and then we have add-ons that add additional functionality onto it. We started as a completely premium plugin and we decided to make the core functionality free a couple of years ago, just to try to get some more exposure and get more people using it.

Joe: Gotcha. Has that worked out for you?

Jeremy: It has, as far as getting our name out there. It’s really increased the amount of publishers that we’ve been able to work with because they find our plugin and they reach out. We have a lot more connections with publishers now.

Joe: That’s great. I’d imagine that it’s probably a good way for you to not only sell more copies of the plugin, or the add-ons, but also maybe get some extra client work on the side.

Jeremy: Exactly.

Joe: That’s fantastic. What’s in the free version of the plugin? Is it like e-mail ask, or is there some payment processing in the free version?

Jeremy: Yeah. The free version comes with PayPal standard, and also Stripe built into it. You can start taking payments right away. If you want to do recurring payments or something like that then we have an add-on for that, but out of the box you can use Stripe or PayPal.

Joe: Wow, that’s fantastic. So people can start making money with your plugin right away, no money down, 30 day guarantee.

Break: Today’s episode is brought to you by Pantheon. WordPress 5.0 and the new editor Gutenberg are coming. Are you prepared? Do you want to learn about the changes in advance? Pantheon has gathered resources to help you prepare, including webinars and tutorials. Pantheon also has made it easy and free to try Gutenberg with your site before the official launch. Visit Pantheon.io/Gutenberg. Let them know that How I Built It sent you. Now, back to the show.

Joe: This is always really interesting to me. When you were figuring out what to make free and what to have as an add-on, did you did you talk to people? Did you talk to your clients, did you just get feedback from users, Did you talk to other professionals in the space? How did that look with the decision making process?

Jeremy: Yeah. We just talked, and we saw the requests that were coming in. Either through the support forum on WordPress.org or our support ticket system to see what people wanted. Our benchmark was if it was something that helped the publisher make money, then we should probably charge for it. So that was our baseline that we used in deciding whether to make something free or just put it into the core plugin. It’s not 100% that way, but for the most part that was what we used to figure out what to charge for and what not to charge for.

Joe: Yeah. And that makes sense. I’ve always said, “The easiest sell is the sell that you can apply a direct value to.” It’s like, “If you buy this add-on you can start making money immediately.”

Jeremy: Yes, exactly.

Joe: Awesome. Very cool. I do have one more question about the features before we get to the title question. It looks like you have an IP exceptions add-on and Ad Dropper, and stuff like that. How much of that came from the implementation? Because you kind of answered this question already, but how much of this came from your domain knowledge of working with publishers on the client side? I’ll do it too. I’ll say, “I could totally build something like that.” But I’m not in the industry and I don’t have the domain knowledge. So, how much of that domain knowledge helps you create features and relate them and write the copy? Writing copy is so hard.

Jeremy: Yeah, 100%. I would say we have client requests as we’re building a site and we’re like, “That’s a great idea. We should build that for this client and then create an add-on for it.” We do that all the time. Like IP restrictions, there was a request for a lot of people in the publishing industry to sell publications to libraries, or universities. So they needed a way to give people with an IP address access without the user having to log in and stuff. That came directly out of a client request, and then we just generalized it to make it an add-on. Most of our new add-ons that come out are directly related to problems or needs that we see that publishers have.

Joe: Gotcha. And understanding that neither of us are lawyers, I guess open source helps in giving you the ability to do that. Because I know when I did freelance work my contract was always, “You completely own everything unless stated otherwise, unless I built it previously.” Does open source help with that? Are your clients keen on you doing stuff like that?

Jeremy: For client work it’s usually pretty customized. We’ll take the idea and we customize it specifically for them, then after the fact we’d more generalize it, and I’ll put in all the hooks and filters needed if someone else wants to customize it as they need. But it’s a pretty generalized version of what we actually build for the client.

Joe: Cool, very cool. I like that a lot. That sounds really cool. I do video work for people and I try to toe that line as well. You can’t exactly copyright teaching something, you can just copyright the content that came out of that teaching thing. So it’s a very similar model to what I take, and very interesting.

Jeremy: Yeah. I’ll even say with that real quick, we have some people that we don’t do full site builds for, they just need a custom functionality. We’ll say, “OK. We’ll develop it for you, and we’ll give you a discount, but we’re going to create an add-on out of it.” That’s another way that we handle that as well.

Joe: That’s great, because then you’re getting a little seed money to build out your business, which is really cool. I like that a lot. Nice. We are about at the halfway point which is when I like to ask the title question, which is, “How did you build it?” You touched on a little bit of that. You’ll get kind requests, you’ll build something specific, you’ll generalize it with hooks and plugins. But what is your development process look like?

Jeremy: We have me, and then a couple other developers that work on it part time. Personally I just use Sublime Text and we have everything up on GitHub so the paywall itself is up on a public repo and all our add-ons are on private repos. We try to use the Gitflow model to create feature branches, work on stuff there, push everything together and then push it out to the repo from there. So we’re working on adding more automation and stuff like that, but it’s just a lot of reading other people’s code and just seeing what other people are doing in this space. Because the membership plugin isn’t new, but our take on it is a little bit different. So just seeing what other people are doing, take best practices and try to incorporate that into our plugins.

Joe: Nice. That’s fantastic. So, you mentioned Gitflow. I always mess up Gitflow and GitHub Flow, and then there was another one introduced to me recently. This is a fun question and I don’t know that I’ve asked it on the show before. My development process used to be feature branch to the dev branch, and then once we felt the dev branch was ready we would merge that right into master. A new– well, new to me, as of a few months ago was feature branch to dev branch, test it on the dev branch then feature branch to master branch. Then at some point you merge master back into dev to make sure that everything is in sync. Is your flow one of the above, or none of the above?

Jeremy: We just have a master and dev branch, and then we just create the feature branches off of master and do all of the work there. Once everything’s good we create a release branch with all those features in it, and then test all that out across everyone’s environment and try to catch any bugs that we can. Then push everything up to the developing master branches, and then push those out.

Joe: Nice. I dig that. Then you have similar to what you see in subversion, with all the release and version numbers as branches. Cool. I like that a lot. And then you mention that you were working on some– First of all, let’s back up a little bit. You have the public repo which is the core plugin and then you have add-ons as private repos. Do you pull in the core plugin any old way, or is that something you do locally? I know people will use Composer or something I haven’t used in a long time so I can’t remember, but it’s like pulling in a repo within GitHub.

Jeremy: Right. Submodules and stuff like that.

Joe: Submodule, that’s it. As soon as we stopped using it at my old company I forgot about it, because I hated it. Do you do anything like that?

Jeremy: Personally, I keep it simple. Most of my day-to-day is client work stuff so I don’t have time to get too much in the weeds on the development process on the plugin side of things. I just keep it simple, pull down both of the repos locally, have all the add-ons in one install to make sure nothing breaks whenever we have something new, and then push it up. It’s not very complicated, you can definitely get pretty complicated. I’m in the Post Status Slack and I’ve asked the question, “How do you guys do development? Because I’m just figuring this stuff out on my own. I’ve never had anyone teach me or anything like that.” So it’s really cool to learn what other people do and take little pieces here and there. But I like to keep it as simple as possible.

Joe: Absolutely. I’m 11 years out of college now, I’m almost 10 years out of grad school and we didn’t really touch on development process like that. It was more like we used Java primarily, so I definitely prefer keeping it simple. I miss the days where I could just open up a code editor and write code and then, “It works!” Or whatever. Now you need to do the node and the build, and the whatever.

Jeremy: I know. I remember when there wasn’t CSS.

Joe: Nice. I was coming in right when CSS was starting to get big. I knew just enough to write each HTML without CSS, and then my friend showed me CSS, and I was like, “What is this amazing thing?” Right before I got set in my ways. But now that’s where I’m at. So, do you use Linter or automated tests or anything? I interviewed Pippin a while ago, I guess it was over a year ago now. And he said that he likes to keep his development environment so light that if his laptop fell into a lake, he could go buy a new one and be up and running in an hour. I loved that.

Jeremy: Yeah. I just use Laravel Valet for local development, so I could spin that up in 5 seconds and be ready to rock again.

Joe: Nice. Laravel Valet. I use Local by Flywheel, because development is not my day-to-day anymore. I do mostly video stuff. But I’ve been hearing a lot of good things about Laravel Valet, I’m definitely going to have to check that out.

Jeremy: It’s pretty awesome.

Joe: Cool. Sweet, this is fun. I get to ask these two questions. Usually it’s all covered in the whole big story, but what transformations has your product gone through since it first launched? I’m really curious to see, you kind of alluded to this but it started off as a client plugin first, that you maybe generalized into a public plugin, and then how did it evolve from that?

Jeremy: It started, and it only worked with that IssueM plugin that we have, and then we added Post Types restrictions so that way it would work with any site. Then it used to be only premium, and then we decided to make the core part free. That was a big change. So those were the biggest transformations, as far as what it’s come from. We’ve added lots of functionality to it, like it used to only have subscribe cards that just had Stripe check out. You couldn’t do registration forms, that was a big update whenever we pushed out the ability to do that. Then over time we’ve just been adding a feature here, a feature there.

Break: This episode is brought to you by the Techmeme Ride Home podcast. You may have heard of Techmeme.com, which is a great tech news site that you can check multiple times a day. Techmeme Ride Home distills all the great content from Techmeme.com into daily 15-20 minute long episodes. You get top stories, posts, tweets and conversations every day around 5:00PM Eastern. It’s like NPR’s marketplace, but for tech news. The show is hosted by Brian McCullough who also hosts the internet history podcast. To listen, you can use your favorite podcast app to search for Ride Home and then subscribe. Get your tech news daily from the Techmeme Ride Home podcast today.

Joe: How important is working on mobile for you? Because I heard some very insane stats recently about the number of people who consume news media on mobile devices.

Jeremy: Yeah. Obviously making sure everything’s responsive and stuff like that. It’s difficult with a plugin though, because it’s not the theme. Theme styles can make stuff look ugly pretty quick. We’ve seen some pretty bad ones out in the wild, especially in local newspaper stuff. Obviously having that mobile experience is good. The big thing we push with our publisher clients is e-mail list building and getting that, and most people are reading stuff on e-mail and then sending people to the website when they’re checking e-mail on their phone, or whatever. So just making sure that the site itself is mobile-optimized. But obviously, we can’t do that from the plugin side of things. Only if we help with the site.

Joe: Absolutely. That’s so interesting, because about two years ago I heard, “E-mail is dead.” And then since going out on my own, all I’ve heard is, “Your email list is your business’ lifeblood.” And I’m like, “That’s interesting.” So, very cool. I know Stripe makes it easier to integrate Apple Pay, do you do things like that in the plugin, or is that an add-on?

Jeremy: We can do it. We don’t have an add-on or anything, it’s definitely possible with the hooks that are in there. If someone wanted to roll their own, or something like that. Honestly, we haven’t had any requests for it. We haven’t dove into that side of things. We’ve got requests for tons of other things in our feature backlogs, so that one just hasn’t made it to the top of the list. It’s definitely possible if you wanted to.

Joe: Cool. I really like that answer. I didn’t prep you on that or anything, so I didn’t mean to blindside you. I guess as somebody in the tech field I just assumed that Apple Pay would be a popular thing, but I guess users probably prefer the act of putting the credit card in if they’re going to give their money to people. Interesting. And you mentioned that you have a big backlog, what are your plans for the future of the plugin? As much as you’re willing to say, of course. I don’t need a hard date, I don’t want to tie you to anything. But what are you working on for the next release?

Jeremy: Our biggest thing we’re working on right now is working on subscriber engagement and getting data around that, because you can do a whole lot more with data whenever you know who the user is. “What’s their path to subscribe? How do you keep people from churning out? How do you add more value to a subscriber to keep them around? What kind of content is a subscriber using? What are they viewing?” And then, “Who hasn’t come in a while?” So you can reach out to those people. Having data points around that, and then creating automation around reaching out to those people, and just helping with subscriber engagement is our next big set of tools that we’re working on that will integrate with Leaky Paywall.

Joe: That’s fantastic. And that’s something that I’ve heard echoed in other interviews at the end of season 4. I had an interview with Becca Rice of Jilt, and she talked about stuff like that. Figuring out engagement, and how to figure out who’s browsing your site maybe before they put an e-mail address in, or capturing that e-mail address as soon as possible. Because Jilt does abandon carts, and it’s not very useful if you don’t know who to send the e-mails to.

Jeremy: Yeah, we’re actually using them on our Zeen101 site right now.

Joe: Nice. At the time of this recording, this episode is going to be in season 5, but they were definitely a sponsor for season 4 and I’m a big fan of their work. I’ll link them in the show notes if you want to go check them out as well. Cool. I’ll end with my favorite question which is, do you have any trade secrets for us?

Jeremy: I would say the biggest thing is dog-fooding your product as much as possible. For us, that wasn’t in us using it personally. We don’t have a publication, but by building client sites with the plugin, we’re really able to see what works and what doesn’t and what features are missing. What could be improved, even from the admin area. A lot of requests we get is the person managing the subscribers needs more tools and stuff like that. So I would say just dog-fooding your product, using it on real-world sites and seeing how it’s actually being used in the wild. You’ll learn a ton.

Joe: That is fantastic advice, as somebody coming from working in higher Ed, it was very clear that the people making the products were not in higher ed. So, definitely you will have a better product if you use the product as well. It’s just like taking a design that has the perfect amount of text in the design, you want to make sure that you’re using real text and not the perfect size headline, because you can’t always guarantee that a headline is going to be exactly 30 characters or whatever.

Jeremy: Or those photos and themes that you can’t actually use. If you don’t have good photography, the theme sucks.

Joe: Exactly. That’s the biggest criticism I’ve heard of Squarespace. If you don’t have good photography your Squarespace site is not going to look good. So, awesome. Jeremy, thanks for joining me today, I really appreciate it. I’m glad you reached out.

Jeremy: Thank you.

Joe: Where can people find you?

Jeremy: They can find me personally, @GreenHornet79 on Twitter. And then Zeen101.com is where all our stuff is.

Joe: Nice. Are you a fan of The Green Hornet?

Jeremy: Actually, it’s kind of a story. I had a ’79 Ford F-150 pickup in high school and completely restored it and it was a metallic green. So my grandpa called it the Green Hornet, and it’s stuck with me since high school.

Outro: That was an absolutely fantastic way to end the show. Thanks again to Jeremy for joining me today. I really appreciate everything that he talked about. His story about his grandfather, the insights into creating a paywall, and of course his development environment. And I want to thank our sponsors once again. Thanks to a Pantheon and Techmeme’s Ride Home podcast. Definitely check both of those out, those are completely free for you. Go ahead and head over to the appropriate sites and check them out. Their support is deeply appreciated.

The question of the week for you is, have you considered adding a paywall to your site? Maybe you have a blog or a new site, maybe you have a podcast or online courses that you maybe drip out some for free. Have you considered adding a paywall to that? Let me know on Twitter, @jcasabona, or email me Joe@HowIBuilt.it. Don’t forget to check out the new T-shirts and mugs over at the HowIBuilt.it/shop, and for all the show notes head over to HowIBuilt.it/94.

If you liked the show, head over to Apple Podcast and leave us a rating and review, it helps people discover us. You can also join the Facebook community over at HowIBuilt.it/Facebook. We ask the question of the week over there too, so you can talk to other listeners about the episode and the question of the week and things like that. I really want to build a strong community around this podcast and Facebook is the place to do it. So, that’s everything from me. Until next time, get out there and build something.