Case study: hacking Gumroad to create and Audible-like experience for digital comics

A few of the businesses owners that I work most closely with are unique in that I don't (or can't) really share much about their businesses due to owner privacy.

But one of them is just too damn interesting to not talk about, so I'm going to do my best to share some recent lessons without sharing any identifying details.

A brief business history

Before working together, this business had been running for a few years as a sort of boutique studio producing niche digital comics. The owner was the original artist, and had built a bit of a following.

My first piece of advice wasn't even really an official consult. It was a casual recommendation that if they offered a free comic in exchange for an email address, they could start telling those subscribers about new comics each week to boost their weekly sales.

But my favorite kinds of people to work with are the ones I don't have to tell twice.

This owner started offering a free to build their list, proactively market new releases to that list, and over the course of 6 months nearly tripled their monthly revenue.

4 years later, they passed $1MM in lifetime revenue. From selling extremely niche digital comics on the internet at $10-20 a pop.

Their catalog has grown to include hundreds of comics, made by dozens of artists. Their pipeline for new releases is planned 8-12 months in advance. They release new work every week like clockwork.

And in some ways, it's the most interesting businesses I work on because it's the most boring business I work on. The owner has made it a machine. It's beautiful.

It's also one of the few "consumer" businesses I work on, which I like having to compare and contrast with the B2B world where I spend most of my time.

So now you're caught up. Let's talk about our most recent experiment, what we built, and why.

Problem #1: The Paradox of Choice

As this business grew, it's catalog continued to be the main source of income.

But as the catalog grew, so did the audience, and we had a new problem.

Whenever a new customer would find us, they had too many choices.

We used Gumroad to reach this point in the business, but were running into the limitation that it's designed for people with relatively small collections of products. I'd be surprised if anybody else used it to sell a brand new product every single week, let alone a catalog of hundreds of comics.

If we wanted to escape the reliance on new releases for revenue, we needed to start thinking about the back catalog as an asset instead of simply a historical collection of released work.

Problem #2: Membership Retention

It's worth remembering that at one point, the only way for someone to buy from this business was to join with a monthly subscription on Patreon. Adding the option to buy individual comics and building simple but powerful email list systems with ConvertKit had gotten us very, very far.

But after years of being stable, the recurring membership revenue slowly began to dwindle. It also took the hardest hit during the COVID pandemic and again during recent economic turbulence.

And understandably so! Monthly subscriptions are among the first to hit the chopping block when people are looking to trim their expenses.

Beyond a reason to sign up for a membership, if we wanted people to stay, we needed to find a way to over-deliver on value in our memberships.

Most of our best ideas for members-only perks would be costly or difficult to sustain. We'd done a lot to decrease the amount of complexity and effort in the business, so if we were going to add any back in, we had to think carefully.

Most of our ideas didn't get very far.

Sometimes your customers will give you the answers, if you listen closely

One of our more successful experiments to solve problem #1 (thinking about our back catalog like an asset) has been creating curated bundles of comics that are related in some way, and selling them for less than it would cost to buy
them individually.

One day, a customer asked if they could request a custom bundle of comics.

They already had some comics in the bundles we offered, and were interested in comics that we weren't bundled yet.

The immediate answer was no. Not because we didn't want to, but because there wasn't really a good way for us to do it and the effort to create the bundle one-off just didn't make sense.

Maybe if the tech made it easier, we could. I even explored our platform's API to see what was possible, and couldn't come up with anything good.

Until the owner came to me and asked...what if we could offer our members the ability to pick a certain number of comics for free, as a perk of membership?

💡 Audible, but for our own catalog

As soon as they described it, my mind went to Audible.com, the monopoly audiobook platform owned by Amazon.

I buy a lot of audiobooks, but the way I buy them is rarely by paying the sticker price shown on Amazon.com. I pay for a monthly audible membership that gives me a certain number of credits every month, so whenever I want an audiobook it's a no-brainer when I have credits to spend.

Some months, I don't buy any audiobooks. But unlike subscriptions that I'm quick to cancel if I stop using them, I keep paying my audible subscription because if I don't use them one month, I know that I can use them in the future as long as I keep my account active. (I think they expire in 12 months or something, but Audible always lets me know they're going to expire so I should use them.)

Anyway, Audible's catalog is MUCH bigger than our catalog of comics. But the model seemed like it could work for us, and solve both of our problems at once: helping people overcome the paradox of choice while also increasing the value of our back catalog to our customers.

Shop the Shelf. Kinda.

