Posted on

2018 year in review

Since 2012, I have written a year-in-review post to detail and share highlights and challenges of the previous year. So as is tradition, here is my review of 2018.

Previous year in review posts: 2012 | 2013 | 2014 | 2015 | 2016 | 2017

In all, 2018 was an incredibly successful year for me and my company, Sandhills Development. We had some great achievements that expanded the team, grew our revenue and profit, acquired a new product, sold two plugin products, branched out into a new market and industry, and matured as a company. We also, however, had some significant challenges that were perhaps some of the hardest yet. I’d like to share some details about each.

Team growth

When Sandhills Development first started, I had no intention of having a large team and was very reluctant to ever grow the company to more than 5-8 people. Through the growth of our products, however, it has been necessary to increase the size of our team to fill ever-growing resource needs. At first I was leery to allow the team to expand beyond what I felt I could directly manage but over time I welcomed the challenges that are involved with doing so.

Today we are at 19 full time employees and one part time / variable time contractor on the software side of the business, and two full time and two part time helpers in the brewery. We’re preparing to bring on 2-3 more on the software side in the near term.

In March, 2018, we welcomed Tyler Lau full time to our marketing and administration team.

In May, 2018, we welcomed Daniel Goldak to our Easy Digital Downloads support team.

In May, 2018, we welcomed David Sherlock as a variable time contractor to our Easy Digital Downloads support team.

In August, 2018, we hired Jeordyn Hensly to help with retail sales in the brewery. Her role transitioned to brewing assistant and bar tender by October.

In August, 2018, we hired Jacob Unruh to work on the production side (brewing, packaging, cleaning) of the brewery.

In September, 2018, we welcomed Mihai Joldis to our Easy Digital Downloads and Restrict Content Pro support teams.

In October, 2018, we welcomed Mandy Jones to our marketing team.

In October, 2018, we welcomed Tunbosun Ayinla to our AffiliateWP development team.

In October, 2018, we welcomed Phil Derksen to Sandhills Development as a partner and product lead.

Each person that has joined us has been an incredible asset to the team and I’m proud and honored to have each of them working with us.

Sandhills Development team (Mihai not present), September 2018

In the next two-four weeks we plan to on-board three or even four new team members in various roles.

Sales and acquisitions

For the third and fourth time in recent years, I sold two of my earlier plugin products to new owners in 2018. These were products that had tremendous amounts of potential but were falling by the wayside under my control.

In February I sold Fullscreen Background Images to Scott Deluzio. This was one of my earlier products and one of my favorites for a long time. I think what I liked most about it was its simplicity and single purpose. It’s easy for plugins to grow beyond their original scope and become something far and away from the original intention. Fullscreen Background Images was a plugin that always stayed true to its original purpose and I really loved that.

In October I sold Simple Google Maps Shortcode to Gordon at Web Factory. This was another of my favorite plugins that I relished the simplicity of. It literally did one thing and one thing only: register a shortcode that displayed a map of any address.

Both of these plugins had a lot of potential for doing much more but managing them on top of our other projects was beyond my capacity, so I decided to sell off both plugins.

In 2017, when we closed the extension marketplace for Easy Digital Downloads, we purchased a large number of plugins from 3rd party developers and brought those plugins under our own management. That was my first experience negotiating purchase deals of that nature. This year I had another first: negotiating an acquisition and merger with another company.

On October 1, 2018, Sandhills Development acquired WP Simple Pay through a merger.

As we have grown over the years, I knew there was a distinct possibility large acquisitions would be in my future, either as the entity being acquired or the entity doing the acquiring. I’ve had a number of potential acquisition discussions over the years, mostly from parties interested in purchasing Easy Digital Downloads, but this was the first time I was on the other side of the table for a product worth more than $500,000.

I had been considering the possibility of purchasing another company / product for some time but had never landed on any definite targets. The acquisition of WP Simple Pay landed unexpectedly but was ultimately a perfect fit for everyone involved so discussions did not take long.

In May, Phil Derksen, the founder and owner of WP Simple Pay, approached me with a quick email:

Ironically, that email was sent a few minutes after we concluded a podcast / webinar episode on the topic of selling WordPress product businesses.

Phil went on to tell me how he felt he’d grown WP Simple Pay as far as he could solo and was ready to be part of a larger team. His options were to either build a team or join an existing team. Phil and I have known each other for close to ten years (we met very early on in both of our WordPress careers) and we’ve always gotten along great. We share a lot of values and ideals, both in our personal lives and in the way we build products.

We quickly agreed that WP Simple Pay and Sandhills Development could be a great fit, so we moved on to discussing ways to make a merger or acquisition a reality. There were a few possible avenues on the table:

  1. Sandhills Development could purchase WP Simple Pay outright, assuming full ownership of the product, and then employ Phil
  2. Phil could sell WP Simple Pay to Sandhills Development and then move on to do something else entirely
  3. Phil could transfer ownership of WP Simple Pay to Sandhills Development in exchange for cash and/or equity in the larger company

In the end we decided on the 3rd option. Phil was given a piece of equity in Sandhills Development in exchange for Sandhills Development assuming ownership of WP Simple Pay.

WP Simple Pay was incredibly attractive to me for a number of reasons.

The first was that it was led by someone I’d known and respected for a long time. Anytime you work closely with someone, you will get to know them really well. Ideally you get along great with the people you work with. Knowing that Phil and I already had a good relationship meant there was very little worry about culture and personality fit.

The second reason was that WP Simple Pay was already a successful product bringing in ~$25,000 / month with good profit margins. That meant the product was already paying for itself while being operated by a solo founder. With a few additional resources, it won’t be difficult to grow it to $30,000 and beyond.

The third aspect of WP Simple Pay I found attractive as a prospective acquisition was its position in the eCommerce ecosystem. It was successfully serving a niche of customers that neither Restrict Content Pro nor Easy Digital Downloads were fulfilling well, mostly due to the nature of those products and their complexity. By adding WP Simple Pay to our product portfolio, we are able to attract another customer segment, expanding our potential reach.

Revenue

Since writing my first year-end review in 2012, we have grown our revenue each and every year. In 2018 we continued that trend with an overall increase of 21.47% with a total income of $2,747,500. This was an increase of ~$500,000 over 2017 with a profit increase of 96.65%.

Of the $2.7, our break down between projects was roughly:

  • AffiliateWP: $1,170,405
  • Easy Digital Downloads: $900,609
  • Restrict Content Pro: $396,192
  • Sugar Calendar: $11,644
  • WP Simple Pay (Oct – Dec): $74,205
  • Brewery: $83,367
  • Misc (affiliate income, revenue shares, other): $90,346

There are a few items I’d like to go into more depth regarding revenue.

First, AffiliateWP became our first product to independently surpass a million in revenue in a single year. This was a milestone I was exceptionally pleased with and is a testament to the product we’ve built and the team behind it. Along with being our largest revenue generator, it’s also still one of the least difficult products to maintain and support. It’s incredibly stable and due to it’s stability and high volume, it operates on a ~30% profit margin.

The excess cash flow generated by AffiliateWP has enabled a level of flexibility for us that has been immensely valuable. It has permitted us to take risks, devote team members to new projects, and put efforts into places we wouldn’t have otherwise.

We have extensive plans for AffiliateWP in the next year and I’m really excited to share more information about those soon.

Second, Easy Digital Downloads saw a decline in revenue for the first time. Over the course of 2018, our average monthly revenue dropped from $73,500 to $70,500, with a peak at $83,000 and a bottom of $60,600. Note: I have excluded November from these averages due to the significant fluctuations caused by our annual Black Friday sale. In the first half of the year, we averaged $73,700 per month and in the second half of the year that average had dropped to $66,500.

This decline, while it may not look too terribly drastic, was excruciating to watch and deal with. On average we had a net operating loss of $10,000 every month for six months in a row. Out of the 12 months in 2018, seven operated at a loss ranging from $2,500 up to $20,800. At the end of 2018 we did manage to turn a small profit for Easy Digital Downloads but that was largely due to the influx of funds the annual Black Friday sale brings us.

There are a lot of factors we have considered as possible reasons for the decline in Easy Digital Download’s revenue, but they are mainly guesses. We’ve been unable to nail down one or even many definite causes. A few potential reasons include:

  • Natural age of a product. It’s possible we’ve simply hit our peak, though I don’t believe this.
  • We unintentionally out-priced our average customer. This is quite possible.
  • We face tougher competition than ever before. This is definitely a factor.
  • Something changed (such as traffic sources) but we haven’t identified it yet.
  • Business owners got spooked by GDPR and other stricter regulations of online businesses.
  • We have not succeeded well enough at updating our product offering to hold the interest and value of business owners.

While we are unsure of what 2019 holds for EDD’s revenue, we are fully committed to it and do believe firmly that we’ll be able to continue to grow above and beyond what we’ve done thus far.

The fourth item I’d like to cover is the $74,205 we added through WP Simple Pay. By acquiring a mature product, instead of building from scratch, we significantly increased the rate of revenue growth. Of course we also incurred the necessary expense to acquire the product and its team (Phil Derksen). Due to how the merger / acquisition was done, however, the cost had no direct impact on our cash flow nor cash reserves.

The $74,205 revenue that WP Simple Pay added was purely from October 1 to December 31st. With an average of $24,735 in monthly sales, WP Simple Pay will have a significant impact on our 2019 sales.

The fifth part of our revenue I want to mention in more depth is the $83,367 we earned through Sandhills Brewing. Last year my brother and I seriously entered into an effort to open a microbrewery in our hometown, and we succeeded. The brewery began operating in February, 2018, and opened to the public at the end of April, 2018. We started at $1,181.11 in sales our first month of operation and finished the year with ~$13,000 in December.

Note, some of the reported revenue for the brewery is from investment from Sandhills Development.

I’ll share more on the brewery below.

The final aspect of our revenue I would like to touch on is profitability. In 2017 I stated that one of my goals was to maintain the sustainable profitability that we had achieved. In 2018 I’m pleased to say we were able to hold strong and operated at a 19% profit margin.

This profitability gave us the flexibility to grow, invest, and plan for the future .

Content marketing

I began my career in WordPress with blogging. Early on I wrote multitudes of posts and articles, ranging from tutorials to opinion pieces to product launches. Writing content was integral to everything I did.

As the company grew, however, it became more and more challenging for me to write as frequently as I would have liked and my publication rate dwindled to almost zero. In the last year for example, I’ve published less than 10 articles.

Content marketing is something we’ve struggled with as a company for a long time. We never quite managed to figure out how to consistently produce high quality content on a consistent schedule. We tried again and again but never succeeded.

That is until this last year. At the end of 2017 we put together a content plan for 2018 that included planned content for several months at a time with specific people assigned to write the content. This worked really well but was still a struggle because it required everyone to find time in their already busy schedules to write the content. What it did, however, was pave the way and lay the foundation for a dedicated position in our team for the first time: content writer.

We hired Mandy Jones towards the end of summer to come on as our dedicated writer. This worked really well, not only because it raised the bar for how much content we could push out but because it also significantly lightened the load of the rest of the team that had been working extra hard to produce the content previously.

For the first time in a long while, we were able to publish consistent, high quality content across multiple brands.

Hiring a dedicated writer was an excellent reminder of how hiring the right person for the right role can have a significantly positive impact on a teams’ performance and work load.

Along with the content marketing efforts we pushed forward in 2018, we finally for the first time also managed to establish a real marketing department led both by Kyle Maurer and Lisa Gibson. As a developer at my core, I’ve always struggled with many aspects of effective marketing so it was never a part of the company I felt comfortable managing nor creating.

One of the beautiful aspects of building a team is seeing first hand the skills and values each team member can bring to the table. In 2018 Lisa and Kyle clearly demonstrated their marketing skills and made it clear how much value we could add by having a full-fledged marketing program.

Today we have four full-time team members working in marketing. By the end of the year I expect we will add one or two more.

Product updates

As usual, there are a number of significant updates surrounding each of our products throughout the year, and I’d like to share a few with you for each.

Easy Digital Downloads

At the end of 2017 we announced a plan for significant updates to Easy Digital Downloads in order to solve some large, overwhelming issues left over from poor early decisions. We originally estimated that we would be able to finish and release the update within the first six months of 2018.

Obviously that release did not happen as we are still yet to release 3.0 and it’s now more than a year past our original announcement. There are a bunch of reasons the release has taken longer, but the primary reason is that the project was simply way larger of an undertaking than we had originally estimated. It was extensive enough that it has taken more than a year of very active development by half a dozen developers to get it near beta ready.

We are now anticipating a beta being ready in the next 1-3 months and we are working to provide for frequent updates on our development blog.

Since we’ve spent so much of our development resources on the development of 3.0, many other areas of Easy Digital Downloads slowed down in 2018, though never to a stand still. We now have a better team than ever before and we’re able to keep continued focus on numerous areas of the product at all times.

As mentioned above in the revenue section, Easy Digital Downloads did see its first decline in sales in 2018. We tackled the problem from a lot of different angles, but two of the most visible are what we did with pricing (yes we changed them again).

In June we launched a new pricing model that introduced “access passes” for extensions. These were effectively memberships that granted access to certain extensions. The lower memberships granted access to more basic or standard extensions and the higher memberships granted access to the more advanced extensions. This is the direction we have planned to take Easy Digital Downloads for several years. We originally launched EDD with what came to be called the “extension model”, where advanced features are sold as separate plugins, each requiring their own purchase.

Over the years we collected extensive evidence to suggest that a la carte extension sales is not a great experience and, oftentimes, is too challenging and/or overwhelming for customers. The access passes we introduced in June were our solution to the problem by neatly packaging all of the extensions into a tiered membership setup.

Except it didn’t work.

We had already seen the model work wonderfully for AffiliateWP and Restrict Content Pro so we really expected the same model to work for Easy Digital Downloads too. After launching the new model, however, our sales continued to decline and they dropped enough that we were seriously concerned that we had just damaged them even further.

Ultimately we came to a conclusion on why the memberships didn’t work for Easy Digital Downloads: we had out-priced our average customer. Even though the membership options were offered at a significant discount over purchasing extensions individually, the price tag continued to scare people off. At least that is what we believed.

On August 1 we lowered the prices for extension passes. That change was difficult to make and not without challenges, but it appeared to have worked:

Aug 1 – Oct 31 compared to previous three months

We are still at a lower monthly revenue than at the beginning of 2018 but we are continuing to see improvements.

Restrict Content Pro

In 2018 we were able to raise RCP’s revenue by more than $60,000 over the previous year. We were able to achieve this by continuing development and significantly upping our marketing efforts for the platform.

Along with the content marketing mentioned above, we also leaned heavily on re-targeting advertising, both of which helped push the needle.

The main focus in 2018 for RCP was the completion of 3.0, which, like EDD 3.0, is a significant architecture adjustment with a re-designed database structure that improves performance and opens the gates for a large number of major features we’ve wanted to build for a long time. The previous database design prohibited a lot of important features.

Restrict Content Pro 3.0 beta was released last week and so far has been running smoothly. We’ll give it a couple more weeks before finalizing the release.

It took nearly a year to complete the 3.0 update, in part because of its size and complexity and in part because we had an unexpected team departure that took its toll on the project. More on that below.

Sugar Calendar

On March 13, 2018, I announced a new website and development focus for Sugar Calendar. The plan was to do with Sugar Calendar what we did with Restrict Content Pro, and that is still the plan that we are working on completing.

Due to a number of reasons, some in our control and some outside of our control, the development and release of the new Sugar Calendar has taken significantly longer than we had intended. Our intentions originally were to have the new version and a series of add-ons released in six months or less from the time of that announcement. That, sadly, has not happened, and we’re not proud of it.

Our communication of the delays that have occurred have also been less than stellar, and for that I want to apologize to each and every one of our customers.

The good news, however, is that we are still absolutely dedicated to finishing the project and I can now say with much more confidence that we are getting close.

We currently plan to release the beta of the new version on, or very close to, February 5, 2019.

AffiliateWP

AffiliateWP continues to be the most reliable and feature-rich affiliate marketing plugin available for WordPress. Through extensive integrations and wide support for all of the main eCommerce, membership, and form plugins, AffiliateWP has continued to grow and thrive.

We hit two milestones in 2018 for AffiliateWP. First, we broke the $2,000,000 mark in earnings, and second, we broke $1,000,000 in sales in a single year.

2018 saw an increase of $273,930 in revenue over 2017, with several months breaking $100,000 in earnings.

Even though we’ve had great success with AffiliateWP, we feel we’ve only scratched the surface and there’s so much more we want to build. We have extensive plans for the next 9-12 months and we can’t wait to share some of them. The first major initiative we’re working on is expected to launch into beta in the first or second quarter of 2019.

SellBird

We have been teasing SellBird for more than two years now. While it is still not ready to show you, I am thrilled to say we have made a lot of progress on the platform and are nearing our first beta phases.

SellBird has been one of the most interesting and definitely most challenging projects we’ve worked on. We’ve always had a general idea of what we wanted to build, but determining exactly how the detailed aspects of the platform behave really eluded us for quite some time.

The first year of working on SellBird was mostly us just picking around without really creating anything. A shotgun approach if you will. The second year of SellBird began to see a more specific target that permitted it to start taking shape. Finally after more than two years, we have a very clear goal for the project and progress is moving forward nicely.

WP Simple Pay

As mentioned above, WP Simple Pay joined the Sandhills family in October. Being our first experience bringing an existing, thriving product under our control, there has been some adjustment periods and elements of the merge that have gone slower than we’d like, but overall it’s gone very well.

We have worked to increase the development and marketing resources on the project and have been working towards merging support systems.

Towards the end of November we released the first major update for WP Simple Pay after adding more developer resources to the project. The 3.3 update introduced some significant new features that really helped extend the platform and give customers more control over the display and behavior of their payment forms.

In the next 12 months we will continue to devote significant developer and marketing resources to push the product further.

Sandhills Brewing

Anyone that has spent any amount of time with me in person, at conferences or other events, likely knows that I have a deep seated love for locally made craft beer. About three years ago my brother and I made a commitment to opening our own brewery as a passion project.

In February, 2018, we managed to complete the licensing process and were able to legally begin producing beer at Sandhills Brewing.

The brewery was a passion for both my brother and I and something we’d wanted to do for a long time. We both, however, had full time career positions running our respective companies that consumed the vast majority of our time. While neither of us knows what the long term future holds, we did both know that we were not ready to leave the digital world behind, so opening the brewery was in no way a career change. It was, instead, a way for us to realize several of our deep passions, namely creating specialty beers and building positive changes in our communities.

When we first opened to the public in April, we were set up to serve free samples and sell beer in sealed containers that customers could take home with them. We operated out of a very rough and minimal warehouse space for six months. It was very much a minimum viable product, but it worked.

We used the warehouse and the to-go sales to slowly fund the construction of our first taproom, which we managed to open at the end of October. The taproom is a place customers can come and sit down to enjoy a beer with friends and family. It was created to be a comfortable space designed for casual conversations and low key enjoyment of the wide array of beer styles we produce.

  • The taproom space we opened in October
  • Re-arranging barrels
  • My brother fixing a leaky barrel
  • One of our first canning runs
  • The original warehouse

The beer world is heavily regulated and nothing moves quickly. Anything that involves the state or federal government is measured in timelines of weeks and months, not hours or days, much less minutes or milliseconds. After building companies in the digital space where it’s easy to get antsy when a file download takes a few extra seconds, it was both agonizingly painful and refreshing to work within an industry that expects less rapid turn around times.

As I have detailed a few times before, I have faced a few significant mental challenges in the last few years while building Sandhills Development. Most recently I struggled with severe burnout. I found myself completely incapacitated and unable to find any joy in digital work. I was, and am, immensely proud of what we’d built and the team I’d assembled, but the day-to-day work of maintaining the company was draining my will to be in front of a screen.

The brewery ended up being exactly what I needed to re-discover my passion for WordPress and the web. I effectively took a six-eight month break from the digital world to build the brewery with my brother and in doing so, re-discovered my love for the web and the products we have been building as a team.

Along with helping me re-find a passion for the web, the brewery has given me an inordinate number of experiences that I’ve been able to turn into valuable lessons for the software side.

Sandhills Brewing is the brewery that WordPress built. Without the success of our WordPress-based products, Sandhills Brewing would have never happened. With that, if anyone reading this is a beer fan and finds themselves in Hutchinson or Mission, KS, come visit our spaces!

Interested in following along with our brewery journey? Follow along through our website or Instagram.

My personal trials and triumphs

I’m writing this while Molly and I prepare to welcome our third daughter to the world and it reminds me of how fortunate we are to have the family, friends, and support that we do.

On the personal side, 2018 was largely defined by three major experiences.

Opening Sandhills Brewing

First, as described above, my brother and I succeeded with a goal we’d had for a long time: open a brewery. Brewing has been a passion of ours since ~2012 and we have both yearned for side-projects that include more direct connection to the physical world and the communities in which we live. Sandhills Brewing fulfilled both criteria superbly. It has given us a chance to work with our hands (we did the majority of our own construction, remodeling, and equipment installations ourselves) and it has enabled us to have a more direct connection with the people in our community.

Within less than a month of opening, the brewery’s taproom quickly became a gathering spot for many groups of friends and families. Each weekend, when the taproom is open, we see people come in, sit, and enjoy the space and beers we’ve created. They smile, laugh, and cheer. Unlike in the digital world, nearly every interaction we have with customers is a positive experience. We are part of their celebration and it’s immediately obvious how distinct the juxtaposition is to our digital interactions, which typically revolve around a problem that needs fixed.

For the first time ever, I have a sense of purpose and belonging in my local community. It used to only be a place I lived, now it’s a place I feel a part of and one I want to help thrive. And we’re now working on repeating the process by opening our second brewery and taproom in Kansas City.

The Sandhill Prairie Farm wild fire

The second major experience occurred in March, right as we were in the middle of getting the brewery’s production up and running. Prairie fires are not terribly uncommon in Kansas, like other drier parts of the world. While we’ve had close-calls with fires in the past, my family has never dealt with the destruction of a direct hit. That is until March 14, 2018, when a prairie fire lit by an arsonist tore through my parent’s property, destroying everything in its path. Everyone that was in the house when the fire approached escaped unharmed, though it was an incredibly close call for my father who rushed to turn on sprinklers and hoses to try and save the house. The fire moved so quickly and within minutes it was on all sides of the property, cutting off the road and escape route. He was forced to drive across pastures to escape.

That was quite possibly the longest, most trialing day of my life, but also one that strengthened family and neighborly bonds. The number of people that came to our aid to help with cleanup and restoration was deeply humbling. When I first got the call from my dad to tell me about the approaching fire, I immediately jumped into our team’s Slack channel and left a simple message:

Emergency. Parent’s property on fire.

My team did not hesitate and immediately understood what that meant. Aside from the obvious, it was clear and known that I would be unavailable for an undetermined amount of time. The whole team stepped up and took care of everything, many of them even offering to drive across the country to come help with cleanup.

I’ve never been more grateful nor proud to work with my team.

The fire, while terrible, gave me a greater appreciation for the relationships we build. Ultimately family and friends, and the bonds we nurture with those people, are more important than anything else we can possibly build.

Possible acquisitions and a team departure

The third major experience of 2018 was perhaps a culmination of four others: struggling with mental burnout, building the brewery, the wild fire, and then losing one of my most senior team members.

In my 2017 review I described the experience of re-discovering my role within my own company. I continued to struggle with motivation throughout much of 2018, even though I now had a better idea of where I fit in. Building the brewery gave me new purpose and was an opportunity to take a much-needed mental break. The wildfire helped me recognize the importance of relationships and the power and strength of a great team. Then two more series of events happened.

In the course of two-to-three months, I was approached by not one, not two, not three, but five different companies interested in potentially acquiring all or part of Sandhills Development. These conversations, while not entirely new to me, came at a time I was feeling vulnerable but also potentially motivated to sell. I’d just gone through a traumatic family experience that made me relish the idea of having fewer business obligations, I was actively involved in building the brewery, and I was mentally burnt out from the digital world. Each of those made me consider the possibility of walking away more than ever before.

In the middle of those conversations, a metaphorical bomb dropped.

John Parris, one of my longest-term team members, a shareholding partner, most valuable contributors, and a great friend, called to tell me he needed to leave the company.

Early on in John and I’s working relationship, we were sitting in a brewery enjoying dinner and a beer when I asked him what he really wanted to do in the next few years. I’ll never forget what he told me:

I want to run your company while you go make beer.

