Handling freemium theme upsells with grace

Freemium WordPress themes are a big business. Transparency reports of Codeinwp, the company behind ThemeIsle, prove how lucrative it can be.

While revenue potential is well established, the conundrum of managing freemium codebases remains. As a freemium theme author, you have several methods of delivering paid functionality to your users:

• Premium functionality separated into child theme.
• Separately maintained, but largely overlapping, premium parent theme.
• Premium functionality separated into paid plugin.
• Separate premium parent theme managed in tow with free theme via pre-processing.

Some methods are more convenient for the developer at the expense of the user, and vice versa. In this blog post, we’ll explore the pros and cons of each, including two “best of both worlds” approaches.

The separate codebase approach

A user-friendly approach would be to maintain two separate codebases. One for the free theme. One for the paid theme.

Let’s break down the flow of the user:

1. User downloads free parent theme.
2. User buys paid parent theme.
3. User customizes with a child theme.
4. Upgrades to paid parent theme are hopefully seamless.

Conclusion: Clearly convenient for the user, but no so much for the developer.

Inefficiencies may trickle down to adversely affect users if consistency is not maintained across both codebases.

The child theme approach

A way to avoid the problem of maintaining two separate, largely overlapping codebases, is to separate any “Pro” features in a child theme. But this leads to another problem.

Let’s break down the flow of the user:

1. User downloads free parent theme.
2. User buys paid child theme.
3. User customizes child theme.
4. Developer releases elaborate update to paid child theme.
5. User wants to take advantage of new paid child theme features.
6. User has little choice but to messily “merge” their customizations with new code.
7. User wishes they didn’t customize the original child theme so much.

While grandchild themes aren’t impossible, it strikes me as a hacky, slippery slope solution. Here’s what Bill Erickson had to say about them:

With a parent/child theme structure, the child theme should simply be site-specific theming and customization of the parent theme. Most people who use them won’t be customizing the child theme – they will just install and run with it. If you plan to make changes to it, you should rename the child theme and use it as a starting place for your own custom child theme.

While a child theme might be updated in the future, those updates shouldn’t be pushed out to existing customers through the “Update Theme” dialog in WordPress. Customers also shouldn’t try to integrate updates with their customizations. The same logic applies to starter themes like Underscores. It gets updated often, but people who used it as a starter for their own custom theme aren’t monitoring those updates and integrating them with their own customizations.

If you have two or more websites with largely overlapping requirements, you should build a custom parent theme and then have each site have a site-specific child theme. This is one of the few situations when I specifically don’t recommend Genesis.

I’ve worked on a network that used Genesis as the parent, a “network” child theme, and then had site-specific plugins as the grandchild theme. It’s overly complicated and just not worth the hassle. Simple things like template hierarchy require custom code to make work across plugins, parent theme and child theme.

A “need” for a grandchild theme is a sign of a poorly implemented theme structure.

If people start selling “premium” grandchild themes, would they be customized with great-grandchild themes?

Conclusion: Convenient for the developer, not so much for the user.

Best of both worlds: a “Pro” plugin

Instead of maintaining two separate but overlapping codebases, or asking users to “merge” child theme updates, a freemium theme developer can separate any “Pro” functionality into a plugin.

Let’s break down the flow of the user:

1. User downloads free parent theme.
2. User buys paid “Pro” upgrade plugin.
3. User makes customizations via child theme.
4. Developer releases free parent theme updates.
5. Developer releases paid “Pro” plugin updates.
6. User is happy because their customizations are safe in a child theme.
7. Developer is happy because they don’t have to maintain separate but overlapping codebases.

The Theme Foundry uses this strategy with their popular free Make theme. Pro functionality is separated into a plugin called Make Plus.

Here’s what Corey McKrill, developer at The Theme Foundry, had to say about separating freemium theme upgrades in a plugin:

What we’re doing with Make and Make Plus, the free theme and premium plugin, works out really well — for us and the customers and community we serve. Our free theme on WordPress.org is the perfect point of entry for folks unfamiliar with our brand. It’s powerful, extendable, and indicative of our code quality and dedication to the WordPress project. Our codebase is public on GitHub, and our transparency with our development process is one way we can build trust with end-users and developers alike.

With the premium plugin, we get to build on the foundation that the free theme provides. So without taking anything away, we can offer more features, deeper integrations, and dedicated support. For one-man and one-woman shops, this means they get a premium theme for their site that’s been through the riggers of the theme review process and several levels of peer code reviews.

For developers and designers who do client work, using our premium plugin, Make Plus, along with the free theme, means there’s no interruption in their workflow — they create with the child theme while we continue to update and innovate and improve on the parent theme and plugin.

We really believe this is the ideal way — in the spirit of WordPress best practices — to offer a premium product.

The only downside I can think of is that it may be confusing for a user to wrap their head around the concept that additional theme functionality can be delivered via a plugin, but after that user education hurdle is jumped, everybody wins.

Conclusion: Best of both worlds.

Best of both worlds alternative: Freemius

Freemius is a company that helps WordPress developers monetize their products, and offers a pretty unique solution to the freemium codebase management conundrum.

This WP Chat post from Freemius founder, Vova Feldman, elaborates:

With Freemius, plugin developers only have to develop and maintain ONE code project with all the logic (free and paid). Our WordPress SDK provides a license related methods which can be leveraged in order to “tell” Freemius what’s the premium logic. For example:

<?php
if ( freemius()->is_paying() ) {
    if ( freemius()->is_plan( 'professional' ) ) {

        // Logic related to Professional plan.

    } else if ( freemius()->is_plan( 'business' ) ) {

        // Logic related to Business plan.

    }
}
?>

Then, when the plugin is ready for release, instead of deploying it directly to the WordPress.org SVN, first it should be uploaded through Freemius14 management dashboard. Our sophisticated PHP pre-processor will automatically process all the plugin files and will generate two [theme] versions.

Home-rolling a PHP pre-processor is an option too, but there’s value in having all that work done for you with Freemius.

In addition, Freemius can handle other tasks a freemium theme author might want, like payment processing, software licensing, and analytics.

Conclusion: Best of both worlds, and then some.