Amy coined the phrase "shop the shelf" in Just F#&king Ship as a way to describe the strategic use of pre-built tools whenever and wherever possible, especially when launching something new.

Sometimes I joke that the reason I will avoid building custom software until
and unless I've exhausted all of my other options is because I've built and
run enough software to know better.

But let's be clear. There is no "off the shelf" tool for selling digital products that has a built in credit system. At least not that I could find!

And even if I had found something, I know how much time it costs to migrate platforms.

So this experiment needed to work with what we have.

About a year prior, we'd successfully launched a new website that essentially mirrors our catalog, and then links to a Gumroad purchase link. Building this
site took a LOT less time than migrating away from Gumroad, and provided us with the illusion of a fully custom experience.

In reality, we'd built a fairly simple but cleverly constructed static website using Jekyll + Netlify's headless CMS. It was fast and flexible.

More importantly – and more reality than illusion – this website was the first step in gaining more control over our customer experience in ways that we couldn't get with Gumroad alone.

Fast foward to this new idea, and it was time to bend Gumroad to our will again!

After a little time with Gumroad's API documentation, we came up with the idea to use their coupon code system as the backbone of our credit system. Since
Gumroad's coupons can be generated by API, and applied to a product's checkout link, we just needed to fill in the gaps with some business logic!

I drafted an initial spec, and shared it with a freelance developer who I've worked with on a bunch of "data plumbing" type projects.

The plan was basically:

• build a small piece of middleware software that our customers would authenticate with their Gumroad account, so our software can act as a custom "wrapper" around their account
• our middleware handles all of the business logic like giving them credits as long as they have an active subscription
• our wrapper also provides our public website – still a 100% static site – with some custom API endpoints that we can call with javascript

I wrote a quick spec and shared with a developer I've worked with before on various API integrations.

Within a few days, we had a working prototype of the middleware!

Our prototype was able to:

• Check if the authenticated customer had an active subscription or not
• Add/remove credits from their account
• Tell us how many credits they had
• Convert credits into one-time use coupon codes for a specific product in our catalog
• ...and a few other handy tricks to keep the workflow safe and secure

Not bad 😎.

After a few tweaks to the business logic, we turned to our Jekyll-powered website and starting building out some code that would:

• change parts of the site if the customer was logged in or not, or if they had an active membership
• show how many credits they had left
• and provide a simple interface for converting credits into free comics

And before long, our static site came "alive" by simply authenticating a Gumroad account. The dream had become reality!

Sidenote: I used ChatGPT to help me write a lot of this javascript code. While none of it was tremendously complicated, much of it was the sort of thing that would have taken me a LOT more time if I was relying just on Google. It was also pretty handy for debugging!

I still needed to know how to describe the code I wanted it to generate, so understanding how code works is critical to writing functional code with AI, but it was the first time I was truly impressed with what was possible.

At this point, all that was left was getting actual members to test it out.

Well, almost...

New Membership Plans and Pricing

Our membership already had two tiers, which made it pretty obvious that we'd offer more credits per month in the more expensive plan.

But the owner had another idea. Given what we'd seen with the price sensitivity of this consumer market (and the current crush of the global economy), what if we added plans at the lower end of the spectrum, with fewer benefits overall but still a lot of value for the price.

We did a bit of spreadsheet sketching, landing on a pair of additional price points that felt like "no brainer" options for someone who was a regular buyer.

Four price points meant needing to redesign our membership pricing page, but it needed an overhaul anyway!

TailwindCSS let us make quick work of building a clear and friendly multi-column pricing page, including an variation for annual prepayments. We were even able to use URL parameters to link directly to the various tiers on Gumroad for completing their checkout.

Once again, a near-perfect combination of having control over the customer experience right until we needed to hand them to Gumroad for commerce!

Planning a launch

One of the neat (and honestly, unplanned) side-effects of the way we built our system was that it the new credit system was effectively invisible until someone authenticated with their Gumroad account.

This allowed us to keep our login link private, only sharing it with existing members that agreed to help us test out the credit system.

We planned three phases to launch:

Phase 1 – Invite-only testers
Phase 2 – All existing members
Phase 3 – Public launch

In phase one, we sent a single email to existing members offering a batch of free credits in exchange for them trying out this new system.

We capped this group at ~20 people. About a third of them actually authenticated their accounts and tried out the credit system.

While we didn't get much feedback like we hoped, it seemed like no news was good news. People who tried the system with very limited instructions were
able to get their free comics.

Nothing "broke" and nobody did anything we hadn't planned for.

And that's what we wanted to see.