It took a lot of guts to say something like that to the CEO of the company, and I loved it. It showed me that John was confident, motivated, and as determined as I was to build Sandhills Development into something great.

John was a huge supporter of the brewery efforts, not just because he wanted me to follow my passions but because he understood the importance of diversifying our revenue streams, and he saw tremendous value in the company building physical presences that have the potential to outlast each of us.

I believed John to be one of my most solid pillars in the company, but then he left unexpectedly, and it rattled me to the core.

Like me, John had been struggling with mental burnout and was needing a change of scenery. That just so happened to coincide with a large WordPress company’s recent acquisition creating a position for John that landed in his lap unexpectedly. It was too good of an opportunity for him to turn down.

The month proceeding his phone call to me became one of the most difficult I’ve ever experienced in my leadership tenure for this company. I felt lost, angry, betrayed, and overcome with an overwhelming sense that I had lost control of my company. I was tormented with the thought that my efforts to build the brewery and my struggles with mental burnout had culminated in the initial signs of the demise of my company. I barely slept, worrying that I would be forced to choose between leading the brewery and leading the digital team.

I began to consider more than ever the possibility of selling my company. Being blindsided with the departure of a team member that I believed would never leave, made me really wonder “what if?”. I knew that selling my company would afford me enough financial freedom to not need to worry about money. I also knew that selling my company would give me unbridled freedom to pursue passions I haven’t been able to focus on.

I also knew, however, that selling the company at this stage would leave me with an overwhelming sense of abandonment. I felt that I had just been abandoned by my partner so how could I do the same to the rest of my team? While acquisition conversations never got as far as discussing a price, the moment I recognized that selling would cause me to abandon my team, I knew my way forward, and it did not involve selling the company.

I don’t blame John for needing to leave and I’m proud to have worked alongside him. I’m thrilled for him to have found a new way to exercise his skills and passions and wish him nothing but the best. Ultimately I recognized that it was likely my own inaction that lit the fire leading to his departure.

Recognizing where my own failings or inaction caused John to leave has given me tremendous motivation to prevent that from happening again. In retrospect it was probably an event that needed to happen eventually in order to drive the necessary changes within Sandhills Development as a company.

2019 and beyond

2018 had significant wins for several of our products and from a revenue / profit perspective and, while not everything went great, I feel I’ve learned and grown more as a CEO this past year than ever before. Based on what we’ve learned as a team and what we already have in motion, I suspect 2019 will be our best year yet.

We try to avoid setting major year-long goals and instead to focus on smaller, more short-term goals that we can more easily measure and achieve. We do, however, hope to achieve the following in 2019:

  1. Raise overall revenue to $3,500,000
  2. Release Sugar Calendar 2.0 and a series of Pro add-ons that helps raise its revenue to $20,000 / month
  3. Launch SellBird.com and begin generating revenue through it
  4. Hire between 3 – 6 new team members
  5. Launch an affiliate payouts service for AffiliateWP
  6. Formalize more of our processes and the company structure / operations
  7. Continue to increase revenue and expand the platform for each of our products

Cheers to years past and those yet to come 🍻!

The post 2018 year in review appeared first on Pippins Plugins.

Posted on

WP Simple Pay joins the Sandhills Development family

I am excited to share that WP Simple Pay has joined Sandhills Development.

WP Simple Pay, led by Phil Derksen, launched four years ago with the goal of offering a simple way to integrate Stripe payments into WordPress. It has stayed true to its goal and continues to be an excellent way to process payments and subscriptions with Stripe.

Since 2013, the team at Sandhills Development has worked to build the best products we can in eCommerce, membership, affiliate marketing, and other verticals. While doing that we’ve learned a lot about what we do well and what we’ve done poorly. We’ve also learned very well the kinds of customers our products work for and those that they’re not quite suited for. We’ve found the gaps and strengths in our offerings.

WP Simple Pay is a product that perfectly fits into several of the gaps in our offerings, so by bringing WP Simple Pay into Sandhills Development, we can do much better at offering our customers the solution that best fits their needs, whether it be complex digital eCommerce or simple payment processing; full-blown memberships or just quick and easy monthly payments.

Phil and I first got to know each other near the beginning of our WordPress product journeys six or more years ago and have consistently communicated since then. We’ve shared strategies, ambitions, and challenges in master mind groups, over many dinners, and frequently consulted each other as we built our products. Phil’s products have used Easy Digital Downloads and AffiliateWP for years and his experiences and feedback from doing so have contributed great value back to me and my team.

As of October 1, WP Simple Pay is now being maintained under the Sandhills Development umbrella. Phil has joined the Sandhills Development team where he will continue to lead and work on WP Simple Pay as well as other projects.

What will change

As with any merger or acquisition, customers may be uneasy and worried that the tool or team they love will change. We fully recognize why that uneasiness happens and want to reassure everyone that the changes that will be made in the next few months will be positive for all.

At first, very little will change. The product will still be led by Phil and the same support team will continue offering top-notch support. We will make a few minor branding updates to bring the product in line with our existing products.

Being part of a bigger team now, WP Simple Pay will receive development, support, and marketing resources from Sandhills Development. After the initial merge and everything is settled in, this will allow us to continue growing the tremendous product Phil has built, and push it even further.

We are really excited to be working together and cannot wait to begin sharing the results of our combined efforts.

The post WP Simple Pay joins the Sandhills Development family appeared first on Pippins Plugins.

Posted on

Simple Google Maps Shortcode plugin has new home with WebFactory

In October, 2012, I released a plugin called Simple Google Maps Shortcode. It was a very simple plugin that simply registered a shortcode that could be used to display a Google map of any address on a post or page. The plugin was simple, efficient, and did just the one thing very well. Overtime it grew to more than 10,000 active installs and is still actively used on thousands of sites. Today I’m happy to announce that the plugin has a new home and has been acquired by WebFactory.

Gordan has already released a few updates for the plugin and plans to continue developing it into a more powerful solution for site owners to add Google maps to their sites.

Among other things, Gordan plans to release updates to introduce the following:

  • A GUI for creating/customizing the final map display
  • A detailed explanation and help guide to assist site owners with generating a Google Maps API key, necessary after the recently announced pricing and billing changes: https://cloud.google.com/maps-platform/user-guide/pricing-changes/
  • New support for custom pin images
  • New support for custom fields, ie [map]$custom-field-with-address[/map]

This acquisition brings WebFactory’s portfolio of Google maps plugins to three. Along with Simple Google Maps Shortcode, Gordan also developers and maintains:

I have known Gordan for a long time and have complete confidence in his ability to deliver superb results.

The post Simple Google Maps Shortcode plugin has new home with WebFactory appeared first on Pippins Plugins.

Posted on

New website and branding for Sugar Calendar

Today I’m really excited to announce the launch of a new, dedicated website for Sugar Calendar! Say hello to sugarcalendar.com.

This is the first in a large series of updates we are working on for our sweet and simple event calendar plugin for WordPress. In the coming months you will see new features released, improved interfaces, numerous add-on plugins, and a whole lot more!

Back in November, 2017, John James Jacoby joined my team at Sandhills Development specifically to work on Sugar Calendar. With the skills and experience that John brings to the table, we will be elevating Sugar Calendar  from a small, simple event calendar plugin to a full-featured event platform. Work on this is in progress and a lot of updates will be coming out in the near future.

John and I have both spent considerable time building and maintaining our own event calendar plugins so with our combined knowledge and experience added to the vast wealth of skills at Sandhills Development already, we should be able to deliver a really good platform.

While we are working on the updates, we need to ask a small favor of existing customers. As part of the migration to the new website, we have regenerated all license keys and account records on sugarcalendar.com. In order to ensure your site(s) stays up to date with the latest versions, please follow these steps:

  1. Update to Sugar Calendar version 1.6.6 from within WordPress like any other update.
  2. Reset your account password at https://sugarcalendar.com/account using the same email address you purchased Sugar Calendar with.
  3. Once updated and logged into your account, please retrieve your new license key and update your site(s) that use Sugar Calendar with it. This is the license key you will use from now on.

That’s it!

With the launch of the new site, we also have an affiliate program available that you may join. Help promote Sugar Calendar and earn a commission on every sale!

If you have any questions or issues, do not hesitate to reply to this email or send us a support ticket from the new support page.

P.S. The upcoming updates will include a price change. Upgrade to or purchase an Ultimate license now to lock yourself into the low price forever.

The post New website and branding for Sugar Calendar appeared first on Pippins Plugins.

Posted on

Full Screen Background Images Pro acquired by Scott DeLuzio

Full Screen Background Images Pro is a plugin I first built seven years ago that allows site owners to easily configure background images on their site that scales automatically based on the browser size. As one of my earlier plugins, I’m thrilled to announce that it has a new owner and home. Last week, Scott DeLuzio and I came to agreement for him to take over sales, development, and support of the plugin.

The plugin can now be found at https://fullscreenbackgroundimages.com/.

I am really excited to see Scott take the plugin further by adding great new features and bringing it up to date with today’s standards and expectations. If you have previously purchased the plugin, or are considering purchasing it, rest assured that you are in excellent hands with Scott.

To help ensure the transfer goes smoothly, let’s address some commonly asked questions for acquisitions like this.

Do customers that purchased from Pippin’s Plugins still get updates and support?

Yes! All customers will get support and updates directly from Scott for the duration of their license key. For example, if a license was purchased from pippinsplugins.com on June 1, 2017, that license will be valid for support and updates from Scott until June 1, 2018, at which time it is then necessary to purchase a renewal from https://fullscreenbackgroundimages.com/.

Can customers log into their account at the new website?

Once all customer accounts have been migrated, yes. Expect an email from Scott in the coming days with instructions on how and where to log in.

Can expired license keys be renewed at the new website?

Yes. Please contact Scott through the new website if you need any assistance in renewing an expired key.

Who should customers contact for help, Pippin or Scott?

Contact Scott through the new support page.

If you have any questions, comments, or concerns regarding the plugin or the acquisition, feel free to leave a comment below or get in touch with Scott or I directly.

The post Full Screen Background Images Pro acquired by Scott DeLuzio appeared first on Pippins Plugins.

Posted on

2017 in review

As is my tradition at the end of each year, I’d like to share experiences, failures, and successes from 2017.

Previous year in review posts: 2016, 2015, 2014, 2013, 2012.

Personal

From a personal perspective, there’s a number of things from 2017 I’d like to share, including accomplishments and challenges.

Moving to a new home in the Kansas Sandhills

Of everything that happened in 2017, there is one single highlight on the personal side of things: getting acreage outside of my city. In June, my wife and I noticed a property for sale three miles north of Hutchinson, KS, where we live. It had 11 acres comprised of woods, tall grass prairie, and plum thickets. Aside from a number of Cedar trees (an invasive species), the property was mostly pristine Kansas Sandhills that had never (to our knowledge) been farmed.

I grew up unschooled on an apple orchard my parents operated and the property included about 100 acres of trees and open prairie. I have longed to be back in the country away from the city ever since I moved away from my parents’ home. I consider my time growing up, free to be a wild child, some of the most important and formative years of my life and I want my children to have the same freedom and opportunities to explore and learn as I did. I hope for them to develop a deep love for nature through being immersed in it every day as I was.

After thinking about it for a week or two, we decided to jump on the chance of getting our own small plot of land. We put an offer on the property, which included a good house, and had it accepted less than 72 hours later. The next month was a whirlwind of getting everything in order, including selling our previous home. We had anticipated the possibility of it taking months, or even a year, to sell our house but were pleasantly surprised to have a solid offer on it in less than 10 days, which we accepted.

Moving to our new home was not free of challenges, especially as far as internet access was concerned, but after getting settled in everyone was thrilled. No place has ever felt more like home than where we are now and I’m eternally grateful to have had the opportunities and good fortune necessary to get here.

Building greenspace

Along with achieving a long-term goal of moving back into a rural setting, 2017 gave me an opportunity to move forward with another of my hopefuls: purchasing land to convert into greenspace and prevent the complete overtaking of concrete that was inevitable for the area. Shortly after completing our new home purchase, I also finalized the purchase of a vacant, 3 acre lot in our city for the sole purpose of creating a nature area.

I wrote about this briefly on my personal blog.

There is still a lot of work to do on it, which I’ll be beginning later this winter and I look forward to including updates on my progress in followup year-end-review posts.

Part of preparing the property for tree planting and other green developments involves keeping it mowed. During the spring and summer I will be mowing it every other week and it takes me about 2.5 hours to finish. I’ve found it as a great opportunity to sit (on a mower) and think for 2-3 hours. It’s actually a rare opportunity, the option to sit and think for extended periods of time. At first I thought I would want to hire someone to mow it for me but I’ve found the time to myself and my thoughts to be exceptionally valuable.

Between spending long periods of time on my bike and mowing the park, I’ve found the time with just my thoughts to be some of my most productive for working through hard challenges. Originally I thought I would want to get rid of any and all “dead” time, now I cherish it.

Re-discovering my role within my own company

On at least four separate occasions I have sat down to write a blog post on how I have lost my role as the lead developer of my WordPress products. As I have continually brought on immensely talented individuals to join my team, I have successfully hired myself out of my primary job: writing code.

This was an entirely intentional transition that, all things considered, worked spectacularly. It has allowed me to step wholly away from the development of our products and focus instead of other areas of the business. What I had not anticipated, however, is the effect this move would have on my personal motivation.

I so successfully hired myself out of my job that I often found myself unsure of what I should do. I frequently found myself sitting in my office monotonously going from easy task to easy task while trying to find my purpose again.

As a solo founder, the beautiful thing about bringing highly skilled team members on board is that you are then given the flexibility to put your own focus and efforts where they are most needed or most valuable. The downside, however, is that you also tend to find that you are no longer needed by your team to complete the task you used to be solely responsible for.

My presence is no longer needed for an update to one of our products to be completed and released. I am no longer needed for customer support. I am no longer needed for our marketing efforts. It is no longer necessary for me to review every line of code that’s written. Most of the company administration tasks no longer depend entirely on me. Obviously my presence and focus on projects and around the company is still immensely valuable, but the profound effect that a lack of need has on a solo founder’s motivation and drive can be intense.

I have always been really good at taking care of things that need to be done, whether I enjoy the specific task or not. I was completely caught off guard by how much not being directly needed was able to undercut my motivation and drive to continue pushing forward.

Getting the company to a place where I am no longer needed is one of my best accomplishments as it takes care of a huge problem that many solo founder companies face: the bus factor. If I am struck by a bus tomorrow, or disabled in any way, I can rest assured that the company will continue to succeed, and that has been one of my long term goals, one which I’m thrilled to have succeeded at.

I simply did not anticipate the effect that protecting against the bus factor would have on my personal motivation.

I never did succeed in finishing my blog post on the subject of losing my role as the lead developer, but I did over time manage to rediscover my purpose with the company. That allowed me to find my source of motivation again and gave me a new drive to succeed and push us further and further forward.

The last 12 months have been an incredibly interesting journey. I never thought I’d be struggling to find my motivation when the company was thriving better than ever before.

The mind is a fascinating beast.

Team growth

When I first began building my company I had no intention of ever having more than 3-5 employees. Growth, though, has a habit of adjusting your plans in ways that may not be expected. In 2017 four new team members came on board and several moved from part time contractors to full time.

Ginger Coolidge joined to help with AffiliateWP support and documentation.

Ashley Gibson moved from a part time contractor to full time team member to work on Restrict Content Pro development.

Kyle Maurer moved from a part time contractor to a full time team member to work on Easy Digital downloads support and marketing.

Tyler Lau joined to help with billing support and social outreach.

Phil Johnston, previously a part time contractor, joined us as a full time team member to work on Easy Digital Downloads development and support.

Keri Jacoby joined to help with Easy Digital Downloads support and internal company documentation.

John Jacoby joined to help with development across all products and to help re-launch the next leg to our product table, Sugar Calendar.

We also said goodbye to several teammates. Between the ones that left and the new ones that joined, our team size remained about the same as 2016. 13-16 between full time employees and part time contractors.

The Sandhills Development team currently includes thirteen full time, salaried members and three active full to part time contractors.

Team photo from our company meetup in Keystone, Colorado

My team is the core of the company. Without them we are nothing and for them I am eternally grateful.

Team focused decisions

Throughout the year, and at the tail end of 2016, my team and I made a number of strategic decisions that all had a singular core goal: doing what is best for the team and the company.

Depending on who you ask, these decisions were supported, loved, applauded, chastised, and hated by many. I have been told quite a few times this past year that I am making excellent decisions that really convey the strength of the team I’ve built and of my leadership skills. I have also been told by numerous individuals that I am the scum of the earth, I am ruining the open source nature of WordPress, and my business will fail.

As anyone that continues to work online does, I have grown a pretty thick skin and am not terribly phased by people calling me a greedy criminal or a despicable person. Each time it happens I try to pause and do my best to understand why someone has this opinion of me. Are they right? Is there truth to what they’ve said about me? Regardless of how right or wrong anyone is, being the target of such accusations has made me very reflective and cognizant of the choices I make for my company.

Perhaps the most important lesson I’ve learned from the choices we have made, some of which I will detail below, is that it’s critically important for the health and wellness of my team to be put first on the list of priorities. This is for a very simple fact: if we are not well nor happy in life or work, we will never excel at making our customers happy. This understanding has become the pivot on which all company decisions are now based.

Is it good for us? If not, we do our best to find an option or route that is. Decisions that promote better health and wellness for the team automatically carry over to the promotion of better experiences for our customers.

Price changes

There were several adjustments to our product pricing in 2017, and one in 2016 that had its effects realized in 2017.

  • Easy Digital Downloads prices increased significantly in December, 2016
  • AffiliateWP prices increased in March, 2017
  • Restrict Content Pro prices increased in March, 2017
  • Renewal discounts removed from AffiliateWP in March, 2017
  • Renewal discounts removed from Restrict Content Pro in March 2017
  • Renewal discounts removed from Easy Digital Downloads in September, 2017

The price increase for Easy Digital Downloads was easily the most contentious of the decisions made. While most people supported the reasons for the change, there was a very vocal minority that vehemently hated us for our decision. I am a firm believer that it is not necessary for the vast majority of companies to have any justification for the prices they charge.

Whatever price chosen is perfectly acceptable, even if some argue the price is extreme. The reason for this is simple: free markets permit companies and individuals to make their own choices on the prices they charge. Beyond that, the “correctness” of the price can be gauged by how customers respond to it and how it affects the sustainability of the company. Too high and the company fails to attract enough customers; too low and the company fails to generate enough revenue. So long as both needs are met, the chosen price works.

A number of individuals made it very clear to us that they felt we’d made a terrible decision with our Easy Digital Downloads price increase and, in no uncertain terms, expressed how our mistake would be clearly realized in our financial failure. I have no wish to discredit or demean their opinions, but I will say this: increasing our Easy Digital Downloads prices is one of the single best decisions we have ever made. It has contributed almost single handedly to a complete turnaround of Easy Digital Downloads’ future. In previous years I have expressed how we felt Easy Digital Downloads was a sinking ship. Today I’m happy to say it is thriving and in a better position than ever. This turn around is something that should greatly reassure Easy Digital Downloads users, even those that were unhappy with the price change, as it is what will permit us to continue building, maintaining, and improving the platform.

The price increases for AffiliateWP and Restrict Content Pro were also very successful in allowing us to operate more freely and have given us a lot more ability to invest back into the further development of the products and company.

Closing the EDD marketplace

In September, 2017, my team and I made the decision to close down the extensions marketplace we operated for Easy Digital Downloads. This was the marketplace that allowed 3rd party vendors to sell their EDD extensions through our website. We had been working on slowly reducing the number of 3rd party plugins that we offered through the site over several years already but it was going to take a considerable amount of time before the process was completed at the pace we were going.

While working through the logistics of introducing some price and sales model changes for EDD, we encountered a number of challenges that were a direct result of our site selling 3rd party extensions. It had already been decided that the changes we wanted to make were really important to the longevity of Easy Digital Downloads as a platform and as a business, so we began looking at the feasibility of discontinuing our marketplace and removing all 3rd party extensions.

After a few weeks of analyzing, thinking, and talking, we quickly discovered that shuttering the marketplace was pretty feasible and would likely not result in too much discontent. Doing so, however, would have significantly positive affects on the future of Easy Digital Downloads.

In order to fully close the marketplace, we needed to get rid of, in one way or another, every plugin that was owned by a 3rd party developer. Getting rid of them really just meant that the plugins needed to be removed from the site so that only our own extensions remained. We decided that one of three things would happen to each of the 3rd party plugins:

  1. It could be transferred off-site and distributed through whatever mechanism the author chose so long as it was not our site.
  2. It could be discontinued entirely.
  3. It could be acquired by Easy Digital Downloads and left as-is on the site.

While our site did not have nearly as many extensions for sale at the time as it once had, there were still a large number of plugins to be managed. In total, 55 plugins needed to be moved off, discontinued, or acquired.

Of the 55 plugins, we chose 37 that we wished to acquire and take over full ownership of. These were plugins built wholly or in part by 3rd party developers that had performed well or had strong potential for the future. For these plugins we determined what we felt was a fair price and then we reached out to each of the owners and made them acquitision offers. The vast majority of authors were thrilled with the prospect of selling their plugins and quickly accepted our offers.

18 of the 55 plugins were determined to be ones that we no longer wished to sell on our site, so these were either discontinued or moved to a place of the author’s choosing, their own site or a marketplace such as CodeCanyon.

Once we decided we were going to acquire the plugins and close down our marketplace, it took just about four weeks to complete the entire transition. After all was said and done, we spent $145,000 purchasing extensions. All extension purchases were paid for in cash with the exception of one, which was put onto a payment plan spanning four months. This was a move made possible by our price increase at the end of 2016. If we had not done that, we’d never have been able to afford purchasing so many plugins in such a short period of time.

A number of very interesting things happened as a result of our choice to acquire all extensions and close down our marketplace.

First, there was a palpable sense of relief and satisfaction among the team. Working closely with 3rd party developers and selling their products through your own site can have mixed experiences, sometimes good and sometimes bad. Most of the developers we worked with were great. They were responsive to bug fixes, welcoming of feature requests, and all around just good to work with. Others were less good for various reasons but regardless of how good someone is to work with, there are inherent challenges that come with working alongside outside developers. By acquiring all of the plugins, we removed all of the challenges that the 3rd party plugins posed to us, thus eliminating significant sources of stress and tension for the team. The effect that this had on everyone was very noticeable in the team’s moods and focus.

Second, by removing 3rd party plugins, we eliminated a significant monthly expense. Each month we paid out between $8,000 and $15,000 in commissions to 3rd party developers. As soon as there were no more 3rd party commissions to track, all of that revenue started going straight back into the company instead of being paid out, which then provided extra flexibility and safety nets. Through the savings of having significantly lower expenses we easily have the opportunity to hire more development resources and invest back into the improvement of the platform.

Third, we reduced our support load. Some of the extensions that were acquired had had long-term issues that were not being taken care of adequately. By taking over control of the plugins we were then able to immediately push out a large number of updates to extensions to resolve some long-standing bugs and problems. We were also able to further reduce support loads by discontinuing some of the plugins that were low sellers or simply not worth the time and effort it took to maintain them.

Overall, I would consider the decision to close our marketplace and acquire all of the extensions to be one of the single best decisions we’ve made in the last few years.

Firing

Twice in 2017 I found myself in a position where I needed to fire a team member. Bluntly, those were two of the hardest experiences in my professional career. Hiring the right people is hard, but I’ve come to find that firing people is perhaps harder.

Going through the mental exercise of firing someone is exhausting. You worry about how the person will react. Will they be angry, understanding, sad, unmoved? You worry about whether they will be okay in the coming months. Do they have funds set aside to get them through a period of unemployment? Do they have something else lined up? You worry about how the rest of the team will react to the news of one of their team members leaving. Will that make the others worry for the safety of their own positions? Will it cause rifts or resentment within the team? You worry about the company’s performance. Will firing this person harm your ability to deliver on promises to customers? You worry about what they will think of you. Will this person hate you for firing them? You worry about their family. Do they have children to support and will they be able to provide for their kids when their paycheck is cut off?

Firing someone you’ve worked with for multiple years is an absolute whirlwind of emotions. Nothing about it is easy. The objective side of the brain knows the choice you’ve made is the right one, but the emotional side struggles. It is obvious when a person is not performing, is not meeting quality requirements, is a poor fit for the team culture, and other issues, but those do not make it any easier to overwrite the human element when you care for the person and their wellbeing.

Realistically, I know I will have to fire someone again in the future, and probably more than one, but I dread the prospect of it. Having gone through the experience twice in a year has made me much more cautious about the hiring process and how we vet possible candidates. No system will ever be perfect but we will work harder to ensure those people we do hire are the right fit.

Revenue

2017 treated us well, largely in part to the strategic decisions we made throughout the year and earlier in 2016. Overall we saw a 53% increase over 2016 with a total of $2,268,000.00 in revenue.

Our 2017 revenue can be broken down as such:

  • Restrict Content Pro: $333,000.00
  • AffiliateWP: $901,000.00
  • Easy Digital Downloads: $946,000.00
  • Other: $94,700.00

Our revenue increase came from three primary factors:

  1. Raising our prices
  2. Automatic license renewals
  3. Natural growth

The most interesting of these three is the automatic license renewals, so let’s take a deeper look at those stats.

Revenue from automatic license renewals

In the first quarter of 2016 we implemented automatic renewals for license purchases. This meant all license keys purchased automatically renewed with a payment on the annual anniversary of the purchase date. As this change was made in 2016, it wasn’t until January and March 2017 that we began to see the effects of it.

In my 2016 review post, I said that enabling automatic renewals was “one of the most important changes we made for the sustainability of the company”. Today I am completely confident that turned out to be true.

Let’s take a quick look at our license renewal stats for 2017.

Easy Digital Downloads

In 2017 Easy Digital Downloads saw $309,000.00 in revenue from license renewals. 2016, in contrast, only had $139,850.00 in revenue from license renewals, so we increased our renewal revenue by more than $150,000.00. And that revenue increase was not from an increased marketing effort nor natural growth, it was simply due to the difference between automatic and manual license renewals. Here’s a graph that illustrates the effect automatic renewals had very clearly:

Screenshot from 2018-01-04 15-50-19

Look at the change between March and April. The first automatic renewals began being processed at the end of March, 2017. It more than doubled the number of renewals we see every month.

Out of the $309,000.00 in renewal revenue, $208,000.00 came from automatic renewals. The rest was from manual license renewals for customers that did not have automatically renewing subscriptions.

AffiliateWP

Similar to EDD, AffiliateWP saw an increase in monthly renewal revenue as soon as automatic renewals kicked in, which happened in the second half of January, 2017.

In 2017, AffiliateWP brought in $201,000.00 in revenue from license renewals. Of that number, $181,500.00 came from automatic renewals. In contrast, 2016 had just $62,700.00 in license renewal revenue, so automatic renewals increased our renewal revenue nearly 3x by itself.

A graph showing renewal growth from Jan 2016 to December 2017:

Screenshot from 2018-01-04 16-37-03

Restrict Content Pro

Like Easy Digital Downloads and AffiliateWP, Restrict Content Pro also saw a nice boost in revenue due to automatic renewals.

In 2017, we brought in $59,750.00 from license renewals. Of that, $44,780.00 was from automatic renewals. This is a pretty significant increase from 2016 where we saw just $23,700.00 in renewals.

Here’s a visual of our renewals over 2016 and 2017:

Screenshot from 2018-01-04 20-18-52

Enabling auto renewals is easily one of the best financial decisions we have made.

SellBird

A project we’ve slowly worked on over the last two years, SellBird is beginning to take shape. We’re still a few months have having an MVP ready but it is getting closer.

I’ll have more to share on it in a couple of months but for now, here’s a screenshot from one of the dashboard views.

image.png

Follow @SellBirdHQ for updates.

Sugar Calendar

One of the earlier commercial plugins I launched, Sugar Calendar was built to be a simple, lightweight event calendar plugin for WordPress. While never a major success from a revenue stand point, the plugin has done decently well over five+ years.

Much like Restrict Content Pro, I’ve wanted to more fully develop the plugin into a full-fledged product for quite some time but had not managed to do that on my own.

Read about the effort to re-build Restrict Content Pro here.

I had originally partnered with another developer to try and move the plugin forward. That effort and partnership, unfortunately, fell through and did not produce nearly the results I had hoped for. It failed due to a number of reasons and no single person carries the blame for the failure.

In October, earlier this year, I decided it was time to restart the efforts to build out Sugar Calendar into a full-fledged product. To do this, I partnered again with another developer to aid in the efforts. This time I chose John Jacoby, whom began the process of modernizing the codebase and expanding the feature set of Sugar Calendar. At first it was decided it would be a possibly short term experiment to see how it worked. By early November, however, we’d already decided it was meant to be. JJJ joined my team as a full time member in December to continue his work on Sugar Calendar and other projects.

When the new version launches, it will see a price change and a new series of add-ons introduced. All current customers will have their license keys migrated to the new website and those customers that have purchased multi site versions will see complimentary access to new add-ons granted to their account.

There is still a lot of work to be completed before we’re ready to launch the new Sugar Calendar but we’re getting closer and closer each day. You can follow @sugarcalendar on Twitter to stay updated.

Achieving sustainable profitability

There several things I am deeply proud of with my company.

  1. We have never missed nor skimped on payroll due to financial inflexibility
  2. We are 100% self-funded and have never taken on loans nor any other kind of financing out of necessity
  3. We have always been profitable

Those three facts mean a lot to me and continue to be pillars of every decision I make for the company.

I say that we’ve always been profitable, but that doesn’t mean we’ve always had comfortable profit levels. We’ve had a couple of years where our profit was only a few thousand dollars. That means very, very little when your monthly expenses surpass $100,000.

The choices that we made in 2016 and 2017 were aimed at moving us towards a number of goals, but one of the most important was targeting sustainable profitability.

What do I mean by sustainable profitability? I view it as a level of monthly and yearly profit that allows a company to:

  1. Be financially stable and able to weather downturns in revenue
  2. Have adequate resources to make strategic investments
  3. Have the ability to bring on new team members to fill needed roles at any time
  4. Be financially able to pay all employees greater than a living wage
  5. Be financially stable enough to allow less liked or neglected revenue streams to be removed
  6. Have adequate cash reserves to permit the company to survive in the case of catastrophe

In 2017 we achieved sustainable profitability. I do not know for certain that we’ll maintain it throughout 2018 and beyond but I am confident we are on the right path to long term sustainable profitability.

Insulating the company

Our greatest strengths are our greatest weaknesses.

I’ve spent a lot of time with nothing but my thoughts in the last two years and these periods have led me down a number of mind paths, many that went nowhere in particular, but there is one that I kept coming back to.

What do I want in the next 25 years?

As I’ve gone through the various ups and downs of the previous years, I’ve thought on numerous occasions that it might be time for me to sell my company and move on. The prospect of this really bothered me though. I knew that if I were to sell my company I could likely walk away very comfortably and I don’t doubt I’d be able to find a new owner that would continue to take good care of it, but I couldn’t get past the prospect of leaving my team.

The people that comprise my team are some of the best individuals I’ve ever met and many go beyond just teammates. they’re lifetime friends that I hope to always stay connected with.

The thought of selling my company has always ended with my team. Many of them have told me that if I go, they go, and that they’d happily follow me onto the next thing, whatever it might be.

Coming to understand the quality of the team I’ve built helped me to find the answer to my question: what do I want in the next 25 years?

I want to build a lifetime company.

I don’t want to spend 8 years building software products, sell it, and move on. As common as it is to hear of founders doing that, it’s not for me.

I first realized that I wanted to build a lifetime company after the owner of a local business I had hired to do a project told me their average employee tenure was more than 25 years. It astounded me that any company today could hold onto employees for so long. I want that! I want to know that we have so successfully taken care of our people that they never want to leave nor need to.

One of the first steps in building the lifetime company is insulating us from our biggest weakness: me.

I have worked hard in the last few years to remove dependency on me for the company’s operations. The next step was to protect against myself for decision making and succession.

If I fall off a cliff tomorrow, I want to know that my company and my team are going to be okay. Doing that meant I needed to no longer go it alone; I needed others to have clear roles in my succession.

In September, 2017, I made four of my team members full partners by giving them a combined 25% of my company.

This move helps to insulate the company from me in the case that I become unfit to run things. It also allows me to reward Sean, Chris, Andrew, and John in a small way for the important role they have all played in getting us to where we are today.

Brewery development

At the end of 2016 I declared one of my 2017 goals was to brew my first batch of commercial beer for Sandhills Brewing, a passion project my brother and I have been working on. We didn’t quite get there but we got very close.

For those that do not know, my brother and I have been working on opening a commercial brewery as a side project for the last several years. That work is getting closer and closer to having something to show for it.

A few highlights from our brewery development:

  • We helped another local brewery brew a small test batch using our equipment. This test batch was sold through their brewery and was well received.
  • We partnered with the same local brewery, Three Rings Brewing, in order to provide them with a barrel aging warehouse and our own expertise (my brother and I’s) with barrel aging beers.
  • We completed the majority of the build phase for our brewery.
  • We submitted our licensing application to the federal government and hope to receive our approval in early 2018.

Once we have had our application approved and have completed a few smaller, easier local and state license applications, we’ll be able to begin brewing commercially. At this time we expect that to happen sometime during the first quarter of 2018. If all goes well, we’ll sell our first 100% independently produced beer by summer 2018.

A nice example of the beer to be brewed by Sandhills Brewing

It’s been a great year and I really look forward to what 2018 has in store for us.

Cheers!

The post 2017 in review appeared first on Pippins Plugins.

Posted on

Discontinuing memberships on Pippin’s Plugins

Six years ago I announced the launch of premium memberships to Pippin’s Plugins for access to advanced tutorials, code reviews, and other member-only benefits. I have been continually humbled by the response and support my memberships received from the WordPress community and I would like to sincerely thank everyone that signed up. Today, however, I have discontinued memberships to this site.

My ability to consistently produce new material and to provide code reviews like I used to has continually waned as the product side of my business has grown. For a long time I held onto the hope that I could find a way to get back to consistently producing new content for this site but a small part of me has known that is unlikely to ever happen, and so I have made the only right decision available: close down memberships.

Effective today, memberships have been discontinued on this site and all existing memberships have been cancelled to ensure no existing members are billed again. If you are a member and signed up within the last 30 days, contact me and I will be more than happy to provide a full refund.

NOTE: this does not refer to Restrict Content Pro. That product is still actively maintained and developed at https://restrictcontentpro.com.

All previously restricted tutorials are now open to everyone. Please learn, grow, and enjoy!

The post Discontinuing memberships on Pippin’s Plugins appeared first on Pippins Plugins.

Posted on

Automatic license renewals: twenty months later

About twenty months ago, while sitting on a couch in Auckland, New Zealand, my team and I flipped the switch to enable automatic renewals for AffiliateWP. Two months later we did the same thing for Easy Digital Downloads and Restrict Content Pro. This was a move that we had been working towards for nearly a year and it’s one that we believed would fundamentally change the position of the company over the next one to two years. Now that it has been twenty months, maybe we can answer the question: were we right? Did it make a significant impact for us or was it all futile hopes?

Historically we, like many other online product companies, have struggled with low renewal rates. All of our products are sold with annual licenses that should be renewed each year so long as the products are in continued use. Renewal revenue is a critically important part of growing any online business because it reduces the expensive process of customer acquisition. Your revenue isn’t purely a factor of how many new customers you obtain, it’s a combination of your new customer acquisition and your existing customer retention. If you have great customer retention, you can grow your annual revenue year after year without having to rely on increasing the number of new customers acquired year over year.

Our goal with implementing automatic renewals was three-fold:

  1. Reduce friction and effort for customers. Easy systems == happier customers.
  2. Increase renewal revenue by reducing the number of “forgotten” renewals.
  3. Provide a predictable revenue stream we could rely on and adequately forecast against.

Let’s start determining if we were successful by looking at some previous year stats.

Easy Digital Downloads

Here are some quick stats on our previous years with Easy Digital Downloads:

  • Total revenue in 2014: $474,622.54
  • Total revenue in 2015: $561,269.06
  • Renewal revenue 2015: $80,799.26
  • Total revenue 2016: $597,352.61
  • Renewal revenue 2016: $139,850.03

In 2015 we brought in $80,799.26 in renewal revenue. That’s revenue from existing customers that renewed their license keys. This number means only 14.4% of our total revenue in 2015 came from renewals. Ouch. While $80,000 isn’t a small number and is a nice addition to our annual income, it’s abysmally small when you recognize how few customers were coming back and purchasing renewals.

Our 2016 renewal revenue was higher at $139,850.03 but still only accounted for 23.41% of our total revenue that year.

AffiliateWP

For AffiliateWP, we have pretty similar patterns between 2014 and 2016.

  • Total revenue in 2014: $119,651.50
  • Total revenue in 2015: $379,078.36
  • Renewal revenue 2015: $19,774.60
  • Total revenue 2016: $491,890.90
  • Renewal revenue 2016: $62,827.80

For 2015, our renewal revenue accounted for only 5.22% of our total annual income. This is super drastic, though it does look worse on the surface before realizing part of the reason the renewal revenue was so low was because 2015 saw incredible growth for AffiliateWP. We more than tripled our 2014 revenue by bringing in a lot of new customers so our new customer acquisition was rapidly out pacing our existing customer base from 2014.

In 2016, we saw $62,827.80 in income from renewals, accounting for 12.77% of our revenue that year.

Restrict Content Pro

Again, Restrict Content Pro shows pretty similar patterns of abysmally low renewal income ratios.

  • Total revenue in 2014: $67,211.75
  • Total revenue in 2015: $83,806.60
  • Renewal revenue 2015: $10,460.30
  • Total revenue 2016: $157,486.89
  • Renewal revenue 2016: $21,706.60

In 2015, we brought in $10,460.30 from renewals, accounting for 12.48% of the year’s revenue. And in 2016 we saw $21,706.60 in renewals, or 13.78% of the total revenue that year.

Easy Digital Downloads in 2017

Automatic renewals for Easy Digital Downloads were enabled on March 30, 2016, which means the first payments to be processed by the resulting subscriptions would occur on March 30, 2017. This is important because it means the first three months of 2017 had the same manual renewals as previous years. Based on speculations, automatic renewals should dramatically increase the amount of revenue that comes from renewals.

Did it?

  • Total revenue so far in 2017, January 1 to August 1: $463,835.92
  • Renewal revenue so far in 2017, January 1 to August 1: $166,716.98
  • Revenue from auto renewals in 2017, March 30 to August 1: $90,297.20

Thus far, 35.94% of our Easy Digital Downloads revenue has come from renewals. That’s 12.53% more than in 2016, so a really good sign that automatic renewals are having a significant effect.

Of the $166,716.98 in renewal revenue, $90,297.20 of it was from automatic renewal payments processed with subscriptions. So 19.47% of our total revenue in 2017 has come from automatic renewals. That’s pretty good on the surface, but actually it’s really good. Why? Simple: automatic renewals didn’t start processing until the beginning of the second quarter of 2017 and yet it has already accounted for nearly 20% of our total yearly revenue.

If we look at March 30 to August 1, the time period that automatic renewals have been processing, we see that renewal revenue accounted for 38.72% of our revenue.

Here’s a graph that shows monthly license renewals for 2017. Can you see the point when automatic renewals began processing?

AffiliateWP in 2017

Automatic renewals for AffiliateWP began processing on January 21, 2017, so most of 2017 has included automatic renewals, unlike Easy Digital Downloads and Restrict Content Pro.

  • Total revenue so far in 2017, January 1 to August 1: $443,996.90
  • Renewal revenue so far in 2017, January 1 to August 1: $101,453.35
  • Revenue from auto renewals in 2017, January 21 to August 1: $89,686.40

22.85% of our 2017 revenue has come from renewals, and 20.2% was from automatic renewals. Just 2.65% came from manual renewals.

In 2017 we have had $101,453.35 in renewal revenue. In 2016 we had just $62,827.80. We’ve nearly doubled our renewal revenue and there are still four complete months left in 2017. Obviously some of that increase is due to natural growth, which we’ve continued to see for AffiliateWP, but it’s still a significant increase that I believe is largely attributed to automatic renewals.

If we exclude the first 20 days of January, we find that renewals have accounted for 24.20% of our revenue in 2017.

Here’s a graph showing license key renewals over time for AffiliateWP:

I don’t think I need to point out when automatic renewals were enabled.

Restrict Content Pro in 2017

The numbers for Restrict Content Pro in 2017 do share similarities with the other two products but it has one significant difference that needs to be noted. Throughout 2016 and 2017, one of our primary focuses has been to revitalize Restrict Content Pro and bring it back to a strong position within our product portfolio. I’ve written about these efforts and the results so far previously. I mention this because much of the growth Restrict Content Pro has seen in the last 20 months can be attributed to automatic renewals and extensive revitalization work.

  • Total revenue so far in 2017, January 1 to August 1: $184,686.45
  • Renewal revenue so far in 2017, January 1 to August 1: $28,503.85
  • Revenue from auto renewals in 2017,  March 30 to August 1: $16,165.80

In 2017, 15.43% of our revenue has come from renewals. 8.75% of that was from automatic renewals. This is an increase over previous years but not too terribly drastic. It is, however, still significant when we recognize that automatic renewals did not begin processing until the beginning of the first quarter of 2017.

If we look at March 30 to August 1, the time period that automatic renewals have been processing, we see that renewal revenue accounted for 19.22% of our revenue.

The graph below shows the growth of license renewals overtime. There is a pretty distinct increase in April that continues through the end of July. That increase is the result of automatic renewals.

Wrap up

I think the numbers mostly speak for themselves and really show that automatic renewals are having a significant impact on the financial state of the company. I look forward to seeing whole-year numbers after we’ve had automatic renewals processing for more than just a few months.

Restrict Content Pro’s 2017 revenue has already passed that of 2016, AffiliateWP is less than a month away from beating 2016, and Easy Digital Downloads is two months away from surpassing 2016. There are still four complete months left in 2017 and one of those includes our historically best month: November.

We need to make an important note here regarding the price increase we did at the end of 2016 and early 2017. The price increase did not affect any existing subscriptions, so the majority of the renewals we’ve seen so far in 2017 have been at the previous, lower price. So even though our renewal revenue is mostly at a lower price point than new sales, the percentage of the total that renewals account for is still significantly higher that it was previously. Once we are seeing the majority of renewals come in at the new, higher price, we’ll see even more significant results.

There are a number of really excellent effects automatic renewals have contributed to, but there are two in particular that I would like to highlight.

First is the ability to reliably forecast our expected revenue month-to-month. We now have a reliable data set that provides us with much more accurate predictions for future revenue, and that is incredibly valuable, especially when making decisions about company investments and weighing risks.

Second is our profit margin. One of downsides to increasing revenue through new customer acquisition is the added support and development burden that entails. The burden of adding $10,000 per month from new customers is not minimal at all. In fact it can be a real challenge. One of the reasons companies hire new employees is to help meet the demand brought on by the new customers. This often creates an endless cycle of growing your expenses as quickly as your revenue. Adding $10,000 to your monthly income doesn’t make much difference if you also add $10,000 in new expenses each month simply to help manage that new $10,000 you brought in.

Renewal revenue, however, doesn’t require the same maintenance that new revenue does. In other words, if we earn $100 from a new customer, it is likely that we will have to spend $80 helping that customer. If, however, we earn $80 in renewal revenue from an existing customer, we most likely won’t spend more than $20-30 helping them, if that. The reasoning is simple: renewing customers cost significantly less because the maintenance for them has already been done.

Existing customers are so much cheaper than new customers, so it only makes sense that we should do the very best we possibly can to increase the revenue generated from those existing customers. If we do that, our profit margins will get better and better, and that is precisely what we have seen.

Our previous years have all been profitable in the end, sometimes not very profitable but profitable nonetheless. 2017, however, has seen a completely new trend. We are not only showing profit every month, we are showing monthly profit that is greater than all previous annual profits, and we’re seeing it every single month but one so far. Which month didn’t see that level of profit? January, right before automatic renewals began taking place. Coincidence? Absolutely not.

I’ve previously mentioned that I believed transitioning to automatic renewals would likely be one of the best things we ever did. Today I’m more confident of that prediction than ever.

Posted on

Reflection on a price increase

On December 14, 2016, my team and I pushed a significant change to our Easy Digital Downloads products: we increased the price on all extensions by 50-250%. Yes, you read that right: up to a 250% price increase on certain plugins. This change was done for a number of reasons, which I will get into shortly, and has resulted in a very interesting last three months. Since I have always been very open with my company’s financials, I would like to now share some reflections on the change that we made and to also share some of the aftermath of the change.

The backstory

Since the beginning of Easy Digital Downloads, and I imagine many products, customer support has always been our biggest challenge. Taking care of customers is hands down the most difficult job in the company. It is ripe with challenging problems to solve, long hours, relentless flows of new tickets, on-going conversations that spread not only over days but even weeks and months. Providing good and, when possible, great customer support is, to put it simply, exhausting.

There have been many times over the last 5-7 years where I thought to myself I’m sick of this; I just can’t keep taking care of these people, maybe I should quit. I have had those thoughts and every member of my team has had those thoughts. On one particular evening back in November, I was sitting on my couch doing my best to work through a not-abnormally sized support queue, and it hit me: this has to stop. This wasn’t the first time I (and many other members of the team) had spent insane hours working through support queues, nor was it the 50th time. Working late to help finish support requests is an every single day occurrence. It literally never stops. This time, however, I had had enough (fifty times too many) and decided it was finally time to take drastic measures to reduce support. I hopped into our Slack channel and told my team this and within a few minutes we’d made a decision: it was time to increase prices. It was past time, actually, but late is always better than never.

When a company is faced with an over burdensome support load, there are a number of ways that most companies look to address it:

  • Fix the bugs that cause problems to happen that then result in support tickets
  • Improve UX so customers better understand how to achieve certain results
  • Write more and better documentation
  • Hire more support team members
  • Move team members from non-support roles to support roles
  • Outsource support
  • Release fewer updates
  • Release more updates
  • Remove problematic features / products

All of these methods are 100% viable and our team has implemented all of them. There is, however, another method that people tend to gloss over or ignore, and it is perhaps one of the most effective of them all.

To lower your support load, all you need to do is have fewer customers.

It may seem like the opposite of what most companies want, after all customers are the people that make it possible for companies to pay their bills and their team members. Without customers, companies cease to exist.

The real answer to lowering support burdens is to have fewer but more valuable customers.

On that evening in November, my team and I decided it was time to try and drastically reduce our support burdens by dramatically raising prices, thus reducing the number of customers while simultaneously increasing the average value of customers. Theoretically this would allow us to keep our revenue about the same (which was just barely covering our monthly expenses) or, if all goes well, raise our revenue and lower the total number of support tickets we received each month.

That was the hope anyway.

The change

We threw a lot of numbers back and forth while discussing the possible changes we’d make to pricing. In the end we had several goals:

  • Raise the average customer value
  • Lower the number of customers, thus lowering the number of support requests
  • Keep overall revenue steady or raise it

Due to the sheer number of plugins sold through easydigitaldownloads.com, there were a lot of different price points. We sold plugins as low as $6 and as high as $149. Our primary plugins were priced at $29, $49, and $82, and just one was priced at $149.

As a general rule, we came up with the following guidelines on picking new plugin prices:

  • Plugins that power fundamental aspects of a store, such as licensing, multi-vendor marketplaces, subscriptions, etc, would be priced at the top tier of $199. These were previously priced between $82 and $149.
  • Plugins that are priced at $49 (mostly payment gateways) would be increased to $89.
  • Plugins priced at $29 (email marketing plugins and some other miscellaneous plugins) would be increased to $49.
  • Plugins priced between $12 and $19 would be increased to $29. This was determined to be the lowest price point we’d offer.
  • Bundles, such as the Core Extensions Bundle and the Digital Marketplace Bundle, would be increased according to the new value of the plugins included in the bundle.

In some cases, this resulted in plugins having $10 added to their price tag, and in others the increase was as much as $117.

The results

There are a number of statistics we can look at to help gauge the effectiveness of our price increase and we’ll go over those shortly, but there’s a non-scientific metric I want to look at first.

Team happiness and morale.