In phase 2, we extended the offer to all existing members.

Given that our initial test group went smoothly (if not quietly), we rolled out a similar offer to the rest of the existing members.

We went in with expectations calibrated that as long as nothing broke, we probably wouldn't hear anything. During a ~2 week window, a couple of small reports popped up, all easy fixes.

This was also the first time we heard from a couple of people that they were excited about this new feature, and getting more value for their membership.

More positive signs!

Finally, the public launch

For 6 months, we'd built and tested this new system but other than the existing members, basically nobody knew what we were working on.

I've run enough launches – and seen what happens when 30x500 students run our playbook or not – to know that a successful product launch is all about
momentum.

Nobody is paying as much attention as you are (especially in the run-up to launch). You have to remember that most people aren't walking around through life looking for opportunities to spend money they weren't already planning to spend.

Launch day isn't so much a "first look" for the world but instead a first opportunity to take action. Which means people need to know it's coming!

So one week before launch day, we sent an email to our list (and a couple of posts in the niche social media spots we know our community watches) to tell people that new membership plans were on the way in a week, with a teaser that we had a new way for them to access more of our back catalog for a lot less money.

More positive responses came in from these posts, further giving us confidence that this would work!

Even the best laid plans...

We set everything up so that launch day would be easy.

We flipped the switches and to celebrate, a mutual friend signed up to be the first customer just before we hit "send" on our official announcement email.

Good we didn't hit send, because something critical broke. 😂 😭

After a quick review of the issue, we decided it was best to quickly roll back the website until we could implement and fully test a fix.

It was definitely a deflating moment, but the right choice.

Launch Day, Round Two

With a fix in place and a thorough round of testing, we decided it was showtime.

We hit send on our launch email.

And within moments we had our first signups! 🥳

Within 24 hours, we saw many of our hypothesis play out:

• We saw signups at all levels, including annual prepayments 📈
• Those lower-priced tiers proved to be very popular 💸
• Almost everyone who signed up for a membership tried out the credit system right away 🎟️
• Within our first 24 hours, our total membership grew by more than 20%, hands down the most growth we'd seen in a long time! 🚀
• We even had a bunch of returning members – people who had cancelled previously coming back to enjoy the new benefits.

In those first 24 hours we also worked out a handful of small bugs and made a few quick improvements to the customer experience.

By all accounts, we're considering this launch an success.

Now what?

You'll find lots of discussion on the internet about what happens when a product launch fails. But not much is said about what happens after a launch
succeeds.

Most people experience some kind of post-launch hangover.

Similar to the feeling after a night of celebration, a successful launch can leave you feeling drained and strangely uneasy. This is often most true for folks who don't launch often!

What are you supposed to do next?

The most tempting is to sit and refresh the stats. But to what end? The dopamine of the numbers climbing up will only last so long.

So don't fall into that trap.

Here's what we're going to do:

1. We're going to celebrate. Candidly, I'm terrible at this. Amy and I both are! But I'm going to make sure that we celebrate this win. We earned it!

2. We're going to observe. We've spent so many months building that it'd be easy to jump back into build mode. Tweak and fiddle.

Obvs, we'll fix bugs as we find them, but if we start tweaking too soon, it'll be hard to know what's working and what isn't. So we're going to focus on
watching and learning from our customers' behavior over the next few months.

3. We're going to plan and prioritize. If I were giving us the same advice I've given many others, I'd suggest that we should have planned and prioritized the next things to focus on before the launch.

One of the most common symptoms of post-launch hangover is the uneasiness of "what should I be working on next?" and the easiest way to solve that problem is to decide the answer before you launch.

Thankfully, I'm a salty old veteran of launch, and this business owner launches a new comic basically every week. So the hangover shouldn't hit us too hard!

Lessons & Takeaways

• There's a lot of money to be made in very small niches
• Consumer audiences are way more challenging than B2B, even when they're doing well
• Giving customers too many choices can slow down their buying decisions
• Think about your past work as an asset, instead of simply a historical collection of released work.
• You can listen to your customers without doing exactly what they ask for
• Whenever possible, shop the shelf for tools before you build fully custom from scratch, even if it requires getting creative
• Write down your feature goals so you aren't tempted into scope creep
• You can and should create multiple opportunities to launch, instead of putting everything into a single day
• Don't wait until launch day to tell people you're launching
• Even when you plan and test, stuff will go wrong
• Decide what "success" looks like before launch day
• Celebrate your wins
• Avoid the post-launch hangover by deciding what you will do next before launch day is over