I do not need a psychology degree to tell you that the price increase has significantly affected the happiness and day-to-day mood of the team. For more than 12 months, our team has been faced with the problem that is Easy Digital Downloads. Yes, I mean that: the problem that is Easy Digital Downloads. You see, EDD is seen around the WordPress community as this great plugin that is wildly successful and a model to look up to in the commercial plugin ecosystem. While this is a reputation that we take great pride in, the honest truth of the matter is our team has struggled with EDD for months because in many ways it has felt like a sinking ship. We’ve seen stagnated revenue growth (even declines), higher-than-ever maintenance costs, relentless support queues, and a whole series of other challenges that our other two primary projects (RCP and AffWP) simply do not have. In comparison to EDD, those projects are cake walks.

The price increase has been enormously successful in making the team feel good, and the importance of that should never be ignored.

Support tickets

One of the primary results we needed to see in order for this change to be successful was a significant decrease in support tickets. It has now been three months since the price increase, so how’ve we done?

  • New tickets submitted: down 0.2%
  • Total tickets handled: down 43%
  • Total customers interacted with: down 35%
  • Conversations per day: down 42%

The total number of tickets submitted barely changed, but the other three statistics are incredibly significant. A 42% decrease in the number of tickets handled each day. That means EDD handled 10-15 fewer tickets every day, which translates to a considerable less amount of time spent working on tickets for our team. We have an average handling time of 5 min and 49 seconds per ticket, meaning we have removed one to one-and-a-half hours of support work per day by increasing prices.

Assume, for a moment, that we pay $25 per hour for support technicians. Removing 1.5 hours per day equates to approximately $37.50 in savings each day, or, when extrapolated out, approximately $13,687 per year in reduced support costs (if assuming zero volume change).

Revenue and sales

Along with a decrease in support burdens, we hoped the price increase would also provide a much needed boost to our monthly revenue. As mentioned in my 2016 in review post, Easy Digital Downloads operated at a loss for much of 2016, so increasing our revenue was an important measure on the success of the price increase. If we managed to decrease support and increase revenue, we’d consider it a home run.

To gauge the effect the price increase had on revenue, I decided to compare three different time periods:

  • January to February, 2016
  • August to September, 2016
  • January to February, 2017

These time periods are good representatives of our average revenue as they do not include any special promotional sale periods and they allow us to compare similar periods from before and after the price adjustments.

The summaries below provide a good overview of the revenue statistics for each of the time periods used for this comparison.

January to February, 2016:

  • Sales (including free): 3,861
  • Refunds processed: 106 – $8,765.40
  • NET revenue: $100,530.39
  • Average order value: $28.31
  • New paying customers: 664
  • Average value for new paying customers: $131.30

August to September, 2016:

  • Sales (including free): 3,930
  • Refunds processed: 74 – $4,454.95
  • NET revenue: $100,262.55
  • Average order value: $26.65
  • New paying customers: 565
  • Average value for new paying customers: $116.57

January to February, 2017:

  • Sales (including free): 3,009
  • Refunds processed: 65 – $7,530
  • NET revenue: $114,376.70
  • Average order value: $40.57
  • New paying customers: 373
  • Average value for new paying customers: $154.95

There are a few primary changes I’d like to highlight here. First, notice that the NET revenue increased by ~$14,000 in 2017 compared to the two 2016 time periods. With that NET increase, however, the total sale count decreased significantly, by more than 800 in fact. This also resulted in our average order value increasing from $28.31-26.65 to $40.57.

The total amounts refunded also possibly suggest that higher value customers are less likely to request a refund, perhaps because they do more ample research before committing than lower value customers.

This change also caused our average customer value (for brand new customers) to jump up to $154.95 from $131.30 and $116.57.

We are only part of the way through March, but the numbers are already looking even better than January and February. This is partly due to the promotional sale we ran for the end of winter, 2017. We shall see if the remainder of March and April hold up with the trend so far.

The price change has also had an interesting effect on commissions amounts that we pay to 3rd party vendors. In 2016, we paid an average of $16,000 per month to 3rd party extension authors. For February and January, this average has dropped to a little over $12,000 per month. While this is not an overly positive change for most extension vendors, it is a change that we see as an overall positive change for our company. This change primarily happened because of a decrease in the total sales, though it is also due in part to us reducing the number of 3rd party products we sell through the site. We have repeatedly learned just how difficult running a multi-vendor marketplace is and, as a company, we’ve determined that is not something included in our long term goals so we have continually worked to reduce the number of 3rd party vendors we directly work with. I hope to share more on various changes we’ve made over the years that have affected vendor commissions soon.

When combining the increase in revenue with the decrease in support burdens, this price change has so far appeared to be incredibly positive for us. It is a single move that might just be one of the most important changes we have ever made.

Customer response

Gauging the success of a price change based on customer reactions provides some really interesting insights. Using customer satisfaction as a metric, however, is something you must be careful with. In much the same way that star ratings tend to highlight the most unhappy and, oftentimes, unreasonable customers, the customer reactions to price changes typically show those customers that are the most unhappy. It’s unfortunately rare to hear from the happy customers or those that support your price change.

Within hours of pushing the price change live, we received our first reaction from a customer that who been considering a purchase during the time we were updating the prices:

Can you please confirm what is going on? How price jumped to the sky in a matter of seconds, I’m client of you and want to include multi-vendor option, it is even an effort to invest those 91 USD.

That reaction is fully reasonable, especially if he’d already added the items to the cart (our system could not account for already-in-cart items).

The second reaction we received:

Did the price of the Recurring Payments plugin really increase from $83.00 to $199.00 since January?? This was an unpleasant surprise. :/

Technically this was true, though with a brief explanation from Sean, her reaction completely turned around:

Awesome. Thanks for the explanation. I’ll look forward to exploring the features.

This customer did end up completing her purchase and has not contacted us since.

So within a few hours, we’d had two negative reactions but one of them turned into a positive experience for both parties. Over the next few weeks, we continued to receive emails from customers reacting to the price change. Many customers, interestingly, asked if the price increase was some kind of error.

Is there an error on your website or did your price in the last week just over double in cost? I was looking at making a purchase when I just did a refresh and saw the huge price increase.

We knew we’d get a decent amount of  flack for our price increase, especially as we chose not to alert customers (new or old) of the price increase before it happened. Whether this was the right choice or not, it was one we made intentionally. We felt there was a good chance that publicly mentioning our price increase before it happened would simply provide a place for people to pile negativity on us, and it would create a permanent record of that negativity for others to stumble upon. Doing it silently was like ripping the bandaid off in one fell swoop. It’s done, it hurts, but then it’s forgotten a short time later.

I still don’t know if doing it silently was the right choice, but there were numerous customers that were irate because of that particular decision. One person’s response was perhaps the most difficult to stomach. They started out perfectly reasonably:

I am in the process of renewing my plugin licenses again, everything looks good but I noticed that you’re now charging $199.00 (139.30 discounted) for Software Licensing? What is up with that?

I paid like $42 last year and certainly can’t afford to shell out $140 or more every year for a plugin. Not to mention the additional $40 every year for the other EDD plugins I’m using…

Please, tell me that a 200% price increase is some kind of mistake..

To that I gave a calm, collected, though perhaps too generic response, which really did not go over well, as can be seen by his reply:

Wow, so calm and collected.

Well, regardless of what YOU think about it:

1) It’s a 350% price increase (!!!)

2) It’s called gouging the customer

3) It’s called betraying all those people who got on board for 350% less, thinking that, even if the price increases, it will remain an affordable deal despite the annual renewals

4) You should grandfather existing customers at the original price instead of screwing them over

5) I expected much more from you, Pippin.

6) Maybe it’s time to create a similar competing plugin, sounds like it’s a very lucrative market, and would be much less expensive than getting screwed for a 350% price jack.

7) You won’t get away with it

8) It was a horrible decision

9) Even if I do renew this year, I’ll be looking for a complete replacement of the very overpriced EDD plugin suite that I have to keep paying for, over and over and over and over again.

10) Raising prices by 5%, 10%, or even 25% is reasonable. 350% is just greedy.

11) Do your current customers get 350% more value? Nope. They get the same old thing, only YOU benefit.

12) This list will be the outline of my next blog post

13) A textbook example of a bad move, how not to raise prices, and how to screw over your customers.

Seriously unbelievable move. I was all on board with you guys. Not anymore.

350% price jack = unbelievable gouging of your “valued” customers.

I could go on and on, but I’ll save it for the post.

I have had a fair share of people throw derogatory remarks my way, but this one was a bit different. This felt incredibly personal because it came from a person I’ve respected and looked up to for a long time. In fact, this response came from one of the very first people I looked up to in the WordPress community. Having them express their extreme displeasure at my decision to raise prices and method with which we chose to implement the change was painful.

It should be noted that we did grand father in all customers that had an active subscription (one that automatically renews). The only affected customers were those with manual renewals and new customers.

When you get these kind of reactions, it’s important to keep a fact in mind: companies do not need to justify their prices.

Perhaps the most telling thing from all of the reactions we received was just how horribly undervalued Easy Digital Downloads (and similar platforms) are in many customers’ minds. Here we had a customer that was seriously unhappy about paying $140 per year for plugins that provided the functionality they needed to operate their own store. Previously this customer had paid just $42 per year to run their store with EDD.

I’ve had friends, colleagues, and advisors tell me our prices have been too low for years, and I couldn’t agree more. It is absolutely crazy that we’re more accustomed as a society to pay $5 for a latte from Starbucks, which we will consume in a matter of minutes, than we are to pay $12-$20 per month for platforms that allow us to operate our businesses. We are accustomed to paying $80-$100 per year for subscriptions to Netflix and Hulu but we react with revulsion and disgust when a company asks for $150 per year to provide software that businesses literally rely on to bring in their own revenue. In the United States (where the customer above lives), we’re used to paying $50-$100 per month for cable TV subscriptions, but we expect software to be provided for so much less.

As a world, we are better at paying for things that rot (figuratively and literally) our insides than we are paying for things that help us provide for the health and wellbeing of our families and employees.

This disparity in pricing expectations is asinine. Unfortunately, huge companies like Apple and Google have perhaps single handedly helped to create this through the rock-bottom prices of their respective app stores. Between the 1980s and early 2000s, it was common for video games, which take hundreds of hours to create, to cost $40-$50. This price was normal and expected. Once the app stores rolled around, however, expected prices dropped so low that companies now get practically eviscerated if they try and charge just $10 for a full length game in the Android or iOS app stores.

Quote from a review of Super Mario Run:

With a £7.99 price tag, Super Mario Run certainly isn’t cheap, but it’s easily one of the best smartphone games around.

Isn’t cheap? Seriously? It’s roughly the cost of just two lattes or one-three pints from many pubs, both of which are gone within a matter of minutes.

It’s high past time software providers charge appropriately based on the value they provide. If we cannot even ask for a decent price, how can we possibly continue to build platforms that power the web and the world around us?

My final reply to the angry customer was lengthy and has served as a good sounding board as I worked through this reflection post. I ended with:

Perhaps our definition of “appropriate” is different, but the last time I checked, EDD provides me (with the ability to run my stores) far more value than any monthly TV subscription or coffee service. Would I pay $500-$1500 per year to operate the stores that provide for my family and employees?

Absolutely.

Perhaps it was my explanation of why we chose to increase prices so severely or perhaps it was the price disparities provided that convinced this customer, but they did end up sticking with us.

Thanks Pippin.

This makes sense, I understand where you are coming from.

I went ahead and upgraded. The renewal discount always is appreciated.

Thanks for the great response. Enjoyed it.

Going forward

At this point, we are very happy with how the price change has worked out for us and Easy Digital Downloads. We were happy enough, in fact, that we decided to implement a similar price increase on Restrict Content Pro and AffiliateWP, which went live on March 1, 2017, just a few weeks ago. We did end up making some adjustments to how we rolled out those price changes and so far the changes appear to have worked well. It is too early to tell just how effective they will be, but we are confident that it will prove to have been the right choice in 3-6 months.

Do you have thoughts or reactions? I’d love to engage with you in the comments.

Posted on

Sugar Event Calendar 1.6 released

Sugar Event Calendar, my simple event calendar plugin for WordPress has just received a large update that resolves a few long-standing issues and introduces several new features, including category filtering of calendars, better mobile display, improved event list widgets, and several new calendar display types.

This release has been a collaborative effort between myself and Daniel Espinoza, who joined me to work on Sugar Event Calendar back in August of 2015, when we released the last major update to the plugin.

New calendar views

By default, the calendar of events will show full-month views that includes all of the events occurring during the month, like the screenshot shown below:

Some sites, however,  wish to show calendars with smaller date spans, such as one or two weeks at a time, four days, or even a single day. In 1.6, we have added support for the following date ranges:

  • Month (default)
  • Two weeks
  • One week
  • Four days
  • One day

Those views look like this:

Responsive mobile display

Sugar Calendar has always been pseudo-responsive and would adapt reasonably well to small screens. In 1.6, however, we’ve gone all the way and created truly responsive displays for all calendar views to ensure people viewing an event calendar from a small screen will be able to easily read and view the event information.

Better event list widget

Included in Sugar Calendar is a widget that can be added to any widget area that permits site administrators to display a list of upcoming and/or past events. This widget has always been pretty minimal of options so it was not always suitable or flexible enough for many sites.

In version 1.6 we’ve added several options to the widget to give site administrators better control over the exact information that is displayed. These new options include:

  • Option to show / hide event titles
  • Option to show / hide event date
  • Option to show / hide event time
  • Option to show / hide event categories

These new options are accompanied by the existing options that include:

  • Number of events to display
  • Categories of events to display
  • Display of upcoming and/or past events

Category filters on calendar views

The calendar display has supported showing just events from specific categories for a long time, but this option has always been limited to a shortcode parameter, meaning the site administrator was the only one allowed to control what categories were displayed. There was no way for a site visitor to filter the calendar by category.

With version 1.6, we have added a category drop down to the calendar view so site visitors can filter the calendar down to just specific categories. For sites that have a lot of events and categories, this will make it easier for site visitors to locate the events they’re looking for.

Bugs addressed

Also in version 1.6, we have addressed a number of long-standing bugs. These include:

  • CSS files did not include proper version numbers
  • Event titles could not include HTML
  • Recurring events not shown in the proper order
  • Recurring events not listed in “Upcoming Events” widget

Updating to 1.6

This update is available free-of-charge to all customers that hold a valid license key and can be installed directly from the Plugins page within the WordPress admin. The update can also be downloaded manually from your account page.

If your license has expired and you wish to update to version 1.6, your license can be renewed from your account page.

If you do not yet own a license key, a new license can be purchased from the product page.

Posted on

2016 in review

It is that time of year again! As in years past, I like to look back on the previous twelve months and see how we did. In this year’s review, I will share revenue numbers, challenges, achievements, insights, and more about my business building and selling WordPress plugins.

Previous year in review posts:

There are a lot of great things that happened in 2016, but it was also easily one of the most difficult years I can remember in my adult life. 2016 put before me challenges and decisions I did not expect. For the most part, each of the challenges was overcome, though some of them are still being battled with, and I believe I’m a better person and a better business owner for having faced them. I’ll talk more on the challenges below.

Team

When I started this plugins business 5-6 years ago, I never envisioned I’d have a team working with me, much less a team of 15!

I started bringing on people to help me with customer support in 2013 and doing that was easily one of the best things I’ve ever done. One became two, two became three, and now we have 16 members (counting myself) of the Sandhills Development team. These 15 are comprised of full time and part time team members and represent a mix of support agents, developers, marketers, writers, designers, and do-it-all’ers.

We are distributed across five countries and eight timezones. While we have not managed to achieve anywhere near a gold medal in diversity, we’ve done reasonably well and it has been an intentional focus for me this year and the time to come. I’m proud to say that of the six team members we brought on in 2016, four of them were women from three different countries. Sadly of the men on our team, only three are non-white males. I hope to improve that ratio in the future.

We have a long ways to go before we’ve achieved proper diversity, but we’re moving in the right direction.

Our team grew in 2016, though we also said goodbye to several team members. One team member joined us briefly for a few months, allowing them to get back on their feet, but then moved on after being offered a full time position at an excellent company. Another team member departed on mutual terms after we found the relationship simply wasn’t the right fit for both parties.

Running a 16 person company is easily one of the most challenging jobs I’ve ever worked, and hands down the most rewarding at the same time. It’s strange to me most days because it’s something I never expected. I have always been a do-it-myself person but at some point that began to change. Perhaps it was a greater appreciation for the skills others have that surpass my own or perhaps it came about with the desire to work less than 18 hours per day.

My team work incredibly hard and deserve so much more than I can give them. I may have started this business but the success we enjoy today is from the work they have done and continually do every day.

To each of you, sincerely, “Thank You!”.

Personal

I have spent a lot of time just thinking in 2016. For the past few years I have worked, worked, and worked and rarely took the time to really think about what I truly want to achieve and do in the next 5-10 years.

The first half of 2016 had a lot of personal struggles for me. I went through several phases where I felt I was on the brink of depression and really struggled to find joy in the days. I spoke briefly on this at Pressnomics 4 in Phoenix.

After a while I was able to work through some of the challenges I was having but it was an important reminder to myself the importance of caring for myself. As much as I’d like to, I simply cannot forget to take care of me. After realizing this, I began to spend a lot more time figuring out what I really wanted out of the next few years.

One change I was determined to make was to work less. I love my work, but I equally and more greatly love many other things in my life. This wasn’t necessarily the driver that led me to hire more team members but it has certainly affected how long it takes before I decide it’s time to hire a new person when our team is facing scaling or expertise challenges. I often forced myself to work longer and longer hours, and give up on other things I love, in order to get everything done, but I’m no longer interested in being a slave driver to myself so I’m more quick to recognize when it’s time to bring someone else on.

In 2017 I also plan to continue pursuing some additional business ventures that excite me a lot, primarily the brewery project that I’m working on with my brother. Perhaps in the 2017 year in review I’ll be able to share more details on that project.

Of all things I did in 2016, one of the ones I’m most proud of is the acquisition of pippin.com, a domain I have been trying to purchase for quite a few years. That domain is now being used for personal blogging, though only minimally. Perhaps I’ll manage to write more for it in 2017. It felt really good to finally get the domain for my name.

Though the discussion started in 2015, much of 2016 was spent considering the possibility of selling off a significant portion of one of my companies (technically I run four companies) to an interested party. I know for certain that I will not run this business for the rest of my life and I probably won’t run it to the end of its days either. At some point, I will either leave the company to my replacement or sell it off to an adequate buyer. This is simply the nature of most successful businesses, especially online businesses.

The interested party offered me a fair price and a strong track record of success. I knew that selling a stake of the company would have led me to much greater success than I currently enjoy today. There was no doubt in my mind that the sell would lead to substantial growth,  but I simply could not get the feeling out of my mind that it wasn’t the right time. In the end I turned down the offer. Will I discover that was a mistake in the future? Perhaps but at this time I’m confident it was the right choice for me and the right choice for my team.

Starting and building a company has been one of my most challenging adventures so far. Considering the possibility of selling it was perhaps the second most challenging decision I’ve encountered so far along the way. The process, however, was a great exercise in figuring out what’s important and what I want to achieve over the next few years.

Company focus

At Pressnomics 4 I spoke on the subject of being a little selfish. Really the talk focused on the importance of taking care of ourselves.

Of everything my team and I have learned in 2016, I feel that recognizing the importance of focus is paramount. I don’t just mean focus as in staying on task; I mean focus as in staying on track. Every company has core focuses and places they put their efforts, but perhaps one of the determiners for how well a company thrives is the degree to which the company stays on track and avoids veering off the path and sinking time, effort, and money into projects that do not fit within the focus of the company.

In early 2016 it became painfully clear that we were spending too much time and effort working on areas of the company that did not align with our core focus. This lack of focus got pretty close to seriously harming certain aspects of the Easy Digital Downloads project.

Much of this last year involved working to realign our focuses and cleaning up the messes left behind by allowing our team to waiver.

At this point, we have just about finished realigning our focuses and I am really excited for what that will allow us to achieve in 2017.

Automatically renewing subscriptions

Perhaps one of the most important changes we made for the sustainability of the company in the last 12 months is turning on subscriptions for all license purchases for AffiliateWP, Restrict Content Pro, and Easy Digital Downloads.

We created our first automatically renewing subscriptions for AffiliateWP on January 21, 2016. RCP and EDD came a few months later on March 29 and March 30.

Since enabling subscriptions, we have not seen any drop in sales volumes, at least not for AffiliateWP and Restrict Content Pro. Easy Digital Downloads has suffered some declines this year but, as far as we’re able to tell, they’re entirely unrelated to enabling subscriptions. The fear I repeatedly hear from business owners is that turning on subscriptions will cause sales to take a dive off a cliff. This is simply not something we have seen, nor something I’ve heard from a single business owner that has followed suit in transition to subscription models.

At this time, we have over 13,000 active subscriptions between our three primary product lines. This accounts for more than $684,000.00 in recurring revenue that we’re projected to bring in over the next 365 days.

Note: EDD and RCP had zero subscriptions created for the first four months of 2016 since we did not enable subscriptions until the end of March.

While obviously the estimated revenue from those subscriptions will change as customers cancel and/or have their cards expires, it’s still very significant when realizing that the recurring revenue from these subscriptions (which does not include revenue from new customers) is nearly 50% of our annual revenue for 2016, and that’s from just 8 months for two of the projects and 11 months for the other. If we had started subscriptions on January 1, 2016, we’d likely have 80% or more of our annual revenue already accounted for.

What does this mean? Well, in short it means that 2017 is going to probably look really, really good by the end of it.

The very first subscriptions are up for renewal starting January 21, 2017. I’m looking forward to it, to say the least.

Price increase

Several of our products received price increases during 2016. These increases were made to better align the prices with the value the plugins provide and to help us reduce support while either sustaining equal revenue or growing the revenue.

Restrict Content Pro received a major price change when we updated the business model. It went from $42 for a single site license to $49 and from $120 for an unlimited sites license to $199. We also introduced new $99 and $449 license options.

Recurring Payments for Easy Digital Downloads saw a price increase from $82 to $145 when we relaunched the plugin. We also adjusted the price of many other extensions throughout the year but those were mostly minor.

At the end of 2016, we decided to implement a price increase across the board for all Easy Digital Downloads extensions, including an additional increase for Recurring Payments. So far this increase has been pretty well received. The number of sales per day / week has dropped slightly, but our average revenue has not. In fact the average revenue appears to show an increase, though it’s too early to say for sure. We’ll know for certain how the increase has affected sales, revenue, and support tickets in a month or two.

Revenue

Alright, let’s look at some more revenue numbers.

In 2015, the company revenue was $1,139,500. For 2016, I’m happy to say we’ve grown this by 29.9% with a total revenue of $1,480,375.86.

The revenue brought in comes from four primary sources:

Let’s look at each separately.

Easy Digital Downloads

In 2016, Easy Digital Downloads brought in $693,527.98. This is an 23.4% increase over 2015. This is a good number but, frankly, one I wasn’t thrilled with. Let me show you why:

screen-shot-2017-01-03-at-11-03-13-pm

Do you see the downward trend shown by many of the last 12 months? Let’s look at a similar graph but this time 2015 and 2016 together.

screen-shot-2017-01-03-at-11-05-05-pm

We see a similar trend. Average monthly revenue has more or less plateaued. While we did see a couple of good months, and one really good month, most months of 2016 were at or just barely above the 2015 months.

In the last four years, EDD has experienced constant upwards growth and this slowdown, which I first noticed in Spring of 2016, really bothered me. It caused me far more stress and anxiety than I’d like to admit. I racked my brain for days every week trying to figure out what was wrong. Why were we not seeing the same growth?

Really it comes down to a pretty simple answer: we’ve moved out of our rocket growth period and now we have to work harder for the same kind of growth.

That’s normal, or so I’ve heard from many different voices.

Our 2016 revenue did increase, and rather substantially, so that was great. It was the average monthly revenue that bothered me, primarily because our monthly expenditures began to outpace our revenue. The bulk of our revenue increase came from just a few of the 12 months.

In 2016, Easy Digital Downloads did not make a profit. The project took a loss of -$34,881.52.

There are a few reasons our expenditures for EDD grew in 2016.

First, we brought on new team members to help with support and development. We also brought some older team members back into more active roles. Both of these were investments into the project that will (and already are) pay off.

Second, we intentionally invested a lot of time and money into improving several of our primary projects within Easy Digital Downloads. These consumed large amounts of capital without equal immediate returns. We’ll see returns overtime.

Third, we intentionally removed numerous revenue streams because they did not align with our long term goals and focus. While losing these revenue streams hurt, we’re better without them as it allows us to better focus in the areas that will greatly surpass them in future revenue.

Fourth, we invested a lot of capital into purchasing exclusive rights to many of the extensions sold through easydigitaldownloads.com that were originally built by 3rd party developers. Bringing a lot of plugins in-house dramatically increased our expenses but also reduce the amount that we pay out in commissions each month. Over time these acquisitions will pay off.

Summaries for Easy Digital Downloads in 2016:

  • Total revenue: $693,527.98
  • Revenue from plugin sales: $628,843.81
  • Average customer value for 2016: $111.12
  • Average customer value over all time: $128.69
  • Average number of purchases per customer: 2.43
  • Total paying customers over all time: 15,013
  • New paying customers added in 2016: 3,718
  • Revenue from license renewals: $139,850.03
  • Revenue from license upgrades (single site to multisite licenses): $7,440.85
  • Commissions paid to affiliates: $12,850.4
  • 3rd-party extension vendor commissions paid: $197,092.29
  • Revenue earned from Priority Support purchases: $10,884.19
  • Recurring subscriptions created: 9,578
  • Recurring subscriptions cancelled: 1,395 (many of these due to upgrades)

There are a few numbers I’d like to highlight and discuss.

First, only $7,440.85 was brought in from license upgrades. These upgrades are when customers move from one level of license (such as Single Site) to a higher level (such as 2 – 5 sites) and pay only the difference between the two license levels. Considering our total revenue from plugin sales was over $600,000, the revenue generated from upgrades is tiny. In a little bit, I’ll show you the revenue generated from license upgrades for AffiliateWP and Restrict Content Pro. They are drastically higher than this, which tells me we have an issue: customers do not have adequate incentive to upgrade their license keys. We’ll need to try and change that in 2016.

Second, notice that the total revenue from license renewals was only $139,850.03 out of our total plugin sales of $628,843.81. That means only 22% of our sales revenue came from renewals. With just the recurring subscriptions we have created between March 30 and December 31st, 2016, we already have an estimated $330,000.00 in renewal revenue. That is an increase of more than 136%, and that’s only the renewal revenue we expect to bring in and does not include any revenue from new purchases. That amount is also greater than 50% of the entire annual revenue for 2016.

Third, we only paid out $197,092.29 in commissions to 3rd-party plugin authors. In 2015, we paid out $213,000. Why the decrease? Two main reasons:

  1. We have worked to acquire a large number of plugins from 3rd-party authors and bring them in house.
  2. We have actively worked to limit the number of 3rd-party plugins we sell through our site. I’ve mentioned this in various places before, but basically we realized (and learned the hard way) that we do not want to run a marketplace. We want to build and sell our plugins, not the plugins of other developers.

Not everyone is thrilled about the move away from the 3rd-party vendor marketplace for Easy Digital Downloads, but it’s a move we have consciously made and firmly believe was the right one for the health of our team and company.

AffiliateWP

In 2016, AffiliateWP had $542,656.34 in total revenue, an increase of 42.8% over the $380,000 in 2015.

Unlike Easy Digital Downloads’ slightly more difficult year, AffiliateWP had a great year. Surpassing $500,000 in annual revenue less than three years after our very first sale for $49 feels pretty good. In December, 2016, we also surpassed $1,000,000 in all time revenue, giving us an average of $33,330 in monthly revenue since the beginning. Not too shabby.

I mentioned this in the 2015 review as well, but it still surprises me that AffiliateWP does as well as it does. I know that we have built a very good, reliable piece of software, but early on I did not expect it to grow to this size, especially not as quickly as it did. A large part of our success, I believe, is building on top of and leveraging other successful plugins. Being able to take advantage of the marketshare of WooCommerce and  popular membership plugins like Paid Memberships Pro and MemberPress really gave us a good boost. Our own cross promotions with Easy Digital Downloads and Restrict Content Pro also benefit us greatly.

Early on in 2016 I started to suspect that AffiliateWP would surpass EDD in monthly revenue. It didn’t happen consistently but there was one month, October, where AffiliateWP earned more than EDD. At this time point I’m unsure if this will begin to happen more consistently in 2017. On one hand, we’re working hard to significantly raise EDD’s monthly revenue in the next twelve months, so it’s likely EDD will stay ahead. On the other hand, AffiliateWP has grown faster, and continues to grow faster, than EDD so it’s quite likely it will.

Summaries for AffiliateWP in 2016:

  • Total revenue: $542,656.34
  • Revenue from plugin sales: $511,438.65
  • Average customer value for 2016: $121.87
  • Average customer value over all time: $123.18
  • Total paying customers over all time: 8,261
  • New paying customers added: 3,657
  • Revenue from license renewals: $62,947.20
  • Revenue from license upgrades (single site to multisite licenses): $42,618.75
  • Commissions paid to affiliates: $14,936.66
  • Recurring subscriptions created: 4,467
  • Recurring subscriptions cancelled:  750 (many of these due to upgrades)

Similarly to EDD, AffiliateWP already has a large portion of revenue for 2017 predicted and accounted for thanks to the recurring subscriptions we enabled in January, 2016. In fact, we have an estimated $280,599.65 in automatic renewals over the next 365 days. That’s more than 50% of our 2016 annual revenue. In 2016, only 12.3% of our revenue came from renewals, so seeing the renewal revenue increase so drastically in 2017 is going to be a great aide to us.

I have little doubt we’ll approach $800,000 in revenue in 2017 for AffiliateWP.

Something else that is particularly interesting is the difference in revenue that came from upgrades for AffiliateWP and the upgrade revenue from Easy Digital Downloads. AffiliateWP had more than 5x the revenue from license upgrades than Easy Digital Downloads did. The reason is simple: AffiliateWP offers much more incentive for customers to upgrade than Easy Digital Downloads does by granting access (free of additional charge) to “Professional” add-ons. Easy Digital Download’s upgrades are for nothing more than higher activation limits.

Restrict Content Pro

As one of my oldest products, it makes me incredibly happy to see Restrict Content Pro come back to life. In late 2014 we made a commitment to breathing new life into RCP. November, 2014, saw the launch of a new website for the plugin and April, 2016, saw the first fruits of our efforts.

screen-shot-2017-01-05-at-8-09-34-pm

For a year or more, RCP’s revenue had held pretty steady at ~$7,000 per month. In April, immediately after updating the pricing model and releasing several “Professional” add-ons, we bumped the revenue from $7,000 to $11,700. By the end of 2016, our average monthly revenue had risen to $15,900.00. One month saw $22,000 and another (November with Black Friday / Cyber Monday) saw nearly $33,000.

In 2016, RCP had a total revenue of $165,824.79. Thanks to the significant increase in our average monthly revenue, I have little doubt we’ll surpass $200,000 for RCP in 2017. Of our three major product lines, I believe Restrict Content Pro has the highest potential ceiling, we just need to keep pushing ourselves to reach it.

Summaries for Restrict Content Pro in 2016:

  • Revenue from plugin sales: $165,824.79
  • Average customer value for 2016: $91.06
  • Average customer value over all time: $72.59
  • Total paying customers over all time: 4,994
  • New paying customers added in 2016: 1,465
  • Revenue from license renewals: $21,706.60
  • Revenue from license upgrades (single site to multisite licenses): $15,928.50
  • Commissions paid to affiliates: $3,203.50
  • Recurring subscriptions created: 1,573
  • Recurring subscriptions cancelled: 290  (many of these due to upgrades)

There are a few numbers I’d like to highlight and discuss here.

First, our average customer value for 2016 was $91.06. This is a near $20 increase over the historical customer value. This increase came from two made changes we made:

  • Introduction of Professional add-ons that encouraged high-level license purchases and upgrades
  • Price increase on all license levels

An increase of $20 on the average customer value makes a big difference over time. For simple math, assume we gain 2,000 new customers in 2016. That $20 increase could mean $40,000 in additional revenue.

Second, RCP generated nearly $16,000 in revenue from license upgrades in 2016. This is more than 2x the amount Easy Digital Downloads generated through license upgrades, strongly reaffirming that EDD’s upgrade incentives need to be revisited.

Third, in the next 365 days RCP has an estimated $72,581.80 in renewal revenue that will be processed. Similarly to EDD and AffiliateWP, this is ~50% of our total annual revenue. Earlier I said I don’t have any doubts that we’ll reach $200,000 in annual revenue for RCP in 2017. This estimated renewal revenue affirms that prediction.

Pippin’s Plugins

Since moving Restrict Content Pro to its own website, the revenue being brought in from pippinsplugins.com has dwindled severely, but that was to be expected as RCP was the primary revenue source for the site. Now the revenue coming in comes primarily from Sugar Event Calendar and site memberships.

  • Revenue from plugin sales: $5,493.61
  • Revenue from site memberships: $23,424.77
  • Commissions paid to affiliates: $179.60

In 2017 I hope to breath some new life into the Sugar Event Calendar plugin, which is now a partner project between myself and Daniel Espinoza.

Combined revenues

Our total gross revenue for 2016 was $1,480,375.86. In 2015 we finished the year at $1,139,500, giving us an increase of about 29.9%. This isn’t as much of an increase as 2014 to 2015 was, but it’s still a good bit of growth.

While 2016 had a significant loss for Easy Digital Downloads, our companies all combined did have a net profit for 2016. Restrict Content Pro and AffiliateWP both had a significant amount of profit, and enough to cover all losses for EDD and still leave us with additional cash in the bank. One of my goals for 2016 was to increase the amount of cash we have on hand, which we successfully did as nearly all company profit stayed in the bank accounts.

Support tickets

I still firmly believe that quality customer support is one of the most defining aspects of great companies. It is also one of the hardest areas within a company to excel. No matter how much you love helping people and seeing them succeed with your products, customer support is incredibly draining. As we have continued to grow our products, one of our company goals has been to be simultaneously shrink the burdens put on us through customer support, not by reducing the quality of the support we offer but by finding ways to naturally reduce support by making it less necessary for customers to need to contact us for help. Did we succeed? Let’s take a look.

Across our four support inboxes, we had a total of 20,829 tickets opened in our Help Scout account. Of these, 1/3 were for pre-sales and the remainder for technical support and account-related questions.

Easy Digital Downloads:

  • Tickets opened: 10,971
  • Total tickets worked on (includes tickets left over from 2015): 13,864
  • Average tickets per day: 38
  • Most tickets related to a single EDD extension: 2,354 for Frontend Submissions
  • Most tickets opened by a single customer: 42 (two customers tied for this accolade)
  • Revenue per ticket: $63.21

AffiliateWP:

  • Tickets opened: 5,635
  • Total tickets worked on (includes tickets left over from 2015): 11,056
  • Average tickets per day: 30
  • Most tickets opened by a single customer: 35
  • Revenue per ticket: $96.30

Restrict Content Pro:

  • Tickets opened: 3,560
  • Total tickets worked on (includes tickets left over from 2015): 3,565
  • Average tickets per day: 9
  • Most tickets opened by a single customer: 27
  • Revenue per ticket: $46.58

There were also tickets opened for various plugins on Pippin’s Plugins but those were minimal enough that I have not included them here. I also have not included any tickets that were submitted to Easy Digital Downloads on WordPress.org. There were approximately 270 support threads posted for EDD on WordPress.org in 2016.

In 2015 I reported that we answered 21,027 tickets across our products. In 2016 we answered 20,829….success! We brought in 29.9% more revenue and dropped the total number of support tickets. Support is still a huge burden every single day, but these numbers do not lie: we made a significant improvement in 2016. This means that we changed our average revenue per ticket from ~$54.19 in 2015 to ~$71.08 in 2016.

New goal: further reduce the number of tickets in 2017 and increase the revenue per ticket.

2016 goals from 2015 review

At the end of my 2015 review, I included the following goals:

  1. Visit New Zealand. My wife and kids actually depart on January 13th and will spend two weeks there. As one of the places I’ve always wanted to visit, I’m really excited for this trip. – Done. It was awesome.
  2. Dramatically reduce the number of support tickets we receive on all three properties. This is already in motion and is happening through several different avenues simultaneously. Reduced by 1% but with a 29.9% increase in revenue.
  3. Bring on two or more new team members, or transition current contractors to full-time. Brought on 6.
  4. Double the revenue of Restrict Content Pro. Took average from ~$7,000 per month to $15,940.
  5. Announce to the world one of the projects we’ve been working on behind the scenes. Hints have been dropped but not too much to show yet. Visit sellbird.com
  6. Ride, run, or walk 2+ miles almost every day. Could have done better.
  7. Spend more time with my family and remember to play often and work less. This was a major focus for me but I have a long ways to go.

Goals for 2017

For 2017, there are a few specific goals I will continuously work towards.

A renewed focus on physical and mental health.

I spent a lot more time in 2016 than recent years prior paying attention to my physical and mental health and it really did make an amazing difference. Seeing first hand how much some focus on it affected me has reaffirmed that I need to work even harder on making my health, and the health of my team, a priority.

Surpass $2,000,000 in company revenue.

I am really pleased with how far we’ve come in 2016 and previous years but now I really want to push us even further. In 2017 I’d like to see us surpass $2,000,000 in annual revenue while simultaneously not equally increasing our monthly expenses. We were profitable in 2016 and 2015 but I want to be wildly profitable in 2017. With everything we’ve learned and implemented in the last 24 months, I think we have a good chance of making it.

Travel to a new international destination.

My family and I have travelled to at least one new country each year for the last two years. I would like to continue that streak and visit at least one new international destination. We have not decided where yet (proposals welcomed!) but will probably begin making plans soon.

Increase revenue per ticket.

From 2015 to 2016, we increased our revenue per ticket from ~$54.19 to ~$71.08. I’d like to see us increase that further to $80 or $90 per ticket.

Brew my first batch of commercial beer.

My brother and I have been working on our brewery project in evenings and weekends for a while now. We’re not yet able to give any kind of timeframe on it but I do hope that we’ll be able to brew our first commercial batch of beer sometime in 2017. It’s unlikely that beer will be released or available in any form during 2017, but at least it will be produced and then allowed to age and develop overtime in oak barrels. Our brewery will be focused almost entirely on American Wild Ales and other long-term barrel aged varieties.

Write more.

Writing has always been an important aspect of my work and life. As my daily work as changed over time so has the amount of effort I put into writing. Going forward, I’d like to find a way to write more, giving myself more time for reflection and thought.

Thank you for reading. Let’s all go have an awesome 2017!

Posted on

WordPress Page builder plugins: a critical review

Before starting this, I need to be completely honest: I really dislike page builders. In the last few years, page builder plugins (and those built into themes) have quite possibly caused more headaches for me and my support team than any other single category of plugins available for WordPress. This overall experience, and one too many support tickets related to a builder in a week, culminated in the following Twitter rant:

These tweets garnered a fair amount of attention in the form of agreements, questions, and denial. Throughout the various small conversations that followed, I began to realize that I had never once truly used any of the page builder plugins that I was moaning about. Sure I had seem them countless times in our support system–usually in a negative light–but I hadn’t actually used one.

With that realization, it only seemed right that I take the time to truly try each one and give them a full review, so here we are.

Why page builders exist

There are many different answers to the question of “why?” but I think they can generally be summed up to this: people want them.

As much as they often cause difficulties for me and my team, I cannot deny that page builders have a huge audience of eager customers. Clearly they exist and thrive because the market demands them.

Chris Lema answered “why?” well in his recent blog post:

Simple. They offer customers a solution for personalization that mass-produced themes can’t offer, while at a lower price than working with a professional web developer and web designer.

I cannot argue with the utilitarian and economical purpose of page builders. I do feel, however, that page builders currently pose a severe problem to the WordPress ecosystem. They have become so ubiquitous that many site owners do not even realize that page builders are not part of WordPress.

On one hand this is great! It clearly shows value and demand for page builders. On the other hand, however, it can be detrimental to the overall WordPress project and user experience.

The problem with page builders

Last week I had a customer open a support ticket and say that the interface shown in our getting started videos did not match what he was seeing. At first I figured this was simply due to the natural progression of user interfaces overtime. We had made some changes recently so some of the options shown had different labels, different appearances, etc. What I discovered, however, was that the “difference” he was seeing was due to a popular page builder plugin. His edit screen had a visual page builder. Our getting started video did not. His sole experience with WordPress began with a theme that included a page builder, making him naturally believe that was the standard for all WordPress sites.

There are several prominent themes for WordPress that have a huge market share. Because of the sheer scale of their market share, these themes have extraordinary power to influence the expectations of a sizable percentage of WordPress users. When these players introduce extensive page builders, and other non-standard features, it is easy for their user base, who are typically non-power users of WordPress, to obtain a skewed perspective of what is “default” in WordPress.

I do not intend to say that we shouldn’t be influencing “default” perspectives–doing that is how we push forward improvements–but I do firmly believe that the creators of these page builders have a responsibility to be very careful. Unfortunately these themes, and the associated page builders, are not particularly known for incredibly high quality products or for actively participating in development of WordPress itself. This is not typically a direct concern for non-power users, but it does greatly affect them when these products result in problems with other WordPress products.

The page builder ecosystem is a wild west right now and is in a gold rush. A lot of different players are building their own versions and many are reaping good rewards for their efforts. I am all for teams building solid products and being rewarded for their efforts.

What the page builder industry is severely lacking is standardization. There is zero standard to how page builders should work. This shouldn’t surprise anyone as this is exactly what happens in every ecosystem that experiences a gold rush. Just look back a year or three to the commercial theme industry to see an excellent example of this. Thankfully these lacking standards tend to work themselves out as products mature.

In any large ecosystem where developers are free to build their own visions of products and openly offer those to the world, it should be expected to have a lot of variation. It is the incredible diversity in page builders that I believe is one of the primary sources of problems right now.

Okay enough of that, let’s get into the reviews.

The review process

For this review process, I felt there were several important factors that needed to be looked at for each of the plugins:

  1. How easy are they to use.
  2. How well do the builder interfaces translate into the final presentation.
  3. How much do they lock users into the system once used? Does the content display properly if the builder is deactivated? Does the content even exist after deactivating the plugin?
  4. Can filters such as the_content still be used to affect the final page content? This is incredibly important for compatibility with many other plugins.
  5. Are there any compatibility issues with frequently used methods in plugins (such as we see in our support systems)?

While not a super definitive list, I felt that these five criteria provided a fairly robust baseline for judging each plugin. With each plugin being different and them each offering their own unique feature set, I opted not to judge any of the plugins on the features they had or didn’t have and, instead, judged purely based on these five points.

In reviewing these plugins, it would be very easy to fall into a rabbit hole and spend hours upon hours setting up test sites and building sample page layouts. It may seem counter-productive to review page builders and not test building extensive layouts, but I really wanted to cover the basics and identify each plugin that suffered from or caused some of the common compatibility issues we see.

For each plugin, I did the following:

  1. Activated the plugin in a fresh install using a default theme without any other plugins active.
  2. Obtained a quick opinion of the overall interface of the plugin. Does it clash with standard WordPress interfaces? Is it obtrusive? Does it flow and feel natural?
  3. Tested the builder on the default Sample Page created by WordPress to get a quick feel for the overall interface and feature set of the plugin. This included using the builder to create a quick layout with several different elements to confirm the builder displayed properly in the default WordPress theme. As surprising as it might be, there are a huge number of plugins that display poorly in the default themes so this is always one of my first tests. If the plugin doesn’t work well in a default theme, how can we expect it to work well in other themes?
  4. From the edit screen of the Sample Page, I toggled the builder interface on and off in order to ascertain how well the builder supported using the standard WordPress editor and the builder simultaneously.
  5. Deactivated the builder plugin and then re-visited the Sample Page to determine what extent of content-loss deactivating the plugin caused. Ideally there should be zero content lost.
  6. Activated AffiliateWP, AffiliateWP – Affiliate Area Shortcodes, and Restrict Content Pro and then tested some of the features within these plugins that were known to fail frequently with page builders. I chose these plugins because I am intimately familiar with them, am aware of several compatibility issues with page builders, and I know that I have already taken serious effort to resolve many compatibility issues.
  7. Wrote down quick notes for each plugin for “good” and “bad” items based on the steps outlined here.

Common compatibility issues

In our support queues, we see several common problems with page builders, each of which I wanted to test for in this review.

First, we see a lot of cases where inline scripts loaded in a shortcode fail. For example, our [register_form] shortcode in Restrict Content Pro conditionally loads javascript and CSS files on the page the shortcode is included on. We sometimes see the files fail to load due to the way the builder plugins modify the content of the page, which breaks some of the standard WordPress shortcode detection methods, such as has_shortcode().

Second, we see site owners often try and use opening and closing shortcodes across page builder elements. This is common with the restrict shortcode in Restrict Content Pro. A lot of page builders are not able to adequately support opening and closing shortcodes when they are placed in different rows or columns in the builder.

Third, we see a lot of cases where plugins, such as Restrict Content Pro, are unable the modify the page content through the the_content filter when a page builder is used. As filtering the content is an incredibly common thing for plugins to do, I wanted to thoroughly test this with each page builder.

Fourth, we see frequent instances where page builders mess with content formatting of shortcodes added to builder elements. For example, some builders will cause extra paragraph tags to be added around HTML output by a shortcode, resulting in very poor frontend display of the shortcode that is completely different from what it would be if added directly to a page not using a builder.

The plugins reviewed

When I first started working on this, I planned to review all page builders, including those built into themes, but I backtracked on that idea once I realized judging a theme-specific page builder against a theme-agnostic page builder made as a plugin was not a fair nor accurate comparison. It’s for this reason that Make, Headway, Layers, and some others are not included.

I originally planned to review only the builder plugins I was aware of (typically those that cause problems in our support queues) but then opted to review as many as I could find in order to be as pragmatic as possible. Perhaps some of the builder plugins never made appearances in our support queues because they were awesome and didn’t cause any problems.

With the sheer number of plugins available, I know for a fact that I was not able to include every page builder plugin, but I do believe I managed a fairly extensive list that includes all of the most prominent players in the market.

Here are the plugins included in this review:

I feel it is important to mention that the reviews and opinions expressed here are solely my own. No sponsorships were requested or accepted for these reviews and the license costs for all plugins (when necessary) was paid in full from my own pocket.

There are no affiliate links on this page.

Alrighty, let’s get on to the actual reviews!

Beaver Builder

Over the last few years I’ve heard nothing but great things about Beaver Builder. It is a commercial plugin that constantly gets great reviews and has been doing very well on the commercial front. I’ve read many of the reviews of the plugin over time but this was my first opportunity to use it.

I am a firm believer in first impressions. The good news for Beaver Builder is that they have a strong reputation as a high quality product, leading me to have good expectations for it. Unfortunately for Beaver Builder, my first experience with it was immediately tarnished by this:

Beaver Builder Fatal Error

I had purchased a Standard license, which, as it turns out, does not include support for WordPress multisite. I have found multisite to be one of the greatest assets in quickly spinning up fresh WordPress sites for testing. I understand that this limitation was done intentionally to prevent customers from activating the plugin on numerous sites within a single network, but the user experience here was quite poor.

Being a developer, I said “like hell I can’t use it on multisite” and quickly found the logic inside of the plugin, removed it, and went on with testing.

Thankfully, the rest of my experience with Beaver Builder was much better than my first impression.

Upon loading the page edit screen, I was pleased to see a clean, unobtrusive interface. Too many page builders include massive, colorful buttons that just stick out like a sore thumb. Beaver Builder added theirs in a nice, tasteful manner.

Beaver Builder Edit Page

Clicking on Page Builder takes the user into a front-end interface that feels relatively similar to the customizer.

Beaver Builder frontend

The overall interface of the builder was pretty intuitive and worked well. I especially liked that it all felt pretty native to WordPress.

I went ahead and used the builder to create a few simple layouts and each worked well. I then proceeded to test the plugin with the steps outlined above in the review process.

Overall, very few problems were found and none of the common compatibility issues I detailed above appeared to be present in Beaver Builder. This is very good so far.

One of the great things about Beaver Builder is how well it retains content when switching the page builder off or deactivating the plugin. Retaining content is incredibly important for a good user experience. Imagine the anguish it could cause if a user was to construct an extensive page, decide to use a different builder, and then discovered that all of the content placed within the builder was lost completely when it was switched off.

I did, however, find a few pain points that I would like to mention. Some of these are not inherently bad, but, depending on the scenario, could result in unpleasant user experiences.

My first criticism for the plugin has already been mentioned, and that is the lack of support for WordPress multisite in the standard license. I’m entirely fine with limiting the number of domains the plugin is activated on but this limitation should not affect my ability to use a core WordPress feature.

Second, I found that a large number of the builder elements, such as contact forms, are not retained when the plugin is deactivated. This is because Beaver Builder includes its own proprietary contact forms, testimonial blocks, subscribe forms, image sliders, and many other content types. While it makes perfect sense to include these, it is important that users be aware of how they will be locked into using Beaver Builder once opting to add these kind of elements to their pages. This is where the separation between layout building and content creation becomes very blurry.

Third, Beaver Builder makes heavy use of icons through out its interface. Inherently icons are not bad, but when not combined with proper labels, icons can be disastrous for accessibility and are, overall, not very intuitive. In numerous cases it took trial and error for me to figure out exactly what each icon used did.

Overall, I was very pleased with Beaver Builder, especially as it did not present any of our known compatibility issues.

Visual Composer

Perhaps one of the most widely used page builders, Visual Composer is a commercial plugin created by WPBakery and is available from Code Canyon.net. Aside from being one of the earliest page builders, a large part of its popularity comes from it being bundled in a huge number of commercial themes on Theme Forest.net.

On one hand, Visual Composer has been perhaps one of the most challenging for me and my support team as it has had frequent compatibility issues with our plugins and others. Yet on the other hand, Visual Composer is also very good at building plugin-specific add-ons that add feature sets for other popular plugins, especially eCommerce plugins.

When activated, Visual Composer adds a large blue block with several buttons to the top of the edit screen. This block provides toggles for enabling the visual editor, classic mode (default WordPress), and a frontend editor.

I don’t particular care for the obtrusive format or style of these buttons. They just feel unnatural and are too much “in your face”.

Once enabled, the visual builder is pretty intuitive.

Visual Composer builder

There are a few things I like about this interface. First, the icons, while still a bit too heavily used, are simple and have pretty clear meanings. Second, the interface does not feel cramped. Even though there is a lot going on, everything still has space to breath. It’s quite well laid out.

Visual Composer Add Element

From a user perspective, it is nice to get a pretty accurate What-You-See-Is-What-You-Get view. The developers at WPBakery have done a good job with the drag-and-drop aspects of the builder as well. Too often drag-and-drop interfaces end up being choppy and jagged, but the one in Visual Composer is pretty smooth and works reliably.

In the same vein as a good WYSIWYG on the backend, Visual Composer also provides a complete frontend editing interface that truly is a WYSIWYG experience.

Visual Composer Frontend

When strictly using the visual editors, the Visual Composer experience is quite good. I don’t personally care for much of the stylistic decisions made with the Visual Composer interface as they really don’t blend well with native WordPress interfaces, but that’s largely just personal preference.

It is an overly broad generalization, but I’ve found that most developers that do not take the time to blend their own interfaces with the native WordPress interface, do not typically have great care for the overall user experience nor do they care greatly for WordPress itself. I cannot say if this holds true for the Visual Composer developers and, like I said, it is a very broad generalization, but it’s one I’ve found to be pretty accurate in my own experiences. It is one thing to strike out against standard user interfaces in order to create something better, and it is entirely something else to go drastically against style choices simply for the sake of it.

Along with my own personal distaste for the lack of style continuity in Visual Composer, there are two primary issues I found with it.

First, Visual Composer has a really, really strong lock-in effect due to its use of shortcodes for layout construction. Here’s a screenshot of the page editor after switching back to Classic editing mode (default WordPress):

Visual Composer Classic

Notice all the shortcodes? For this screenshot, I built a very simple page with three rows and two columns. For that, three separate shortcodes were added to the page in order to create the layout. Now imagine a much more advanced layout that includes numerous columns, many rows, and a lot of other builder elements, such as buttons, contact forms, images, etc. The sheer number of shortcodes added to the page makes it nearly impossible to comfortably edit the page in the classic editor. For anyone that wishes or needs to switch back and forth between editing modes, this is a very poor experience.

The heavy use of shortcodes also makes it a serious chore to ever disable Visual Composer and use something else, even just default WordPress. The site editors would be required to go through and remove the countless shortcodes from every single page that Visual Composer ever touched.

Non-technical users may not care how it works behind the scenes, but they will care about the amount of work removing Visual Composer if that ever become necessary.

The second issue I found is one of the common compatibility issues I mentioned above related to shortcodes.

Opening and closing shortcodes work properly within individual elements but they do not work across elements. Take the following screenshot as an example.

Visual Composer Shortcode Problem

The edit window is editing the contents of the very first row. You can see I added a [restrict]] shortcode to it. At the bottom of the screenshot, you can see the closing [[/restrict] shortcode. We’ve found this to be a very common practice with these kinds of shortcodes because site owners want to restrict a portion of the page while still retaining control of the layout within the shortcodes.

When rendered, the shortcode parsing breaks as shown in this screenshot:

Visual Composer Broken Shortcode

Visual Composer has some really nice aspects to it and is overall a very well functioning page builder, but I would personally avoid it due to the severe lock-in effect.

Tailor

This was a page builder I had not heard of until several people recommended it in response to my Twitter posts. It is available for free on WordPress.org and is built by Andrew Worsfold.

After activating Tailor, one of the very first things that caught my eye was the level of care with which Andrew integrated his plugin’s interface with the native WordPress UI.

Tailor Page

Tailor UI

It looks and feels exactly like native WordPress. I love that. It uses a Customizer-like interface that gets out of the way while still being very intuitive.

Another positive note for Tailor is the lack of icons for actionable items, making it easier for a site editor to quickly understand what each option does.

Tailor edit buttons

One of the few “complaints” I’ve found from other users of Tailor is that it’s not as feature rich as many of the other builders. After thinking about this for a while, I’ve decided that the fewer features offered by Tailor is actually a hugely positive note for the plugin. So often people get caught up on whether a plugin has tons of features or is an all-in-one package without stopping to think if the plugin should offer those features.

Many of the other page builder plugins include options for contact forms, testimonials, post sliders, and so much more. Tailor offers a few of those items but it distinctly limits them to a few more basic ones. Personally I really like this because I don’t believe page builders should be providing contact forms and other major feature sets. A builder should be for creating layouts, not handling email submissions. Those features should be handled through other plugins, such as a real form builder or image slider plugin, and then simply added to and displayed within the page builder’s layout.

Tailor walks the fine line between layout building and content creation / collection very well.

Another thing Tailor does well is content retention when the plugin is deactivated. None of the content is lost. It also has a really excellent admin-side representation of the frontend layout, giving it a great WYSIWYG experience.

There were only two negatives I found with Tailor, one being a compatibility issue and one just being a minor quirk.

First, shortcode openings and closures do not work properly across rows and columns. Look at my first screenshot above and you’ll see [/restrict] at the bottom. The first content block has the opening shortcode.

The second problem is simply that the drag-and-drop is sometimes a little rough. Elements tend to jump around a bit while trying to place a new one on the page. This is pretty minor but a smoother drag-and-drop would be excellent.

Overall, Tailor is a really excellent page builder that I would not hesitate to recommend to users.

Thrive Visual Editor

The Thrive Visual Editor plugin is built by Thrive Themes but is theme-agnostic, so it works with more than just their own themes. It is a commercial plugin that seems to have a pretty large customer base.

I’ve run into Thrive Visual Editor numerous times in our customer support channels but have not had any real experience with it before purchasing a license to test for this review.

The first thing I notice about the builder is it’s pretty reserved in how it adds its interface to the edit page screen. It’s not perfectly smooth and does stick about a bit, but it’s much more minimal than many of the other builder plugins.

Thrive builder

Clicking on the Edit with Thrive Content Builder button takes us to a new, frontend builder that looks like this:

Thrive Content Builder

Hovering over an element on the page shows an outline with three options: drag-and-drop ordering, duplicate, and close.

screen-shot-2016-09-23-at-2-28-24-pm

I rather like this because it stays away from abundant, hard-to-grok icons.

Adding new elements to the page is quick and quite intuitive. I really like the interface they’ve created for adding column layouts. Instead of using weird icons or other mechanisms for controlling the number of columns, they simply give you options for each division option:

Thrive column options

It’s simple and intuitive. While all page builders strive to build an intuitive layout builder, I think Thrive Visual Editor has possibly done it the best of all, or very close to it.

There is really only one problem I found with the plugin. Shortcode parsing works, script loading works, everything works great in fact, but there is one major issue that, for me at least, is serious.

The Thrive Visual Editor plugin has 100% content lock in. Let’s compare the admin edit screen to the frontend edit screen for the same page.

Admin:

screen-shot-2016-09-23-at-2-39-04-pm

Frontend:

Screen Shot

Notice the difference? None of the content added through the visual editor is shown in the admin. Instead of working with the existing page content, Thrive Visual Editor simply overwrites the page content. That also means that if you deactivate the plugin, all of the content added through the plugin is gone. Poof, vanished.

All page builders should strive to retain as much standard behavior as possible. Unfortunately, Thrive Visual Editor fails badly here, which is really too bad because if they had avoided the complete content lock-in, this would be one of the best page builders available. Unlike nearly all of the other page builders, Thrive Visual Editor does not suffer from a single common conflict that I could find, but the content lock-in is dangerous. For that reason alone, I would avoid using the plugin.

Fusion Builder

Fusion is the page builder from Theme Fusion, the creators of the notoriously popular Avada theme. It is quite possibly one of the most wide spread page builders due to its inclusion in the Avada theme, which is the most widely used commercial theme of all time.

Before going further, I need to include a reminder about one of the conditions for being included in this review. I chose to review only theme-agnostic page builders made as a plugin. So it needs to be a plugin and it needs to work with all themes.

The Fusion Builder appeared to fit this criteria as it is built as a plugin, so I went ahead and continued the review of it. That is, however, about as far as I got because, as it turns out, Fusion Builder is built as a plugin that can be activated on any theme, but it fails drastically if it is used on any theme other than Avada.

Here is the builder with Avada activated:

Fusion with Avada

And here it is without Avada activated:

Fusion without Avada

The builder shows up and sort of functions. The options at the top for selecting elements all work and new elements can be added to the page, but none of the icons show up and you cannot actually edit any of the content.

The frontend view is even worse, however, because it doesn’t function at all. None of the layout elements show up. Zip, zero, zilch.

Without Avada, Fusion Builder becomes a car without an engine.

I understand building a theme-specific builder but why on earth would you build a theme-specific builder plugin that only works with one theme? At that point you’ve simply made it harder for your customers to get all the features of your theme without any added benefit. If Theme Fusion offered a whole suite of themes, having a builder plugin that works exclusively with their themes would make sense, but they don’t! They make one theme: Avada.

In my mind, this is a fatal flaw that automatically discounts Fusion Builder as a viable option, unless of course you’re using Avada.

Now, all of that being said, I’d like to still give the builder a full review like the other plugins so I went ahead and activated Avada and tested out the builder.

Easily one of Fusion Builder’s greatest strength is its interface design. It is incredibly smooth and overall pretty intuitive. I really like that the entire builder experience is inside of the standard WordPress edit screen. Its design even blends into WordPress quite nicely.

I tested for each of the common compatibility issues we encountered and found mixed results. Standard shortcode parsing and script loading worked perfectly fine, as did filtering on the_content, a very common method employed by countless other plugins.

There were, however, some additional negative sides to the plugin beyond the reliance on Avada mentioned above. First, layouts are constructed using shortcodes, making the possibility of editing outside of the page builder an excruciatingly painful experience. Have fun editing this:

Fusion Builder inactive

Aside from the painful text editing experience using shortcodes like this creates, it also results in bad content lock-in. If a user deactivates Fusion Builder and is then met with the mess above, they’re probably just going to reactivate the plugin instead of trying to clean it up.

Like most of the other page builders, shortcode enclosures also do not work across builder elements. In an ideal world, the following should work but does not:

Shortcode enclosures

Before finishing this review post, Theme Fusion reached out to me to let me know that they are actively working on a new version of Avada and also a new version of the Fusion Builder plugin and, reportedly, the new version is actually theme agnostic. I was also provided with a copy of the new versions but some technical issues prevented me from fully testing them so I cannot say how substantial the improvements are, but it is something watch out for if you are an Avada customer or interested in Fusion Builder.

Page Builder Sandwich

I was not aware of Page Builder Sandwich before my posts on Twitter but several people said I should take a look at it. There is a free version available on WordPress.org and a premium version available from the developer’s website. For this review, I chose to stick with the free version as it covered all of the necessary basis for the review.

Once activated, Page Builder Sandwich adds a new metabox to the edit screen with a Edit with Page Builder Sandwich button. While I don’t love the color scheme (I don’t see a reason to not match the WordPress colors), the button is otherwise not intrusive so I have no issues with it.

Page Builder Sandwich

Clicking the new edit button takes us to the frontend where we’re presented with a WYSIWYG editor:

Page Builder Sandwich

This view does jump drastically outside of the WordPress look-and-feel, something I’m really not fond of. It’s a rainbow of unnecessary colors.

The Referral URL Generator form you see comes from AffiliateWP and was used as a test to see how well shortcodes that load CSS/JS work inside of the builder. Page Builder Sandwich got top marks here as everything worked perfectly, even the WYSIWYG aspect.

The layout editing interface is pretty intuitive and quite powerful. One of my favorite aspects is how the exact spacing between any and all elements can be easily controlled with a simple drag bar. It’s quite nice.

When adding a new layout element to the page, the toolbar on the left expands with additional options:

Page Builder Sandwich layout builder

Page Builder Sandwich has a few other strong points going for it.

First, shortcode enclosures work properly across elements. Unlike most of the builder plugins, opening and then closing a shortcode with columns, rows, etc, in between all works properly.

Second, there is zero content lock-in with Page Builder Sandwich. The plugin can be deactivated and all content is still available. Users can even continue to edit their content in the standard WordPress page editor if they wish.

There are really just two issues I have with the plugin. A couple of times I found myself in trouble as some of the layout elements got jumbled (for unknown reasons) and were sitting on top of each other. When this happened I couldn’t figure out how to delete the problem elements. I suspect this is due to a minor javascript issue that could be easily resolved once identified.

The second issue I have is very minor but still important in my view. I really don’t care for the aggressive color schemes. As I’d mentioned numerous times here and in other posts, I care greatly for maintaining the WordPress color scheme and style choices. The interface in Page Builder Sandwich is a stark contrast to the standard WordPress UI. In my mind, it creates an unnecessarily jarring experience.

Beyond those two items, it is an excellent page builder.

Brix Builder

Next on the list is Brix Builder. This was another new one to me but came recommended by several folks on Twitter so I gave it a go. It’s a premium plugin and starts at $69.

This is an aside but one I feel is important. One of my very first impressions of Brix Builder was quite negative, not because of their sales page, the price, or anything else about the product, but because I could not find out anything about the people behind the product. It is built and sold by a company called Evolve s.n.c but beyond that, there’s nothing. I believe greatly in the importance of trust and the willingness to put your face and name on your product. While it could be a simple oversight, I always question if there is an ulterior motive behind the decision to not publicly state the names of company owners.

Tip: put your face and name on it. To those whom trust is important, it can make all the difference.

I did go ahead and purchase a license and began playing with the plugin. Unfortunately, I was immediately greeted with a second poor impression as soon as I activated the plugin.

Brix Builder Framework Required

So immediately after installing the stand-alone plugin, I’m asked to install a separate framework plugin in order for Brix Builder to run. This is just a poor user experience with very little real benefit. I’ve seen a few companies do this but I’ve never been convinced it is a good idea. The standard argument for this approach is that the company can have multiple plugins that all use the same framework without requiring that each plugin bundle their own versions.

After getting the main plugin and the framework installed and activated, the builder looks like this:

Brix Builder

The very first thing that I noticed (you may see a trend here) is that the editor interface is wildly outside of WordPress standards. A lot of people would call me a stickler here but I really do believe it matters a lot for overall user experience. The best experiences are always going to be the seamless ones. Brix Builder, like many of the other page builders, is definitely not a seamless experience.

Aside from my initial distaste for the design decisions of the editor, the editing interface is nice and smooth and seems to work very reliably. Here’s a few more shots of the various screens:

Brix Builder

Brix Builder

Brix Builder

In terms of usability and intuitiveness, I’d put Brix Builder near the top of the list of the builder plugins reviewed here. It’s quite good. They make liberal use of tooltips and help text, which can really help beginner users get acclimated.

After building a few simple layouts to get a feel for the plugin, I dove into my compatibility tests. Some of the tests passed with flying colors while others, unfortunately, broke down pretty poorly. There were three major compatibility issues.

First, shortcode enclosures do not work across builder elements. Putting an opening and closing shortcode in one element works, but trying to span multiple elements fails. For plugins like Restrict Content Pro, or any other that uses shortcode enclosures, this is a major problem that results in tickets landing in our support queues.

Second, once the page builder has been enabled, site admins cannot switch back to the default page editor without losing their layout. If a site editor was to build a layout, temporarily switch to the default page editor (perhaps to add HTML directly in the Text view), save the page, and then switch back to the builder, the complete layout would be gone. This is really, really bad. Imagine spending a few hours building a great layout then needing to use the default editor for a moment, only to discover that all of your work is now gone.

Third, due to the way that Brix Builder modifies the page content, it completely breaks other plugins ability to also modify the page content through the the_content filter, which is a critical piece of functionality that thousands of plugins depend on.

These three issues are significant enough that I cannot recommend Brix Builder as a good option, which is really too bad because the plugin works very well on all other fronts.

Conductor

Of all the page builder plugins, Conductor is one of the most unique. Rather than being a layout builder for the content area of pages, it is a layout builder for the entire page. Most builders are designed to work within a theme’s content area, but Conductor is different. Conductor takes over the complete layout of the page, including sidebars and allows site editors to control everything between the header and footer of the site.

Conductor first gives site editors the option to choose a layout. This can be done for each page of the site, including all public post types.

Conductor layout

Once a layout is chosen, you’re put into the builder interface, which is very similar to the Customizer. From here, page elements and style options are controlled. Content is added to the page through widgets and “Conductors”, which is really just a custom widget with special options.

Conductor editor Conductor editor Conductor editor Conductor editor Conductor editor

It took me a little longer to get used to how Conductor worked than it did the other page builders, but I think that’s largely due to my predisposed expectations of how page builders work.

One of the other major differences between Conductor and other page builders, is the lack of “bells and whistles”. In many page builder plugins you will find contact forms, testimonial widgets, tabbed content options, section toggle, and more. Conductor does not have these and, frankly, I think that’s a positive. I’m a strong advocate for keeping a plugin’s focus narrow, which Conductor does well. Too many builder plugins try to be an all-in-one solution.

I did find one compatibility issue and one primary weakness of Conductor.

First, inline scripts loaded directly from shortcodes do not work properly. It seems that the way Conductor loads the content and layouts prevents script loading from behaving like it would on a standard WordPress page. This causes problems for some plugins, including some of our AffiliateWP add-ons.

Second, due to the content being stored in widgets, the content of layouts created through Conductor will become inaccessible if Conductor is deactivated. All builder plugins should strive for 100% content retention when the plugin is removed to aide site owners in migrating to or from plugins.

At the end, I’m not entirely certain how I feel about Conductor. I do really enjoy their approach with a Customizer-like interface (similar to the Tailor builder above) and they have provided a feature that very few other builders have: complete control of the page instead of just the content area. This level of control does at times make Conductor more difficult to use because it means the site editor has to build everything, instead of just the content area. For some site editors, this will be a hurdle, but for others it will be a huge win.

Site Origin

A free offering from Site Origin, a plugin and theme development shop, the SiteOrigin Page Builder is one that I rarely hear anything but good about. For that reason, and it being commonly seen in our support channels, I wanted to give it a run for its money.

Once activated, a simple, elegant tab is added to the page editor:

SiteOrigin Editor

Clicking on the Page Builder button opens a prompt asking if we’d like to copy the existing page content over to the builder and then, once the prompt is accepted, we’re greeted with a similar interface to that of many page builders:
SiteOrigin Builder

So far this seems pretty intuitive. We can add widgets, rows, and existing layouts with the tool bar at the top and edit the existing content by hovering over the element. There is even a live editor that provides a WYSIWYG view.

SiteOrigin Widgets SiteOrigin Rows SiteOrigin Layouts SiteOrigin Frontend

Overall, I really like the interface in SiteOrigin’s Page Builder. I did, however, run into a rather strange development decision.

Once the page builder was enabled and the existing content was copied over to an element inside the builder interface, I clicked Edit on the default element and was presented with this:

SiteOrigin Plugin Required

In order to edit the default content of the page, we’re required to install a separate plugin called SiteOrigin Widgets Bundle. What? Why? It appears that the plugin contains a series of widgets, which is fine, but seriously, site admins should not be required to install a second plugin just to edit the default content of the page, especially when all other aspects of the builder function without it.

Once the widget bundle is installed, we can go back to editing the page layout as normal. Just weird though. Now our editor for the default page content looks like this:

SiteOrigin Page Builder

After playing with the builder for a bit and getting a good feel for it, I have to say that I really like the user experience. The interface is great. It’s snappy, intuitive, and just works really well.

Sadly, all good things have to come to an end. Once I was done testing the default functionality of the plugin, which is superb, I dove into the compatibility tests. Some of the tests worked great and others failed. During these tests, I found a few other issues with the builder as well.

The first problem, just like almost all of the other builders, is that shortcode enclosures do not work across elements. This needs to work and is not difficult to do.

The second problem is that the builder interface and the standard page editor cannot be used simultaneously. If a site editor tries to switch to the regular editor, they are given a prompt:

SiteOrigin Prompt

Clicking OK takes you to the standard WP page editor, but something really odd has happened. Take a look at the text editor now:

SiteOrigin - Text Editor

See all the JavaScript? That’s not supposed to be there. That JavaScript is the result of the [pw_map] shortcode, which you can see in the screenshots above. Switching from the builder to the standard editor preserved the content but instead of keeping the shortcode as it should, it rendered the shortcode and then saved the output. That means my shortcode is gone, poof, vanished. I cannot edit it or adjust the parameters of the shortcode anymore because the shortcode isn’t there, just the HTML of the shortcode is.

The third issue I found was that SiteOrgin Page Builder creates pretty significant content lock in. Most of the elements, and any content associated with them, added to a page are completely lost when deactivating the builder on a page or when deactivating the complete plugin.

These three problems are pretty significant, though they won’t affect everyone, perhaps not even a sizable percentage of the SiteOrigin user base, but they are problems nonetheless.

Divi Builder

The Divi Builder from Elegant Themes is one of the more widely used builder plugins, at least gauging by my own impressions based on how often it shows up in our support channels. I’ve always had mixed feelings on it as it has always seemed to cause compatibility issues with some of our plugins.

Once activated, a giant purple button is added to the page editor:

Divi Builder

I will not hide it; I hate this button. It’s huge and purple for no reason other than to be blatantly obvious. It’s distracting and takes away from the fluidness of the standard WordPress interface.

Know what I like even less than the button? The rainbow of colors in the builder itself.

Divi Builder

Divi Builder Divi Builder

Divi Builder

Beyond my distaste for the builder’s stylistic choices, it does work quite well. The interface is overall pretty intuitive, though it is pretty heavy handed on the use of icons.

Once I had a few sample layouts built, I again tested for compatibility issues and quickly found several.

First, the builder is overly aggressive with its frontend CSS. To test this, I added a registration form from Restrict Content Pro to the page. Here you can see first the form without Divi Builder active and then the same form with the builder active:

RCP Registration

RCP Registration

Notice how the second image has lost a lot of its margins and button styling. Those button styles shown in the first image do not come from Restrict Content Pro; they come from the theme. That means Divi Builder is applying its CSS to elements that are not part of the builder.

As with all plugins, CSS in plugins should be written such that it only affects elements it is designed to target.

The second issue I found has to do with content lock in. Each builder has some form of content lock in, but Divi Builder is 100%.

Divi Builder

At least they are nice enough to restore the original content. As we’ve seen with a very select few of the builders, avoiding content lock in is not impossible. Too bad so few achieve it.

Next, shortcode enclosures do not work across elements. You have probably noticed that this is a very common trend in builders.

Divi Builder is definitely not my least favorite of the builders but it’s far from my favorite as well.

Elementor

This was another new builder to me that came recommended by a few people on Twitter. Elementor is free on WordPress.org.

Like some of the others above, Elementor adds a large colored button to the edit screen. If you’ve read this far, you know my opinions on it.

Elementor button

Clicking on it takes us to a frontend WYSIWYG editor, similar to the Customizer but with its own stylistic choices.

Elementor editor

Elementor

Adding new elements and widgets to the page is pretty nice and simple.

Elementor Elementor Elementor

Overall, Elementor works quite nicely. There were a couple of weird quirks when editing the content of element blocks. Switching back to the element index wasn’t very intuitive, but clicking around a bit took care of it.

Aside from the big red button that I mentioned above, I only found two issues with Elementor, and they’re two of the same issues we’ve seen with most of the builders.

First, inline scripts loaded by shortcodes do not seem to work properly. The files simply do not get loaded when the shortcode that calls them is included inside a builder element.

Second, shortcode enclosures cannot be used across builder elements. Within individual elements they work fine, but trying to encapsulate multiple elements in a single shortcode breaks.

The builder is pretty nice but could use with a few improvements to make the editing experience smoother and to address the compatibility issues mentioned above.

Pootle Page Builder

A free plugin from WordPress.org with premium upgrades, Pootle Page Builder has crossed my radar a few times but this was my first opportunity to play with with it.

First, I just have to say their mascot makes me happy. That doesn’t mean much for how well the plugin will work, but it’s still a great touch.

banner-772x250

Alright, let’s see what kind of monsters we’re dealing with in Pootle Page Builder.

After activation, users are presented with a nice welcome screen with helpful walk through videos. I skipped right past these but beginner users would very likely find them valuable.

On the page edit screen, we see a nicely placed Page Builder button.

Pootle Page Builder button

The red doesn’t bother me too much here because it’s well placed with the existing Visual and Text button options. I do wish, however, that the button color would match the selected color scheme of the currently logged in user. That would be a nice touch.

Clicking on the Page Builder button is where we see our first downside to the plugin.

Pootle Page Builder warning

Thankfully they warn us before deleting any content but I really do not feel this should be necessary. Page builders should always automatically pick up the existing content or, at minimum, provide a way to import the existing content. Some of the builders seen above support this properly.

I went ahead and clicked I know what I’m doing and was presented with this:

Pootle Page Builder

I immediately noticed two things:

  1. At the bottom it shows Word count: 239
  2. The top right shows a Default Editor button

So I wondered what would happen if I clicked back to the default editor. Would my content be gone? Hurray! The content was still there. Pootle Page Builder did not delete my content, it was just being overly cautious to ensure the user knows that the content seen in the default editor is not the content seen in the page builder. While that could be improved to synchronize the two views, this was much better than I initially thought.

The builder interface was very straight forward and easy to use.

Pootle Page Builder interface

I was able to quickly add a multi-column row and add text elements to it. This all worked fine and displayed as expected on the frontend.

One thing that became immediately apparent about Pootle Page Builder is that it has a much more minimal approach to the builder concept than most plugins. Rather than offer builder elements for all different kinds of content types, it simply provides the tools to build a layout, in which users can then add whatever they wish from other plugins or their theme. I really like this. Far too many builder plugins go for the all-in-one approach that, while very valuable to many, result in a lot of bloat. A minimal plugin isn’t suited for everyone but for those that just want layout control, it’s perfect.

Aside from the issue I pointed out above with switching back and forth between the editor views, Pootle Page Builder only had two compatibility issues I could find.

First, shortcode enclosures do not work across elements, just like nearly all of the page builders above.

Second, inline scripts loaded by a shortcode do not appear to work, at least not in the scenarios that I tested.

If I was to use a page builder on one of my sites, Pootle Page Builder would be in the running for my top choice.

Live Composer

Another builder I was not aware of before this post, Live Composer is a free plugin on WordPress.org with free and premium add-on plugins. Based on the reviews and the active site count (more than 30,000), it seems Live Composer is quite popular and has a strong user base.

After activation, a welcome screen is show with information about upcoming add-ons and existing add-ons that can be used to extend the plugin’s functionality. I skipped right past this page and went straight to the page editor. Before I got there, however, I noticed that Live Composer and registered several new menus in my admin area:

Love Composer menus

That immediately told me that Live Composer is playing the all-in-one game and offering both content and layout creation. Personally I feel page builders should stick closer to the layout-only side.

When we get to the page edit screen, we’re presented with a nicely done Open in Live Composer button that fits perfectly inside of WordPress’ UI.

Live Composer edit button

Interestingly, the developers chose to add two buttons, one next to the page permalink and one called Page Builder next to the Visual and Text buttons. Both do the same thing and direct us to a frontend editor.

Live Composer open dialog

Live Composer editor

I really liked how well the developers integrated their editor into the page edit screen, but all of that happiness went down the drain when I saw this.

I personally dislike the color scheme of the builder, but that’s the smallest of the issues here. The biggest problem I see is that the builder interface becomes clumsy on anything less than a large screen. The builder elements are placed in a scrollable container without any quick way to find specific elements. The arrows on the right move the view port to the left and right but they’re incredibly slow. You’re forced to move the view port one click at a time. Most of the time, interfaces like this would allow the user to click and hold on the scroll bar to move quickly through the options, but not here. It only accepts single clicks, so if the element you need is 25 spaces to the right, you have to click at least 25 times to get there. Keyboard navigation is not an option either. This just screams accessibility (and usability) nightmare.

Once we get past the interface problems with adding elements, the builder itself works quite well. Adding new elements is pretty smooth and editing existing ones works nicely. There were some occasional quirks that caused issues, however. For example, I added a text field and then tried to split it into two columns. When doing this, the column controls went underneath the text element below it, making the column controls inaccessible.

Live Composer editor glitch

Another example of poorly thought-out UI is the editor control panel for module rows. Again we are faced with a situation where there are a lot of controls to utilize, but they’re mostly hidden away in a scrollable horizontal container.

Live Composer row module editor

I spent some more time playing with the editor and found more of the same kind of issue so I decided to move on and test for the common compatibility problems. Here things broke down even further with five major compatibility problems.

First, the page builder completely ignores the existing content of the page. I’m really not sure why so many builders do this. It is not hard to import basic content in to a full-width text field and then let the site editor take it from there.

Second, shortcode enclosures do not work across columns and rows. I really wish page builder developers would spend more time ensuring compatibility for standard shortcode functionality.

Third, inline scripts loaded by shortcodes do not work at all. The scripts simply do not get loaded like they would in the standard WordPress editor.

Fourth, plugins that adjust content through the the_content filter break completely. Live Composer completely overrides the ability for plugins to adjust the page content, meaning the primarily functionality of plugins like Restrict Content Pro is completely useless when using Live Composer.

And last, if the page builder is deactivated, every bit of content put into the builder is lost. It’s 100% gone.

Considering the number of 5-star reviews and the high active site count for Live Composer, I was really expecting a very different experience.

Conclusions

I am jaded, I will not deny it. I’ve had too many poor experiences with page builder plugins to not have a bad taste in my mouth.

One of the main reasons I chose to do this review was to try and be objective about it to see if my opinion was justified. I am really, really happy to say that a few builders here have won over my complete support. Those include Tailor, Pootle Page Builder, and Beaver Builder. Those three are easily my favorites that I would happily recommend to any of my customers. Sure they each have a quirk or two of their own, but what product doesn’t?

After going through each of the plugins in this review, I feel there are a few items that builder plugin developers should work to address.

First, compatibility with standard shortcode functionality is a must. Unless a plugin’s purpose is to explicitly disable a piece of functionality, all native WordPress features should remain 100% functional.

Second, avoiding content lock in should be considered a top priority. WordPress has been built upon freedoms and the philosophy of owning your content. What good is content ownership if it’s lost due to a negligent plugin?

Third, I would love to see more builders give greater care to the playground in which they play. Respect native interfaces and design decisions and leverage them. Hands down the greatest user experiences will always be those that successfully blend functionality and interface design seamlessly into the environment in which they live (WordPress).

I would love page builders to be a consistently good tool for site owners to rely on, but in order for that to happen, there must be stronger compatibility with the wider plugin ecosystem. Not all of the builders are weak in this area, but the majority of them have at least one major weak point when it comes to plugin compatibility.

Let’s return now to the Tweet that started all of this:

Are they all terrible? No, definitely not, some are even great! I hope that the opinions expressed here and the select compatibility issues pointed out help developers to create better page builders. I would be thrilled if this post was entirely obsolete in the near future.

Posted on

Rebuilding a dying product

Four and a half years ago, I released Restrict Content Pro on Code Canyon.net. It was not my first big plugin, nor even the second, but it was the first one that I developed a more intimate relationship with. I heavily relied on the plugin for my own site and thus had a greater commitment to it than the large plugins that came before. For the first two years, the plugin thrived. I updated it constantly and continued to push it further and further. In 2014, however, I began to lose touch with the plugin as my other two big projects, Easy Digital Downloads and AffiliateWP, dominated more and more of my time.

I continued to let Restrict Content Pro dwindle for nearly two years before making a decision. I had several options. I could let it die a slow, drawn out death, I could sell it, or I could work to bring it back to life and let it kick ass again.

I chose the last of the three options and, over the last five months, my team and I have been working to revitalize the product that was once the majority of my monthly revenue. It has a long way to go but we’re making significant progress and I’d like to share some of the journey with you now.

Among the very first steps was to set goals. What exactly did we want to achieve beyond just keeping Restrict Content Pro alive?

Ultimately, there were a few specific goals we had in mind.

First, we wanted to transform Restrict Content Pro from a good-but-simple membership plugin to a full-featured membership platform that is a top-contender among other membership systems. Doing this was to require a lot of work but, if done properly, should lead directly into the success of this project.

Second, we wanted to double or triple Restrict Content Pro’s monthly revenue within six months and then continue to grow it monthly from there. At its peak Restrict Content Pro was earning ~$7,000-8,000 per month. Once the project began to lose attention, that number steadily dropped each month, as should be expected with any project that doesn’t receive the attention it deserves.

Accomplishing these two goals would make the revitalization project a success in my eyes.

Addressing pain points in plugin features

In order to transform RCP into a full-blown membership platform that was as good as or better than the plethora of other options, we really had to add a few specific features that’d been missing. Since Restrict Content Pro was released in January of 2012, I had a huge list of pain points the customers often encountered. This gave us a very good idea of what we should focus on first in terms of development.

Some of these features included:

  • Pro-rated upgrade and downgrade support between subscription levels for members.
  • Expanded merchant processor support. PayPal and Stripe were the only two options for a very long time.
  • Dripped content to aide in member retention.
  • A full REST API to provide developers with a platform to build upon.
  • Improved WooCommerce integration.
  • More intuitive interfaces for configuring member-only content.
  • Umbrella memberships.
  • Improved administrator areas that are mobile friendly.

There were many other improvements (see some examples here and here) that we identified as well, but these were some of the primary pain points we wanted to address.

As of yesterday, every one of these features has been completed and is available as part of the core Restrict Content Pro plugin or as one of the many “pro” add-ons.

Many of these features are ones offered by other available membership platforms, but a few of them really help to set Restrict Content Pro apart. For example, RCP is the only membership plugin for WordPress that offers a full REST API. It is also only one of perhaps two or three that offers grouped (umbrella) memberships, which is fundamentally important to a huge number of organizations.

Part of building a successful product is offering the “standard” features. Another part is offering the features that set you apart through exclusivity. We have succeeded there and we will continue to succeed as we develop Restrict Content Pro further.

Increasing revenue by raising the average customer value

Research into revenue models has proven time and time again that it is easier and more profitable to increase the value of your existing customers than it is to acquire new customers.

Restrict Content Pro has had a fairly large number of customers over its lifetime. Between the time it lived on Code Canyon and the time it lived here on Pippin’s Plugins, RCP acquired some 5,700 customers. What this number really means is this: we can dramatically increase our monthly revenue if we can find a way to encourage those 5700 customers to renew and/or upgrade their existing license keys.

If we encourage just a small percentage of those existing customers to upgrade their license from the first level to one of the top tiers, we can meet our goal of doubling or tripling our revenue.

With AffiliateWP, we learned that using a model where add-on features are available free of charge to high level license holders, we could dramatically increase the average customer value, especially if enough pro add-ons were available to sufficiently justify the higher cost.

We decided to implement this same add-on model for Restrict Content Pro. By implementing many important features as add-ons available to top-tier license holders, we gave existing customers a significant incentive to come back and renew and upgrade their licenses, while simultaneously encouraging new customers to opt into a high level license instead of the basic license.

The concept of the pro add-ons was fundamentally important to the success of this project. Ever since Restrict Content Pro was made available on pippinsplugins.com in 2013, it was priced based on the number of sites supported by the license. For example, a single site license was $42 and an unlimited sites license was $132. Being that the only distinguishing difference between the license levels was the number of sites it permitted to be activated, the vast majority of customers purchased the $42 license. Now there is a significant difference between the Personal license and the Professional license; that difference being the access to the pro add-ons.

Getting more hands on deck

Restrict Content Pro, like nearly all of my original plugin projects, began as a solo project run purely by myself. I was the developer, the sales person, the support team, the tester, and (originally) even the accountant.

I’ve written about it before and I still feel the same today. Easily one of the best decisions I’ve made for the health of my business is bringing on other team members. Easy Digital Downloads was the first to get additional team members, followed by AffiliateWP shortly after. Restrict Content Pro, however, remained as a solo project all this time. I kept thinking about as my personal “pet” project. It was the project I worked on when I was tired of Easy Digital Downloads or AffiliateWP.

In order to accomplish the goals outlined above, however, keeping me as the only person working on the project wasn’t going to cut it.

John Parris joined the Easy Digital Downloads team full time in summer 2015. Later that year he began to express a lot of interest in working on RCP and membership sites so when the time came to put another team member on RCP full time, he was a logical choice. John is now working almost exclusively on RCP and has been fundamental in moving the project forward.

Michael Beil has been an unstoppable machine of efficiency in the AffiliateWP (and recently Easy Digital Downloads) support teams. Along with his prowess in support, Michael is a great tester and so getting him involved with Restrict Content Pro was an easy decision.

Andrew Munro is our site wizard and is wholly responsible for giving Restrict Content Pro a shiny new home at https://restrictcontentpro.com.

By involving these team members in the project, and staying actively involved myself, we’ve had great success in transforming Restrict Content Pro back into a vibrant and successful product that is here for the long game.

You can run a marathon alone but a relay takes a team.

Improving development activity

One of the many signs of a dying project is the cease of active development. Restrict Content Pro was no different. In the last two years, the plugin only received occasional updates and rarely, if ever, did those updates include anything beyond minor bug fixes.

To grow Restrict Content Pro into a strong product, we needed development activity to be constant. The same goes for non-development activity, such as marketing efforts and documentation improvements.

A lot of development work was required in order to get RCP to the basic level it needed to be at, but the development won’t stop there.

As shown by our blog, we’ve been very actively releasing updates and new add-ons for Restrict Content Pro. This is a trend that will continue for the next several months and beyond.

The results thus far

We have a very long way to go but so far the results are very promising.

In terms of increasing development activity, I believe we’ve been incredibly successful. Since April, when we officially began this project, we have released:

Several more pro add-ons are in the development and planning stages and the next major version of Restrict Content Pro (2.7) is in the planning stage.

Revenue wise, I feel we’ve done well. Our goal was to double or triple the monthly revenue within six months. In March, 2016, RCP brought in $7,700. Last month, July 2016, it brought in $11,400. August, 2016, is estimated to bring in a little over $12,000.

We’re at the five month mark and have increased monthly revenue by about 1.5. That’s not double yet, but it’s getting close. Within another few months, I expect we’ve surpass $15,000 in monthly sales. Even with just an increase of 1.5, we’re still looking at more than $100,000 in annual revenue, and the monthly revenue is higher than it ever was in the past, so we’re succeeding.

Overall the project has been a success and is something we will continue to work on for many months to come.

Restrict Content Pro will be one of the premiere membership platforms for WordPress.

Posted on

Help Scout documentation search with Gravity Forms

Gravity Forms is a tremendously powerful plugin for WordPress and Help Scout is an awesome customer support system that also provides a service for handling documentation. What they miss, however, is a direct connection that allows site owners to provide customers with a way to search the Help Scout documentation before they can submit a support ticket submission form.

An ideal support ticket submission process goes like this:

  1. Customer enters keywords related to their issue
  2. Relevant search results are shown to provide customer with “self-help”
  3. If the answer is not found in the documentation, customer can proceed with opening a support ticket

As far as I know, there are very few (if any) documentation / support solutions that provide this flow out of the box. There are numerous ways to build it but they are often complex and time consuming. Most product owners and service providers simply allow customers to fill out a contact form to ask for help without providing them with a good way to try and help themselves.

To help provide a better support experience for our products, and to make it easier for customers to help themselves, my team and I decided to build a custom integration between Gravity Forms and Help Scout that would allow customers to enter a search query, see results, and then, only if no relevant results were found, be permitted to open a support ticket. You can see this in action on the Easy Digital Downloads support page and also on AffiliateWP’s support page.

affwp-support

Let’s take a look at how we can set up a similar ticket submission form to the one we use for Easy Digital Downloads.

Requirements

Setting this up requires the following:

Configuring the form

There are numerous ways the form could be configured so feel free to deviate from the steps below. I’m just providing a sample configuration that can work well.

First, install all of the required plugins and setup the Help Scout documentation sub-domain setting and shown in the installation instructions for Gravity Forms and the Help Scout Search Field plugin.

Next, create a new form and add a text field to it that has a class of helpscout-docs:

Search text field Search text field

The class name is required in order for the field to be made into a search field.

At this point you can preview your form and the search field will be functional.Help Scout docs search results

Now, if you wish, you can continue to add additional fields and set up conditional logic for those fields so that they only display after a search has been performed. I would recommend breaking the form up into two pages with the search field on the first page and the other form elements on the second page, that way you only need to add conditional logic to the page break instead of each and every form input field after the search input.

My form looks like this:

Form editor

The conditional logic for the page break:

Page break conditional logic

On the second page of the form, I have added the following input fields:

  • name
  • email
  • website
  • message

Depending on your own needs, you could add additional fields as well.

This gives us a fully functional submission form that includes documentation search.

GF Help Scout Docs Search Demo

That’s all there is to it! Now customers can search your documentation before opening a support ticket. This could potentially cut down your support ticket stats dramatically while also making customers happier since it is now easier for them to help themselves.

Huge thanks are owed to Zack Katz for his contributions to the plugin. My team and I wrote the initial version that worked for us then Zack came in and made it 10x more awesome, allowing us to release it as a plugin that anyone can use.

If you could like to contribute to the plugin or report an issue of any kind, you can find it on GitHub.

Posted on

Extending the WordPress metadata API

The WordPress metadata API is a simple way to store and retrieve information related to various objects in WordPress, such as posts, users, comments, and taxonomy terms. Out of the box, WordPress includes post meta, user meta, comment meta, and term meta, but what if you want metadata on other objects, such as custom objects provided by a plugin? Thankfully, the metadata API is actually quite simple to extend, allowing developers to easily register their own kind of metadata that is attached to their own, custom objects.

Before diving into how we can extend the metadata API, let’s have a quick refresher on the existing metadata functions available in WordPress.

For each object type, there are four primary functions used by developers:

  • get
  • add
  • update
  • delete

Posts

For post objects, we have the following metadata functions:

  • get_post_meta()
  • add_post_meta()
  • update_post_meta()
  • delete_post_meta()

Comments

For comment objects, we have the following metadata functions:

  • get_comment_meta()
  • add_comment_meta()
  • update_comment_meta()
  • delete_comment_meta()

Users

For user objects, we have the following metadata functions:

  • get_user_meta()
  • add_user_meta()
  • update_user_meta()
  • delete_user_meta()

Terms

For term objects, we have the following metadata functions:

  • get_term_meta()
  • add_term_meta()
  • update_term_meta()
  • delete_term_meta()

All of these functions work exactly the same way. For example, to get metadata, it would look like this:

$value = get_post_meta( $post_id, 'meta_key', true );

To update metadata:

$updated = update_user_meta( $user_id, 'meta_key', 'New Value' );

To delete metadata:

$deleted = delete_term_meta( $term_id, 'meta_key' );

To add a new row of metadata:

$added = add_post_meta( $post_id, 'meta_key', 'The new value', $unique = true );

Notice that they are all identical in everything but name. Each of these functions is actually just a wrapper for the general metadata functions:

  • get_metadata()
  • add_metadata()
  • update_metadata()
  • delete_metadata()

For example, get_post_meta() simple calls get_metadata() like this:

$value = get_metadata( 'post', $object_id, 'meta_key', $single = true );

And, update_term_meta() simple calls update_metadata() like this:

$updated = update_metadata( 'term', $object_id, 'meta_key', $single = true );

Extending the metadata API

We have refreshed our memory on what the standard metadata API functions look like, so now let’s see how we can extend these to interact with our own metadata.

The first thing you need to do is have an object type that metadata will be registered for. This could really be anything but let me provide you with a few examples.

In AffiliateWP we use a custom table for affiliate accounts. An affiliate is similar to a user account and we often want to store metadata for affiliates, much like is often done for user accounts. We extended the metadata API to provide support for affiliate meta.

In Easy Digital Downloads we use a custom table to keep track of customer records. We recently added a new customer meta API that extends the one in WordPress. This allows us to store metadata for customer records.

In Restrict Content Pro we use a custom table for subscription levels and payment records. Both of these needed to support custom metadata, so we added metadata tables that extend the WordPress API.

Other examples of object types that may need metadata could include invoices, sale receipts, photos, and so many more. Basically, if you register a custom table and do not rely on the core WordPress tables, it may behoove you to add a metadata layer as well.

There are several components involved with registering your own metadata layer:

  1. You need to create a custom table in which to store the metadata
  2. You need to make WordPress aware of the meta table
  3. You can optionally define wrapper  functions or class methods for the core metadata functions that make it easier to interact with your metadata layer

Let’s look at each piece.

Creating the metadata table

The metadata has to be stored somewhere. In the vast majority of cases, the best option will likely be to register a custom table that closely mimics the default metadata tables for posts, users, comments, and terms.

If you’re unfamiliar with creating custom database tables, I’d recommend you read through my series on building a database abstraction layer, especially part 3, which covers creating the tables.

The MySQL syntax that WordPress core uses to create the postmeta table looks like this:

CREATE TABLE `wp_postmeta` (
  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `post_id` bigint(20) unsigned NOT NULL DEFAULT '0',
  `meta_key` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `meta_value` longtext COLLATE utf8mb4_unicode_ci,
  PRIMARY KEY (`meta_id`),
  KEY `post_id` (`post_id`),
  KEY `meta_key` (`meta_key`(191))
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Unless you have a specific reason for deviating from this structure, I’d recommend using the same table structure.

Let’s use AffiliateWP’s affiliate meta as an example.

The MySQL for our table looks like this:

CREATE TABLE `wp_affiliate_wp_affiliatemeta` (
  `meta_id` bigint(20) NOT NULL AUTO_INCREMENT,
  `affiliate_id` bigint(20) NOT NULL DEFAULT '0',
  `meta_key` varchar(255) DEFAULT NULL,
  `meta_value` longtext,
  PRIMARY KEY (`meta_id`),
  KEY `affiliate_id` (`affiliate_id`),
  KEY `meta_key` (`meta_key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

We create this table when AffiliateWP is first installed, along with our other custom tables.

The structure is simple and mimics core’s metadata structure:

  • meta_id – This is an auto incrementing row that holds the ID of the row
  • affiliate_id – This is an integer that is set to the ID of the affiliate the metadata belongs to
  • meta_key – This is a string identifier for the value stored
  • meta_value – This is the actual value of the metadata stored

Registering the metadata table with WordPress

Once the table has been created, we need to make WordPress aware of it. This is what will permit us to utilize the core metadata API functions, such as update_metadata(), to interact with our data.

I would recommend registering the table on the plugins_loaded hook but it could likely be done during other actions as well.

function pw_register_metadata_table() {
	global $wpdb;
	$wpdb->affiliatemeta = $wpdb->prefix . 'affiliate_wp_affiliate_meta';
}
add_action( 'plugins_loaded', 'pw_register_metadata_table' );

That’s really all there is to it. You can see how we actually do it in AffiliateWP here.

There is one important notes about registering the table. The value passed to $wpdb most follow an exact naming scheme as it defines the value that needs to be passed to the $object_type parameter of the metadata functions.

The type value is determined by everything before “meta”, so in our example above we used “affiliatemeta”, which makes the value we need to pass to the object type “affiliate”.

If you register the table as $wpdb->customermeta, you would pass “customer” as the object type.

Interacting with the metadata

Now that we have created the table and registered it with WordPress, we can use the metadata API functions in WordPress to read, write, and delete to our metadata table.

Add metadata:

$added = add_metadata( 'affiliate', $affiliate_id, 'some_key', 'The value' );

Update metadata:

$updated = update_metadata( 'affiliate', $affiliate_id, 'some_key', 'The value' );

Get metadata:

$value = get_metadata( 'affiliate', $affiliate_id, 'some_key', $single = true );

Delete meta:

$deleted = delete_metadata( 'affiliate', $affiliate_id, 'some_key' );

If desired, this could be formalized a bit more for your specific use case by defining wrapper functions to the core functions. For example, in AffiliateWP, we register methods in our database class like this:

/**
 * Retrieve affiliate meta field for a affiliate.
 *
 * @param   int    $affiliate_id  Affiliate ID.
 * @param   string $meta_key      The meta key to retrieve.
 * @param   bool   $single        Whether to return a single value.
 * @return  mixed                 Will be an array if $single is false. Will be value of meta data field if $single is true.
 *
 * @access  public
 * @since   1.6
 */
function get_meta( $affiliate_id = 0, $meta_key = '', $single = false ) {
	return get_metadata( 'affiliate', $affiliate_id, $meta_key, $single );
}

We also define global functions to make the class methods more accessible:

/**
 * Retrieve affiliate meta field for a affiliate.
 *
 * @param   int    $affiliate_id  Affiliate ID.
 * @param   string $meta_key      The meta key to retrieve.
 * @param   bool   $single        Whether to return a single value.
 * @return  mixed                 Will be an array if $single is false. Will be value of meta data field if $single is true.
 *
 * @access  public
 * @since   1.6
 */
function affwp_get_affiliate_meta( $affiliate_id = 0, $meta_key = '', $single = false ) {
	return affiliate_wp()->affiliate_meta->get_meta( $affiliate_id, $meta_key, $single );
}

The metadata API in WordPress is really quite nice and does a lot of the heavy lifting for us. There’s no need to write any MySQL for CRUD actions since it’s all handled for us in the metadata API.

Posted on

The monster that is a poor database schema

Step back in time two, three, four, or even 10 years and take a look at the development decisions you made then. What do you notice about them? Unless you are a one-in-a-million statistic, you probably look at those past decisions and say to yourself what was I thinking?! Why did I do it that way?! Welcome to the real world of actual development.

As developers, we grow and learn over time; we get better at making design pattern decisions; we get better at writing performant code; we get better at all aspects of development.

Take a look at any project that has been around for a number of years and you will find gremlins hiding in its shadows and crevices. There will be internal APIs that are convoluted; there will be data structures that make zero logical sense; there will be function names that seem asinine; there will be blatant problems and it will appear that these are the results of poorly made development decisions. While this is sometimes true, it is far more likely that these gremlins are actually the result of inexperience that leads to a lack of foresight and understanding of the future consequences of non-well-thought-out designs.

Smooth resolutions of bad design patterns

Imagine a project that begins as a small, internal system for doing one thing and only one thing, and imagine it as a project you build specifically for yourself. Due to the nature of it being a small, personal project, it is likely that you will take short cuts; it is likely you will make some decisions simply because Y provided a quicker solution than X; it is likely that you will name variables or API methods poorly; and it is guaranteed that you will make some decisions that have a severely negative impact on your small, personal project four years later when that project has grown far beyond a simple, personal project.

This is the reality of the real development world and the truth for all projects that grow over time. Poor data schemas and difficult APIs are the skeletons in our closets, the spider webs behind our furniture, and the ghosts in our machines. They exist in every project and are a natural product of development growth.

The real achievement is not in building a project with zero gremlins, it is learning how to get past those weaknesses and poor decisions in a smooth way that has little to no negative impact on the users of the project.

Let’s go back to the imaginary project above for a moment. Assume that when first building that project you made the decision to store large amounts of data in a poorly designed database schema, or perhaps even a database with zero design schema that applies to your project. At the time this database schema worked fine because it was easy and, after all, it was only you using the project, so who really cares? Now fast-forward four years and imagine that your project is now used by over 50,000 websites and tens of thousands of users and hundreds or even thousands of developers. Each of these users makes use of the project in a slightly different way and each of the developers builds new tools on top of the project. At this point those poor design decisions (or perhaps even the complete lack of a “design” decision) begin to have negative effects on the project by reeling their ugly heads and presenting your users with severe limitations and scaling issues.

Bad data schema designs can result in severe performance issues. Poor API design can make it difficult for other developers to use or extend the project. Poorly thought out relationships within your code and your database can become the elephant in the room that no one wants to talk about but are abundantly clear and really start to get in the way.

The question that all developers need to ask at some point is this: how do we get past the design decisions of the past so we can continue to grow and excel in the future?

This is precisely what my team and I are working on for Easy Digital Downloads now.

Quick and easy in the beginning

Four years ago, when Easy Digital Downloads was brand new, I made some poor design decisions related to the database structure used in the plugin. Relationships between various pieces of information stored by the plugin were created haphazardly and we chose to rely on the data structures provided by WordPress core. This means that all of our eCommerce data (payment records, order items, order meta data, customers, etc) were stored in the wp_posts and wp_postmeta table. At the time this worked fine. It was easy, quick, and more than flexible enough for what we needed. What I failed to see, however, was just how cumbersome storing eCommerce data in the core posts table was going to be once the plugin scaled up to a lot of users and large websites processing significant sales volumes.

The decision to use wp_posts and wp_postmeta for our eCommerce data is a decision I regret and one that has created significant challenges for us, but none of the challenges are so significant that we cannot get past them.

When faced with the reality of bad data schemas, there are really two ways to address the problem:

  1. Simply live it with and do what you can to mitigate the problems
  2. Work out a plan for resolving the problem completely by re-building the data schema from the ground up

The first option is the easier of the two for many reasons. First, it requires the least amount of change. Second, it avoids the significant risk of severely breaking backwards compatibility. Third, it does not require any cooperation with third party developers that have built on top of your bad data schema.

Option two, however, can be much better for the health of the project in the long run. It does, however, present a serious risk to the project’s health and continued adoption by users and developers. When making significant changes, backwards compatibility must be kept an absolute priority. If backwards compatibility is ignored or implemented poorly, it’s very possible that the migration process to the new and improved schema will go poorly, resulting in developers and users abandoning future reliance on the project. It can also cause a support nightmare if hundreds or thousands of websites are suddenly breaking due to the changes implemented.

Building a backwards compatibility layer can be challenging, but it is a challenge that will be worth it in the end. Frankly, I would go as far as to say you should not even consider resolving a bad database schema if you do not plan to also introduce and maintain a complete backwards compatibility layer. Choosing to ignore backwards compatibility in a scenario like this is negligent and harmful to your users. With that in mind, how does one go about building a backwards compatibility layer? There are really a few parts of it.

Abstraction layers for backwards compatibility

The very first step in providing backwards compatibility is to ensure there is an abstraction layer for your database. An abstraction layer is simply an API for interacting with the database. It provides developers standardized methods for reading and writing to the database without writing actual queries. For example, WP_Query is an abstraction layer for the wp_posts table that provides methods for querying data from the posts database without writing any actual SQL. Why is this valuable? There are numerous reasons but for this particular discussion, it provides project maintainers the ability to change the database schema without disrupting external projects that utilize the data.

In Easy Digital Downloads, we have built abstraction layers for payments, customers, and products. These abstraction layers are fundamentally important when it comes time to change the underlying database structure.

Let’s look at a quick example.

Assume we wish to retrieve the first and last name of a customer record. In the current version of Easy Digital Downloads, both the first and last name are stored in a single column in the database, but perhaps in a future version we decide to separate them into two columns. Through the EDD_Customer object, getting the name of the customer is simple:

$customer = new EDD_Customer( 47 );
echo $customer->name;

That will output the customer’s full name, such as Elizabeth Johnston.

Where’s the value in this abstraction layer? well, it becomes very apparent (at a simple level) when we consider the following possibility.

Assume now that the EDD_Customer object was not originally available so a third party developer decides to directly query the database for the customer’s name:

echo $wpdb->get_var( "SELECT name FROM edd_customers where id = 47 LIMIT 1;" );

Since storing both the first and last name in a single column was probably a poor decision, we later on decide to separate the names into two columns, first_name and last_name. In this scenario, the first example, which relies on the abstraction layer of EDD_Customer, will continue to function exactly as is. The second example, however, will suddenly fail because the name column no longer exists.

This is a simple example but it does accurately illustrate the importance of having abstraction layers. Consider now how important it will be when you’re preparing to change not only a single column in the database but the entire database. Every single column. Without a proper abstraction layer, making that transition will be nearly impossible.

If an abstraction layer isn’t already present, build one immediately. That’s the very first step anytime a database schema needs to be changed.

After you have an abstraction layer in place, you need to work hard to ensure that everyone uses it. If a platform has been around for a while, it will be necessary to push and shove work hard to encourage developers to update their code to use the abstraction layer. This is something we’ve begun to do for the recent introduction of EDD_Payment.

With the creation and adoption of a good abstraction layer, the process of migrating to a good database schema becomes a lot simpler, though it is still a very, very significant task that has a lot of challenges. For example: how does a project maintainer account for all of those developers that ignored or simply didn’t see the news about the abstraction layer? Or how about all of the project’s users that did not update to the latest versions? For those, the best one can do is provide as much backwards compatibility as possible.

For Easy Digital Downloads, building a backwards compatibility layer will involve a number of factors. First, we will have to intercept and re-route every single call to get_post_meta() that is made against all EDD payment metadata. Thankfully, the WordPress metadata API includes number filters and action hooks that make this possible. Second, we will have to intercept and re-route every query to the wp_posts table that contains the edd_payment post type. Again, the prevalence of filters in the WordPress core codebase will provide ample ways for us to do this. Third, we will also have to intercept and re-route every write and deletion to the wp_posts and wp_postmeta tables for all EDD-related queries.

Slow and careful

This kind of migration process takes a long time and needs to be executed with extreme care. We will likely spend 6-12 months building this backwards compatibility layer. The most significant challenge for it will not be writing or handling the re-routing of queries; the real challenge will be finding and knowing all of the data points that we need to include. For example, we know very well what all of the meta_key values are that we use in Easy Digital Downloads and all of the officially maintained extensions. What we don’t know, however, is the meta_keys that third party developers have used in their own extension. There are some assumptions we can make, such as assuming that any meta_key containing “edd_” belongs an EDD plugin, but we’ll never be able to cover 100% of the data out there.

In the end, there should be several goals in defeating the monster that is a bad database schema:

  1. Introduce a new and well thought-out schema that resolves all problems the original schema created
  2. Introduce and maintain complete abstraction layers for the database schemas so that future changes are less difficult
  3. Make the transition from old to new schemas as smooth and invisible as possible
  4. Protect the user base that does not have the luxury of updating or is simply unaware of updates by providing complete backwards compatibility

There is no reason poor database schemas cannot be improved, they just have to be done so slowly and with great care.

Note: would you like to learn how to build a database abstraction layer or read more about the reasons for why you should use custom tables in WordPress? I have a complete tutorial series on the subject.

Posted on

Hardships and victories in four years of eCommerce

Four years ago, I started out on a journey to build an eCommerce plugin for myself so that I could sell a few of the plugins I was building. A plugin to sell plugins, how meta. As with most of the projects I choose to dedicate my time and energy to, Easy Digital Downloads was built for me by me but in such a way that others could make use of it if they wished.

Today, Easy Digital Downloads is installed on over 50,000 websites, has reached nearly one million downloads, and has grown to a sustainable business that supports the livelihood of an ever-growing team comprised of full time employees and active contractors. I don’t think I ever thought we would be where we are today four years ago. It has certainly been an adventure and continues to bring new challenges and excitement every day. I would like to take a few minutes to look back at some of the challenges, hardships, and triumphs we experienced in getting to today.

Usually in these types of posts, I primarily cover the revenue numbers and other accomplishments. While I’d like to still include those in an effort to be ever transparent, I want to focus primarily on some aspects of this journey that I feel are more important and provide better value to others working on similar projects.

We are all imposters

Easy Digital Downloads has done well for me and my team, I will not deny that. We have seen upwards and continuing success constantly over the last four years. We have consistently grown our team and have managed to stay profitable as we do. Easy Digital Downloads is 100% bootstrapped and fueled by profit. We’ve never taken out loans to meet payroll or cover development investments and we do not plan to change this in the future. We are here and here we will stay. These are facts I’m very pleased to claim, however . . .

We are all imposters. We’re constantly exposed to the success and greatness of others that we place ourselves ever in a shadow of doubt. It is easy to look at the accolades of products and developers in similar ecosystems and compare your own success to them, and in comparison, look sadly upon yourself and wonder where you went wrong.

I watch spectacles like the recent WooConf and am in awe of their success. What is it that lead projects like WooCommerce to be so incredibly successful? I don’t intend to actually try and answer this question because it’s due to many, many reasons and debating their success, or the success of anyone else, is not the purpose of this post, but seeing this kind of success always makes one be a bit introspective.

It has been a true pleasure to watch the team behind Ninja Forms take their plugin from a small form builder that did okay to a truly dominant player in the market. I have watched, and been behind the scenes, as they have gone from a few downloads per day to thousands of downloads each and every day. They recently passed 2,000,000 downloads and are now active on over 400,000 websites. I love to see them excel and succeed like that, but then I wonder why it is Easy Digital Downloads has not reached those kinds of numbers? Sure we have passed 50,000 active installs and are approaching one million downloads, but our growth pales in comparison to Ninja Forms.

How about WP Job Manager, a side project for Mike Jolley? It has more installs than EDD and (from what I hear) has a higher monthly revenue than we have ever had.

It’s incredibly easy to get down on ourselves when watching the success of others fly past us. I don’t mean to belittle what we have achieved as I firmly believe our team has done great things with Easy Digital Downloads and I’m exceptionally proud of what we have produced and where we are going in the future. I do not bemoan others for doing better; no, I applaud them for their efforts and the rewards which they have truly earned.

I am not blind to my own status within the WordPress development community. I am very aware that many look up to me and my team for what we’ve done, so do not think these are the words of an ignoramus or someone that is blind to their own success. I believe it is important to understand that every one, no matter how high they have climbed and no matter how many people look up to them, is susceptible to feeling like an imposter among giants.

A bold face lie would be to tell you that I’ve never felt down or burdened when looking at the success of others.

About a year ago, a friend said something to me that had a great impact on me. He said something along these lines:

You are miles and years behind WooCommerce.

At first I was a bit disoriented. I didn’t really know how to take that. For the last three-four years, I had been working incredibly hard to make Easy Digital Downloads what it is today and here was my friend telling me I had essentially failed because EDD was nothing compared to WooCommerce. We didn’t have the massive customer base they did; we didn’t have the millions in annual revenue; we didn’t have media coverage outside of the WordPress world; we were not even a blip on most eCommerce radars. We were nothing. When he said that, he did not mean it to belittle or criticize our efforts; he was simply pointing out that if we wanted to dominate, we had to get moving and that we should consider partnering with those that could really propel us forward.

It took me a few minutes to (or perhaps months or years) to come to terms with that statement, but once I did, I realized something incredibly important. It did not matter.

At Pressnomics 2016, Brian Krogsgard gave a presentation on the state of business in WordPress. One of his poignant comments was that not everyone wants to be the best or the biggest. Not everyone is striving to win this competition that we’re all seemingly in, whether we choose to or not. The competition of who is the best, who has the best product, who makes the most money, who has the biggest and most badass team.

In response to my friend’s comment, my answer is this:

I know, and that is okay. Our goal is not to be the biggest or to own the market. Our goal is create something awesome and love doing it.

If your goal is to be the biggest or the most badass or to have the most market share, power to you. That’s awesome. I salute you, but that is not my goal and that is not the goal of my team or the goal of our products. Easy Digital Downloads is not the biggest, it is not the best, it is not the most valuable, and all of those things are entirely okay because those are the not accolades we strive to achieve. Instead, we strive to create a great product that customers love to use and one that allows our customers to create their own successful businesses online.

One of our customers told me recently that Easy Digital Downloads had changed his life. He said it had provided him the means to sell his plugin, which had grown to a point where it provided 100% of his revenue and enough to employ several full time team members.

That is the difference that we strive to make. Those are the accolades we are after.

I, and millions of others, feel like an imposter every day. If we allow ourselves to get caught up in that, it will consume us, so remember: it’s not about beating everyone else. Someone will always do better than you, and that is okay.

Own your product or be owned

A few months ago, I published a blog post titled Be a little selfish. The premise of that post was that in order to thrive, both personally and professionally, we all have to be willing to be a little bit selfish and make sure that we are taking care of ourselves. I stated that I felt it was fundamentally important to be ever cognizant that if you or your team is unhappy or unhealthy, you cannot possibly run a company that maintains happy customers, and I stand by that belief today.

Of all challenges we have faced in the last four years of building Easy Digital Downloads, the realization that we had begun to lose control of our product was perhaps the hardest and most painful to deal with. Last summer we began to realize that we had grown too lax with how well we controlled the extensions and developers that we actively promoted within the Easy Digital Downloads ecosystem. We had permitted too many subpar plugins to be published on our marketplace and we had allowed ourselves to become victims of those developers and our own inaction.

Early on, I made the decision to promote Easy Digital Downloads as having an open marketplace that any developer could get their EDD extension listed in. I wanted all developers to have the opportunity to piggyback off of the growing market that Easy Digital Downloads was creating. It made sense to me at the time: we promote other developers and other developers build things for us. Easy win! What I had not anticipated, however, was the severe challenges that running an open marketplace presents. I had no idea that the management, review, and support involved with publishing dozens of plugins from other developers would be so incredibly challenging. Looking back on it, I was clearly naive. How could that not be monstrously challenging?

Three months ago, we made a very deliberate decision: we were here to own our product. We did not set out to provide a platform for customers to set up sites that worked okay; we set out to build something awesome, and in order to do that, we had to take firm control of what we produced, what we supported, and where we chose to exert our efforts.

That decision meant that we were no longer running an open marketplace for any and all extension developers. Today, we still run an extension marketplace for Easy Digital Downloads, but we don’t allow just any one in. We are very, very choosy with who gets a plugin published on our site. Along with much stricter publishing guidelines, we also thoroughly evaluated every single plugin sold through the site and discontinued a large number of them for one reason or another. At one time, Easy Digital Downloads boasted over 300 extensions available in the marketplace. Today it has 164. In three months, who knows. I’d like to see the number go down actually.

Before we chose to take better control of our product, we were fueled by the idea that more is better. More extensions, more options, more choices. These can only be good things. Right? No! WordPress core got it right:

Decisions, not Options

When making decisions these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration. As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.

By producing every option under the sun and striving for even more options, we were crippling our users and crippling ourselves. What we thought was benefiting us, was actually killing us. We recognized this early this year and took action. To say that making a conscious decision to re-take control of our product made a difference would be an understatement. Since making the first set of changes that lead to better ownership of our own platform, revenue has increased, customers are happier, support tickets are down (and/or easier to solve), and our team’s morale is greatly improved. That’s the definition of a good decision if you ask me.

Highlights and victories

Over the last four years, the Easy Digital Downloads team has had some great highlights that I’m exceptionally proud of. I cannot cover everything, but there are a few I’d like to tell you about.

Continual growth

Since Easy Digital Downloads was first launched, we have experienced nearly constant growth. Each year we have done better than the previous and have experienced monthly growth more months than not. The graph below shows how EDD’s revenue has increased over time:

EDD Revenue over time

2015 saw only little growth, and a bit of fluctuation up and down throughout the year, but still ended very well, and 2016 has proved to be on a good path so far.

Revenue by year:

  • 2012: $25,500
  • 2013: $203,000
  • 2014: $489,000
  • 2015: $576,000
  • 2016 (so far): $194,000

While we have managed to continue the upward trend of revenue through https://easydigitaldownloads.com, the true indicator of our efforts will come in March of 2017. Last month we turned on automatic renewals through subscriptions for every purchase made through our website. This will have a significant impact on revenue next year.

So far this year, only 19% of our revenue has come from license renewals. Because license renewals have always required a manual process by customers, the renewal rate for license keys is incredibly low. While some customers do not renew because they choose not to use the plugins anymore, a huge portion of customers never renew their license keys because it’s a hassle, they miss the emailed expiration alerts, they think “I’ll do that tomorrow” and then forget, or some other reason that results them in dropping out. We managed to increase our renewal rate quite significantly by being much more aggressive with our email and license expiration notification strategies, but even those have only a minimal impact compared to what automatic renewals will have.

Imagine for a moment that a site that requires manual renewals has a renewal rate of 15%. Now convert this to an automatic renewal system, and take a guess at what the renewal rate will be. Hint: it’s significant even on the lowest estimates.

While only time will tell, we expect to nearly double our revenue in 2017 through automatic renewals alone. That’s the impact of automatic renewals through subscriptions.

Transitioning the extension sales to a subscription model took nearly a year’s worth of work and planning, but it was (and will be) worth the effort. As a happy side effect, the work we did on our systems to make subscriptions possible also literally more than doubled the monthly revenue of one of our more popular extensions. Talk about dog-fooding for the win!

Growth is about more than just revenue though. Our download counts on WordPress.org have been steadily increasing as well, as have the total number of active sites. We recently passed 50,000 active sites. The numbers below represent the total at the end of April each year.

  • April 2012: 1,585
  • April 2013: 83,763
  • April 2014: 278,002
  • April 2015: 584,058
  • April 2016: 994,820

I have no idea how many sites we’ll have running Easy Digital Downloads by this time next year but I am excited to see how far we can reach.

Traffic to easydigitaldownloads.com has also been on a near constant rise.

EDD site sessions

EDD site pageviews

Something interesting that I had not expected and only discovered when looking at the stats as I was writing this post, is the significant increase in page views and sessions  between May and June, 2015. Remember what happened on May 19? Automattic announced the acquisition of WooThemes and WooCommerce. I am not going to dive into hypotheticals or make proposals for why our traffic and page views went up right then, but I do find it super interesting 🙂

Overcoming technical debt

Perhaps one of the most difficult aspects of any long-term project, at least from a developer perspective, is dealing with technical debt.

Easy Digital Downloads has had its fair share of technical debt. It’s a problem that all projects spanning numerous years encounter, but I’ve come to realize that the technical debt in an eCommerce platform is significantly more severe than most projects. This is for a very simple reason: eCommerce platforms are depended on by businesses to keep their business running. Changing things just to get rid of technical debt is simply not an option in many cases. You have to constantly keep old data structures, or API methods, old everything in mind so as to not disrupt businesses’ revenue flows.

If an update for a purely presentational plugin goes awry and affects the display of a site, the revenue of the business may be affected due to unprofessional appearance, but if the update for an eCommerce platform goes awry, sales potentially grind to a complete halt. Obviously this is not always the case as not every update-gone-awry is so drastic, but it is an important lesson to keep at the forefront of every developer’s mind when building eCommerce.

In 2015 alone, we managed to eliminate a huge amount of technical debt that had been hurting our growth, hurting our flexibility, and making it more difficult and cumbersome for 3rd party developers to build on top of Easy Digital Downloads.

Later in 2016, we have continued efforts planned to even further remove some of our technical debt, and that excites me.

Getting great people

In the end, business is about people. Or perhaps I should say great business is about people. While I do not know if we fit in the category of a great business, I do know that we have managed to build a great and talented team around Easy Digital Downloads.

I have never felt qualified by any measure to lead a team but for some reason, these individuals let me keep my job, and for that I am incredibly grateful and blessed.

Today, the Easy Digital Downloads team is spread across four countries and even more backgrounds.

Sean Davis, Andrew Munro, Chris Klosowski, Topher DeRosia, John Parris, Chris Christoff and Phil Johnston are the folks working day and night to keep Easy Digital Downloads running. Honorable mentions go to Sunny Ratilal, Dan Griffiths, Kyle Maurer, Barbara Atkinson, Michael Beil, Spencer Finnell, and Adam Pickering. We also work actively with an ever-growing list of contractors and 3rd party developers to make improvements across the Easy Digital Downloads ecosystem.

These folks have all of my praise and deserve endless thanks. They make me better in so many ways and I’m humbled to get the opportunity to work next to them.

Onwards and forward!

Perhaps the most exciting aspect of the last four years for me, is the realization that we’re only just getting started. At times I feel like I’ve been working on Easy Digital Downloads my whole life, but it’s really been a brief period and we have a long runway in front of us.