The Caldera Journey So Far and What Is Next

CalderaWP WapuuI started 2015 stranded by a freak storm in a small town in West Texas. I ended it wondering if I had what it took to make it as an entrepreneur. In between I launched a new company or two, traveled to ten WordCamps and the one constant that held was community.

Those two days in Balmorhea, TX population 500, were actually pretty inspiring. After a scary night trying to get off the road and stay warm sleeping on a blocked highway off ramp, my wife and I made it to the one little inn, which was sold out and sent us to the community center turned shelter.

This tiny community, which clearly was not very well off came together to organize food, cots and more to keep over 100 people fed and safe until the roads were relatively safe to travel. Being stuck in an overcrowded community center is not the best experience. But being a part of a spontaneous and self-organizing community that arose to help out strangers made a bad situation into a great experience.

It reminded me of the value of community. You know like WordPress always does.

Back In The Sun

Who knew it snowed in Texas?

Photo by: veeterzySix weeks later, back in sunny Florida, David Cramer and I launched a new company to monetize his plugin Caldera Forms and make other plugins. It was exciting, even if the sales didn’t exactly pour in.

By the end of our first month — gross revenue: about $350 — I knew I was in way over my head as a business person and online marketer. But that was OK. Im someone who went from sort of knowing HTML, to being a pretty badass PHP and JavaScript developer.

I figured I could just hack business until I got good at it. This almost destroyed my business. After about 6 months we had increased our sales to about $1500 a month, which was good, but not enough. Client work was robbing our time and straining our relationship.

More than that, I had essentially demoted myself to junior developer and support representative. I spent my time fixing bugs, helping users and hardly ever writing any fun code.

Knowing I had to try something different, but not knowing what, I started another company as an A/B test on my business. Yah, I’m that guy, who starts another business to test the theories of what is wrong with his business. In the meantime I created a pretty cool new product: Ingot, an automated A/B testing tool for WordPress. Meta right?

All the while, I worked to figure out how to escape or fix the problems in CalderaWP. Over time the business and developer to developer relationship between David and I really improved.

Not shockingly, as our communication improved and we paid off our technical debt, our revenue rose. It’s still not great, but we’re finally in a good place, product-wise where we are ready to grow and grow properly.

If there is one thing I learned it’s that going slow can be a good thing. if Caldera Forms had blown up in a year to the kind of user base we are now focused on building it probably would have destroyed us.

I’m being patient with Ingot. It’s too early to say what Ingot will become and it’s slow growth is a good thing. The support demands are low, and we have plenty of time to figure out how to refine its feature set and really nail how to explain this product’s value properly.

Maybe it’s different with established brands and big marketing budgets, but in my experience, you have to spend a year running your mouth about something before it goes anywhere.

I Am A Developer

I can’t stop thinking like a developer, and that’s OK.

Photo by: NASAThe other thing I figured out is there are a lot of parts of running a business I don’t like. When I’m stressed out it’s normally about the business or money and one of my best coping mechanisms is to learn more about JavaScript.

That last paragraph is the words of a developer, not someone who should be running a business. A short audit of my financials and the number of loose ends in my business is a testament to that.

I embrace that. I’m a developer, and I can’t stop thinking that way. That’s good, and I love the strategic parts of designing products and marketing plans. But I’m done running the parts of the business I lack a passion for, am quantifiably bad at and take time away from the things I am passionate about and love doing.

I love being a developer, I love teaching — writing, speaking and creating course — and I love going to WordCamps to meet new people and connect with the growing group of friends I’ve found in this awesome community of ours.

The Ingot project had a lot of objectives, including trying new approaches to development. The other was to try out to new people I had met in Tallahassee that I believed in and wanted to work with. One of them, I still believe in, but he wasn’t the right fit, nor were we the right fit for him

Growing Toghether

The theme of 2015 was team work

Photo by: Stefan KunzeAs Ingot and CalderaWP grew, it became more and more clear how silly it was that the more mature company was being mismanaged by me, while the less mature company I had was being run incredibly well by Christie Chirinos.

Having two teams and two companies was a good way to start as we tested out what worked and didn’t work. But, moving forward as we have seen everyone’s strengths and weaknesses, we will move forward as one company.

For the last month I have been transitioning Christie into running both companies together and we will soon merge them into own company known as Caldera Labs.

In addition, my freelance practice and educational site will be folded in. It’s a lot of stuff, but I believe with better organization, focus, some tweeks to the business model, we are now ready to grow quickly and have badass products to back this up.

For the last few months I have been more active in Caldera Forms development than I had been in the past. David is going to remain the lead developer of Caldera Forms and I’m going to balance my time between that and leading the Ingot project. But I’m going to take my time with Ingot and let it develop naturally.

Moving Forward

The theme of 2016 is growth 

Josh Pollock speaks on Do WordPress Better With The WordPress REST API, at WordCamp San Diego 2016 #WCSD
I’m happy to represent my company, but I don’t want to be the only one. Photo by Kari Leigh Marucchi.

Of course, because Josh Pollock and David Cramer, we will keep making prototypes of fun new stuff. That’s something that used to drive me nuts about both of us. There is a ton of stuff that we have both built because that’s how we learn, with no plan to evaluate which of these plugins or services are worth pursuing and which were just fun.

You can expect to see a few of these reach the light of day as we evaluate the stack for good products. We never had a process of keeping track of early ideas, and evaluating them to see if they solve real problems that people will pay for or not.

That’s what’s next? I’ve been spending less time being freaked out and more time writing. My REST API video course was fun to make and pretty well received. Look to see more courses and some online or in-person workshops soon.

Also, we have some exciting updates for Caldera Forms and Ingot, as well as new add-ons about to launch. If you ask me real nicely at a WordCamp — I’ll be at WordCamp NEO and WPCampus this summer — I may tell you about some secret projects.

Have Fun

Seriously, that is the point of all of this, right?

This is me, at WordCamp San Diego using the force to summon an object to me in the middle of my talk. Photo by Joe McDonald.
This is me, at WordCamp San Diego using the force to summon an object to me in the middle of my talk.
Photo by Joe McDonald.

Sometimes I worry that when I tell people “have fun” or “sounds like fun” they think I am being sarcastic. I say things like that a lot and I am generally very serious.

I find what I do to be really fun. Not always, parts of it are not fun, but overall it’s a blast, and that’s what I want and why I do it.

So yep, I’m excited for Caldera Labs, it’s a new approach to organizing and growing our company and our team. It sounds like a lot of fun to me.

So You Want to Make a Commercial WordPress Plugin?

In the end of 2014 I decided to start a commercial WordPress plugin company. In March 2015 David Cramer and I launched CalderaWP. We went to market with an add-on for Pods and add-ons for Caldera Forms.

David and I met when he started contributing to Pods, where I worked at the time, and I was super-impressed by the UI in Caldera Forms. It worked the way I wanted my plugins to work.

A little over a year later I’ve started to look back at how it’s gone and how we could have done better. I want to share this in hopes you can learn something from my experience. This article is based on a tweet storm I sent recently.

To be honest, I was hesitant to write this post beacuse we’re doing OK, but we’re not having the kind of success that I see in the transparency reports from plugin companies that are killing it. But, I want to offer an honest and realistic vision of what it’s like to be a year out, and well positioned for success.

Speaking Of Imposer Syndrome

I just shared a bit of my self-doubt about sharing business advice. As a developer, it has been at time hard for many to get past “I’m not good enough for this.”

Do you know what? Fuck that. One of the best things about WordPress is it empowers us to try new things and learn as we go. That’s been the best part for me.

There are plenty of WordPress developers that are less skilled than me whose plugins sell better than mine, and plenty of developers who are better than me who I do better than business-wise.

Just make stuff and learn. Your version one is going to embarrass you later no matter what. Just don’t skip out on basic security and think you will fix it later. Sanitize and validate every user input and make sure every action has a nonce and authorization check.

If you don’t know what the last sentence means, start with the WordPress plugin developer’s handbook and Chris Wiegman’s presentation on application security for WordPress developers. If you have questions, its the kind of question advanced developers love to answer. Open a thread in the AdvancedWP Facebook and tag me if you need to.

Choosing The Right Product

caldera-forms-bannerLike the developers we are, we chose to work with the plugins we knew the best. On one hand this makes sense: you have to take advantage of your expertise. That said, Pods isn’t the most popular custom fields and content types plugin and Caldera Forms was virtually unknown when we started.

I don’t think that is a fatal mistake, and I believe very strongly in Caldera Forms. But, it did set us up for an uphill battle that should have been obvious to me, but wasn’t.

It’s hard, as a developer, to get passed what you think is cool and evaluate a project as a business.

More importantly, I’ve realized that I can’t prevent myself from thinking like a developer, and that’s OK. This is why we build teams with diverse sets of skills. When I started Ingot, I didn’t partner with any developers.

So You Want To Make Commercial Plugin?Photo by: Kamesh Vedula

Is It A Good Idea?

So do you want to make a commercial WordPress plugin? I think that is awesome, it’s a fun thing to do. But, if you want it to be a business you need to know if it a good business move?

What’s your timeframe to evaluate success? If it’s a year. Then the answer is almost always a big “NO” It takes a lot of time to grow. Think about it, if you only spend 500 hours coding version one, at $100/hr, that’s $50k in lost productivity. That’s a low estimate.

The point is that’s your investment in just getting the product built. You might think it’s free to build since you don’t have to pay yourself, but you still need to survive while you build it and get started and while you’re working on your product you’re probably not getting paid

You don’t have a website, logo, docs or two t-shirts for WordCamps yet. You or any marketting. You need all that. Seriously two shirts of different colors, that way you can wear a branded shirt both days and not have people think you didn’t change your shirt.

Do you have a plan to offset your lost productivity while you develop the product? How long can that last? Hopefully it’s as long as it takes to get the product to be self-sustaining.

How Are You Going To Support It?

So you released your product and some people started buying it. Congrats. Also, welcome to your new job in tech support!

Support is only one of the many costs that having a product.

When you read all of those transparency reports from successful plugin business you need to ask yourself: How long did it take? What are their expenses? How did they get there?

Can You Scale It?

Photo by: Andrew CoelhoIf all goes well you’ll get a bunch of users in your first year who can tell you what’s wrong with your plugin. Then it gets interesting. No matter how careful you are, at every stage of growth, your going to find new problems.

Technical debt is unavoidable and it is painful to pay back.

Now you need to support your users, fix the bugs, figure out what features to add, which feature requests to ignore. You need to find time to actually add those new features and keep doing whatever you’re doing to pay the bills without losing your mind.

While you’re adding those new features and fixing those bugs, you can’t break the stuff that works. Also, your competitors are going to add shiny new features you want and your users want.

At some point someone will tell you that you have to add a feature that your competitors has or they will use your competitor. If its a feature you want to add and can add, do it, but don’t feel like you have to do everything your competitor does.

It is better to let a customer who you can’t make happy go than to make promises you can’t keep to land the sale.

So, Should You?

So should you do it? If you’re passionate about your idea & 💖 building plugins & 💗 building a business, fuck yah. Have fun!

Just don’t think it’s quick money or fall into the “if you code it, they will come” trap. Price it high & fuck those who say lower the price.

If you’re in and need help with development, my company CalderaWP can help.

Just don’t forget that development is only part of what it takes to be successful. Right now we’re at the “Ok going well, but we need to scale it” stage. I have some theories on how to accelerate my growth, I’ll let you know which ones worked & which ones failed.

One thing I know for certain, you must invest in an awesome team and work hard on making that team work together well.

In fact stay tuned soon for a big announcements soon on how we are changing our team and how we do business in order to take our business to the next level.

But to the original question “So you want to make a commercial WordPress plugin?” I can’t really answer that for you, overall but I 💝 it 🙂

WordPress Plugins: SAAS! Gota Go SAAS. Right Brah?

All the things meme. Text is "SAAS all the things! All software is a service! $7.99/month! For the last year or so, I can’t get into a discussion about the WordPress plugin business without hearing why I’ve got to go SAAS, seriously SAAS, get that recurring revenue. I’m constantly hearing about why I need to turn my plugins into a software as a service (SAAS) model or create a SAAS business.

This worries me. The SAAS obsession can leads to businesses designed around a business model, instead of fitting a business model to a solution for a specific pain point. Also, the got to go SAAS brah push is paved with promises that it might not be able to deliver, depending on the product.

Don’t get me wrong, there is a lot of upside to a SAAS for developer, business and end user. So I’m not anti-SAAS or incorporating some of its benefits into a traditional plugin. I just think we need to break down why these things do or do not make sense.

Get Monthly Recurring Revenue

They want you to think you can’t charge for your plugin monthly

A lot of time I hear that I need to make my plugins a SAAS business so I can get monthly recurring revenue. This argument has at least three logical flaws.

  • It assumes you can’t charge for a plugin monthly

You can. For Ingot, we offer monthly and yearly recurring payment options. We use Freemius for this, it’s pretty painless for us and the end-user.

  • It assumes monthly payment options convert better than yearly payments

Ok, this is generally true, but if it’s not you’re leaving money on the table. If people are just as likely to pay you $100 a year, as $10 a month, you’re probably better taking that $100 up front, even if you get $20 less a year. The hope that I will have $10 next month doesn’t pay my bills. $100 now does.

A ton of MRR is awesome. But a little bit of MRR for a growing business, in terms of running that business, isn’t as cool as actual monthly revenue.

  • It assumes your plugin has ongoing value

Some plugins are more of a use once or twice type than essential type of plugin. These plugins — importers and converters — should always use one time payment.

Vova from Freemius has explored all of these points in alot more detail on their blog.

The big thing to consider is whether we normally make plugin licenses just about support and updates, not ongoing service, because that’s how we normally do it or if there is an actual reason for it. Consumers are used to paying an ongoing fee for services. I pay for Netflix every month. If I didn’t pay, I wouldn’t get Netflix.

Ingot doesn’t break sites when the license isn’t paid. It just always chooses the first possible variant and doesn’t record any data from the test. That way Ingot still creates valid HTML on the page, your site isn’t broken, but you don’t get the benefit of our algorithm.

That’s a lot nicer than Netflix. Last time I forgot to update my credit card details in Netflix, I logged on and they had removed all of the features besides the billing screen from the app. I didn’t get a single episode of House of Cards! Not one!

Yes, the licensing system in Ingot is super easy to defeat. But, people who don’t pay for software are not paying for my software whether they use it or not.

So, whatever, I’ve got a lot of things to worry about in life. Seriously, Donald Trump might be the next president and you want me to worry about people not paying for software. Meh…

Going SAAS purely because you can charge for your product in a specific way, not because you can deliver a better product via SAAS, or it fits better to the problem you’re solving or your solution, is bad business planning.

Protect Your IP

They want you to think your IP needs protecting

Photo by: Leigh KendellThis is the weakest argument for SAAS all the things in my opinion. Seriously, give me any good idea for a WordPress plugin and a small amount of time and money and I will reverse engineer it. So can a thousand other developers.

Yes, everyone can fork my plugins and use it anyway they want. I just don’t care. People try and get me to care, and I just don’t. When we launched Caldera Forms we didn’t fork Gravity Forms, we made our own thing and made it different, that is our advantage, it’s different.

I strongly believe that the ability to openly discuss source code with other developers leads to better code. Free software is both an ideological principle and a pragmatic way to make better software.

Does this apply in every case? Probably not. Getting investors interested in backing commercial free software isn’t easy. It’s hard for them to see what they should pay to make free software.

If you work in a free software space and you can’t convince yourself or an investor of the value of open source, one or both of you shouldn’t be involved in WordPress.

Serve One Stack

They want you to think some other plugin’s error is your problem

Photo by: Paul JarvisAs a developer, not having to worry about every single version of PHP and random crappy shared hosting configuration is a one of the most attractive propositions you can offer me. I dream of having one server stack to debug and being able to log every error. Being able to reproduce and test errors on the one single stack my app will be deployed on, that’s a wonderful thought.

iFraming in a plugin’s UI and not letting all the random crap that happens on a WordPress site break your app should make for less support.

I am making a lot of assumptions in this section.  Everyone of them needs to be evaluated to see if it is really true, not hopefully true.

But even if they are, that is not enough of a reason to go SAAS. Sure, running the processing on your server versus the user’s server might be the only way to make the service work. This is a case by case evaluation to make, but I’m just saying that Moore’s Law is against you on this.

But here is the other big issue: operational cost. Ingot runs totally on the end-user’s server. If someone uses it to run a million tests a day, or five tests a day the cost to us is $0. If we were a SAAS that cost might be very different.

This gives us serious flexibility in designing our pricing model. Assuming a fixed support cost, we could stop charging for the plugin tomorrow if we felt upselling to services was a better model. Our costs of running the core service wouldn’t change. Not being a SAAS product gives us major flexibility, including being a SAAS product at some point in the future.

For now we provide Ingot for between $0 and $100 a year and the risk of having the wrong pricing model doesn’t include running up a ton of AWS usage we can’t afford.

One of the big advantages of the WordPress plugin industry vs being a SAAS is we don’t pay to run the servers are software run on. Are you sure you want to give up that advantage?

Data Control

They want you to think “regular users” don’t care about owning their own data

Photo by: Aleksandra BoguslawskaWordPress is about democratizing publishing. As WordPress evolves that becomes more abstract, but the fundamental idea is that you control your data and what to do with it or not do with it. There is value in this and it is one of the reasons that people choose WordPress.

This point is not just ideological, it is pragmatic. WordPress users expect hooks, to customize how plugins and themes work. If the plugin doesn’t run on their servers, there are no hooks. Targeting an element in a cross-origin iFrame via CSS or JavaScript is not possible.

The more restrictive your APIware plugin is, IE the more you protect your IP, the more you have betrayed the WordPress promise of ultimate customizability. You start to invalidate the choice of WordPress for a project. And yes, WordPress isn’t right for everyone, but still, I want it to be as much as possible because WordPress is how I make a living and how so many people I know do.

The more complicated a site is, which often corresponds roughly to budget for the site, the more likely a site developer needs to modify how a plugin works or query its data directly. The more you close this off, the less useful your tool is to those who make WordPress sites professionally.

Professional developers and site builders are very important to your business. They recommend products, they blog about products, they buy multi-site licenses. They make other plugins that might integrate with your plugin.

SAAS Makes A Lot Of Sense

They want you to think Josh is anti-SAAS

Crop of ant in flower

Let’s talk about Akismet for a second. Akismet is Automattic’s anti-spam system. Without it WordPress.com would be covered in spam and would have failed. Without a healthy selection of anti-spam solutions all WordPress sites would be covered in spam and spam would have failed.

Akismet is one of Automattic’s oldest products for self-hosted WordPress sites and it uses a freemium SAAS model. The WordPress plugin is APIware that passes a suspect comment or other content to Automattic’s servers for a spam or not spam determination. The actual anti-spam system isn’t in the code they deliver to you in the plugin.

I don’t know for sure, but I suspect that if the that algorithm was running on your site it would be very anti-performant. I also suspect that in order to keep on top of increasingly intelligent spam bots, they need to crowdsource their machine learning.

Both of these factors probably make for an infinitely better service. In the process they got around having to release their code under a free software license and created a stream of recurring revenue. Both of those things I assume please the venture capital firms that Automattic would not exist without investment from.

And I pay that $5 a month for many of my sites. Great service, totally worth it.

So, will you see a SAAS service from me? Maybe. There are some interesting ideas being prototyped that might overcome every objection I’ve given here for going SAAS.

My team is way better equipped to deliver WordPress plugins than SAAS services — no devops here — so it makes me a bit nervous. I would suspect you would first see us offer add-on services to our core products that make them better or easier in some way.

People who skim this article are probably going to think I’m anti-SAAS for WordPress products. I’m not, I’m just saying that this business model has to be chosen because it’s the right business model. When the conversation starts at business model, before even knowing what the business is, that makes me antsy.

Learning AngularJS For WordPress Development

At WordCamp Miami this year, I showed how and why, I use AngularJS for building WordPress plugin admin interfaces. For our A/B Testing plugin Ingot we chose to build our interface in Angular beacuse it was the fastest and best way to build an interface that had to be highly dynamic.

I gave two talks, one on Angular basics, and then the second one dove into my specific use case. With this information & with a knowledge of how to extend the WordPress REST API you should be able to start creating new & exciting WordPress user experiences.

It was awesome to be a part of a day full of developers explaining why they made their choice in framework. I hope this type of sharing will lead people away from “What framework should I use?” to understanding the strengths and weaknesses of each framework and make that decision on a per project basis.

In Ingot, Angular is a thin UI layer on top of what is mainly a PHP codebase. I needed a really solid AJAX interface — sorry jQuery — that would allow the interface to have lots of different UI states easily available. Angular provides that.

I want to add that while the focus of these talks was Angular, building this way, in my opinion, requires an API-first approach to the PHP code. I wrote extensively about this before. The short version is that it requires keeping the code required for reading and writing to the database totally decoupled from the front-end use, and API code.

How The WordPress REST API Changes WordPress Plugin Development

This approach also requires having your own REST API endpoints. That part of the stack I covered in a talk I gave several times last year, in chapter 8 of my book and part 3 of my course.

http://learn.joshpress.net/downloads/customizing-wordpress-rest-api/

Slides

Video

 

Example Code

Learn More

Learn The WordPress REST API With Me :)

Josh Pollock WordPress REST API Course

The future of WordPress is the WordPress REST API. The future is here — it’s just not evenly distributed. The WordPress REST API is slowly maturing into a new and exciting tool, but it requires learning a whole lot of new skills and patterns.

I’ve had a blast writing and talking about what you can do with the REST API. In addition I’ve had the pleasure of presenting about the REST API at WordCamps all over the country. More importantly I’ve been putting it to use in my own work.

Today, I am releasing a four part video course about the REST API, with 17 videos in total. The premise of this course is that with the REST API, you can exceed expectations of what your users and clients expect from WordPress.

I genuinely believe that the WordPress REST API — once you master it — will allow you to deliver better more exciting, scalable and manageable results. It’s a new skill you need to learn, but it’s worth it. Don’t forget once you’re exceeding the standard of what people expect  that you start charging more.

Also, I made a 4 part video course about the WordPress REST API, that is available for sale today. Each of the four parts is a series of You can purchase the whole thing for $100, or each individual part of the course for $30 each.

You can learn more about the course, or download it on my shiny new “Learn with Josh” site. Expect to see more fun ways to learn WordPress development there, later this year.

BTW If you pre-ordered the course, check your email 🙂

What’s The Status Of The REST API?

Photo by:  Paula BorowskaPaula BorowskaAdding a REST API into a traditional web application, that was never intended to be API-first is no easy task. It’s going to take time and have ups and downs along the way. WordPress is all about progressive iteration and improvement.

The WordPress REST API is two parts. The first is infrastructure for creating RESTful APIs. The second is a set of default routes and endpoints for WordPress core functionality that uses that infrastructure. The infrastructure for the REST API was merged in to core WordPress 4.4. The second part was supposed to be merged into 4.5.

Unfortunately the second parts — the defaults — will not be included in WordPress 4.5. This does not mean that the REST API project is dead. The REST API team felt that everything besides the meta routes were ready to go, and proposed they be placed in a separate feature plugin, with the rest of the current feature plugin be merged. This proposal was not accepted.

The current issues that are considered blockers for the REST API are not huge. I would assume, but can not be certain, that the 4 routes — posts, users, comments and terms, with meta support for each — will be included in WordPress 4.6. In the meantime, the REST API plugin is still available for you to use.

The bright side, is that the plugin and the documentation are still being developed on Github, so it is easy for you to get involved with improving the plugin or the docs. If you’ve read my book, and watched the videos in my course, you are more than qualified to contribute to the docs.

Your Turn To Share

Photo by:  Maja PetricI first got excited about the REST API when I met Ryan and Rachel at WordCamp Milwaukee in 2014 and saw their presentation on the project. I went home both excited and worried. I knew this was the future of WordPress, if anyone could figure out how to use it.

So I wrote a bunch of articles for Torque, and gave some WordCamp talks, and wrote a free book, and now I’ve released this course. I love that I’ve been able to do all of that. If you’ve been following along and putting what you’ve learned to use, than you have something to share.
Free software is about the power of sharing what you’ve learned. The WordPress REST API is awesome. Some really awesome people put a lot of hard work into making it possible. Let’s pay it forward by sharing what we’ve learned about it.

More Data, Less Anxiety

There are a lot of ways my business causes me anxiety. This is an unescapable part of being an entrepreneur.

The biggest inducer of anxiety is decisions with no clear answer. Nothing makes this happen more than when trying to figure out the best way to describe my product.

I have a few different slogans I use for Caldera Forms, and I’ve never been sure what was the best one to use. It’s a source of constant worry for me if I’m using the wrong one, or if it doesn’t matter at all.

One slogan is descriptive, one says it’s different and one says it’s easy.
I’ve spent a lot of time debating over which one is best and I can make a good case for each. Without any data, I can’t know for sure, and honestly it’s been driving me a bit nuts.

Split Testing FTW

ingot-logoSo, the other night I installed Ingot, on CalderaWP.com and started testing the three slogans. I’m using the new “destination test” feature we added in the last version. This allows me to drop a shortcode into my content, where I normally would use the slogan, and track a conversion when a product is added to the cart.

I might find that the slogan has no effect on conversion rate. Honestly, finding out that I was worried about the wrong thing would be just as valuable. Only when I can eliminate one factor can I move on to testing others.

When you’re in business, you spend a ton of time worrying about all the possibilities, and talking to different people about the different options. That’s important.

So is taking a few minutes to set up an automated test to give you hard data to inform your opinion.

A/B Testing In WordPress The Easy Way Just Got More Awesome

 

Problem, Solution, Repeat

Photo by: Stefan KunzeYour business should solve a problem that you have and are passionate about solving. Of course, it’s not a good business unless that problem affects enough people and they are willing to pay for it.

Ingot exists because I knew I need to so A/B testing for CalderaWP and I wasn’t happy with any of the solutions available to me. The tipping point for me was actually an experience with MailChimp’s A/B testing system.

In MailChimp I started setting up a test in one of my campaigns and then I realized I was pretty sure I had done that test last time, but then I needed to confirm that thought, which turned out to be true. Then when it came time to fill out the field I had tested the last time, I had to look up which variant had won.

I got a little annoyed — especially because after all of that, I had to deal with the anxiety that came with the fact that my list wasn’t big enough to create a statistically significant sample.

It was like every reason I didn’t use complicated A/B testing services for CalderaWP’s website. All of which were built for sites with may more traffic than we have.

That’s why Ingot is a thing. I finally have a simple tool to do A/B testing on CalderaWP’s site that is designed to work on lower traffic sites — we get about 6-7 thousand unique visitors a month.

Online marketer Josh is happy not to have time to do analysis on analytics and split test results. There is now a plugin do that automatically.

No one tell online marketer Josh how much time developer Josh spent making that possible:)

 

I Can Do Anything! So What?

chemexFor Christmas this year, my wife got me a Chemex coffee maker. It’s an amazing gift. This simple tool, when used right makes the best coffee I’ve ever made. Getting the ratios, water temperature — she also got me an infrared thermometer — and pour technique correct is tricky. I’m still getting the hang of it, but when I do it right:)   

It’s a new skill to learn. It will take time to get consistency with it. It’s always going to take more time and effort to make coffee with the Chemex then with my FrenchPress. But, I enjoy the end results, and the process is fun. I don’t have a lot of hobbies, making coffee and doing it right is one of them.

I’ve been thinking a lot recently about optimization, Josh optimization, coffee making optimization and conversion rate optimization.

As many of you know, I’ve been working on a new conversion rate optimization plugin called Ingot. If you don’t know that, don’t worry, I’ll fix that:) By the way, we got a new logo, thanks to Michelle Schulp and a new website thanks to Jason Lemieux.

ingot-logo

It’s A Moonage Daydream

I wrote last week about what I learned as a developer working on Ingot. I wanted this piece to be purely about business. Nothing about development. The first time I tried to write this it turned into something about David Bowie, which is fine. The send time it didn’t work.

That’s awesome failure, because it is leading me to understand that I can not separate the two. I am not a business person and a developer. I am a developer entrepreneur.

Being a developer entrepreneur is awesome because I can code up my own ideas. It’s terrible because I can code up my own ideas.

There was a time, let’s call it the last few years of my life, when I rushed from “great idea” to prototype. I’ve spent a lot of time coding an idea before even considering the business’ unique value proposition, or whether such a thing exists.

I actually don’t think this was a bad thing at first. I used it as a way to learn a lot of things about WordPress, PHP, JavaScript, etc. I once wrote most of the MVP for a productivity app just to learn Firebase and it led to my first experience with Angular.

Whether or not that business idea was any good is sort of irrelevant. Having stumbled through Angular once before I had to learn it for Ingot, was valuable. Getting my head around three way bindings with Firebase plus Angular helped me understand how live-updating applications should work, and what’s wrong with how we try and fake them in most WordPress-based apps and plugins.

Not to say that I’m done learning. But I’ve gotten pretty good at what I do and I’ve created a situation where the things I need to do are sufficiently challenging, that choosing what to do and not to do, can not alone be about trying fun new shit. I’ve programmed myself to assume I can do anything, because with sufficient googling, I probably can.

It Works If You Work It

cropped-image-1441085665.jpgBeing a developer doesn’t exactly mean that you can do whatever you want. It just encourages you to think that anything is possible with the right amount of looking stuff up online and experimentation.

This is what is so exciting and fun about what I do. I get to constantly find new and exciting puzzles to solve.

 

Ingot does two types of testing: content testing, testing any type of change in content and measuring clicks to a destination, and price testing, which tests changes in pricing and measures changes in sales and revenue.

Right now, content testing works, and is in the plugin and price testing is still “coming soon.”

Recently, while waist deep in working on implementing Ingot price testing, I asked one of my Ingot business partners to do some testing on Ingot content testing. He found some issues. I told him I’d get to them when I finished price testing.

Then I heard from a few people about how the UI flow could be improved for content testing. I told them I’d get to it when I finished price testing.

Then I heard from a friend about a new type of content testing we should do. You can guess what I told them…

I knew content testing wasn’t perfect. I put it out there so I could feedback. Ship fast, iterate and repeat is a smart way to work.

But it doesn’t work if you don’t iterate based on feedback. It’s not a magic system. As we alcoholics say, the system works if you work it.

Josh Version 12,146

Josh Pollock at WordCamp US
Photo by Kari Leigh Marucchi — Found Art Photography

Startup entrepreneurship is, by definition — IE according to Paul Graham — about businesses with the potential for exponential growth. But, I’ve always felt that nothing big is worth doing if it doesn’t make me a better person. It’s a constant struggle, but I try.

Startups convert pain points into products that alleviate pain points. If the pain point is sufficiently painful and widespread then the business has potential for exponential growth. That is, if the solution, sales process, customer experience, and customer retention can be sufficiently optimized.

I think a lot about this stuff. I built Ingot because I didn’t have a good way of integrating A/B testing into my sites. The existing solutions underwhelmed me and none of them were powered by WordPress. Having the basis of Ingot in place will empower me to using a data driven approach to improving my businesses in 2016.

There is a ton of cool stuff that I intend to do with Ingot that should be useful to others. That’s awesome. But staying focused on improving what we have so far, and building the right features, not just the fun features. That’s going to be the difference, from a developer stand-point between having a product that could be successful and can not be successful.

Notice that I didn’t say adding the right features would make Ingot successful. I said it would make it possible for it to be successful. 

It’s so tempting to think you just need one more featured and then you’re product will be killing it. If only my plugin could do X, then everyone will want it. This is a kind of magical thinking that my ability to add features, and really enjoy doing so, has led me to.

That’s the lesson I’ve learned about business, by thinking as a developer about Ingot, as a business.

 

Planet Earth Is Blue. And There’s Nothing I Can Do

David Bowie wasn’t better than pop music beacuse of the level of artistry he brought to the art of pop music. Bowie was a Warhol.

I’m just starting to dig into Blackstar now, his final album. The comparison’s to his 1995 collaboration with Eno Outside are right on. But this is not a remake. Even when Bowie looked backwards, such as on Heathen, he was still perfectly modern. Heathen is one of my favorite Bowie records beacuse of how perfectly in two places — past and present –it was. The perfect way to tell the story of a character out of place.

Bowie was sly that way. He was sly in a way that was endearing and charming. He winked at his audience, instead of fucking with his audience.

I don’t know where I’m going from here, but I promise it won’t be boring…

If you’re reading my blog, you probably know me as Josh the WordPress guy, but before I was a web developer I was an audio engineer and musician. My music tastes have always been fairly eclectic and how Bowie did so many things, with such wonderful authenticity and evolved with time was always a huge inspiration on me in that phase of my life.

My career may no longer be in music, but Bowie is still an inspiration to me. My career in music became consumed with the technology of music for the same reason my career today is in programming — technology and the magic of making things with it is utterly fascinating to me.

Bowie moved with the times, but he also looked beyond it. When we take inspiration we risk seeing him as a chameleon — taking on the form of his current surroundings. Bowie took many forms, but none of them were purely copying what others were doing.

All of his forms challenged what was happening and pushed them in a new direction.

Press Your Space Face Close To Mine

Bowie’s music evolved over time authentically beacuse it evolved with the co-evolution of culture and technology. He never came off as a poser or a squatter in whatever type of music he landed in for a time. Where he landed he didn’t ape, he occupied it and looked forward. He wasn’t just modern he was futuristic. His work was authentic science-fiction.

The search for authenticity is hard beacuse there is no clear way to describe what it is. But, authenticity is something you could point at Bowie and see.

As Ursula K Le Guin wrote in the forward to Left Hand of Darkness, true “Science fiction is not predictive; it is descriptive… truth is a matter of the imagination.” Science fiction is way to use our visions of a different world, better or worse to discuss the present in an way that without fiction would lack authenticity.

Bowie challenged us to see a different version of the present.

It’s hard to define, but, for me, Bowie has stayed an inspiration beacuse of the way he embodied wonder, and a desire for something different or better… What I love about what I do is that it is never done.

Oh I’ll be free

Just like that bluebird

Oh I’ll be free

Ain’t that just like me

How The WordPress REST API Changes WordPress Plugin Development

Over the last few months I’ve been working on creating a totally self-contained WordPress A/B testing plugin. It’s called Ingot, and we released version 1 right after christmas.

Since I did almost all of the development myself from scratch I was able to do it all “the Josh way” and refine what that even means. This allowed me to put a lot of my opinions on WordPress development to the test. I shared a lot of what I learned in yesterday’s post.

Lessons Learned Coding A Big, New WordPress Plugin

Ingot was in many ways written around around the REST API. The custom endpoints we built are used for the Angular app that Roy Sivan and I created for the admin screen. It’s also used in a very small front-end JavaScript file for tracking conversions, failed conversions and cache busting.

Today, I wanted to follow up yesterday’s post with what I think it means to create a WordPress plugin using the REST API. Next week, I’ll talk about the business and product design lessons I learned from Ingot. The design decisions that went into building the Ingot REST API will be a big part of that discussion.

How Things Change

As most people reading this know, I spent a lot of time over the last year or so thinking about how the WordPress REST API will change how we build WordPress plugins, themes and apps. I think this change is big and has to do with how the use of WordPress is changing.

WordPress didn’t get to 25% market share on blogs and it’s not going to get to 50% or whatever that way. The growth comes from eCommerce, publishing, membership sites, inbound marketers etc. These are all users that can benefit from being service providers.

Photo by: Jeff SheldonI think that those of us who empower these users by giving them the tool need to make their sites have to think API first. Your plugin’s interaction with the client is going to be more and more coming through the API.

That doesn’t mean WordPress plugins are suddenly all JavaScript magically. Your custom REST API routes are PHP code that you write around the rest of your plugin.

If the code they wrap must be solid and sufficiently decoupled from input method — if you call GET or POST in your CRUD still you’re not going to make this transition.

The hype around the WordPress REST api has been about the default routes and that might be exciting to you if you do front-end work. But the real potential in my mind is that your plugins can be repurposed SAAS service more easily and that your users can become service providers themselves.

The Developer End User


Photo by: Sonja LangfordToo often, when creating a plugin that is designed to be simple to use and not require technical knowledge, we forge that there are still developers as end-users. Keeping developer end-users happy is super important as they are often decision makers that choose whether or not their client uses your product or not. They are also likely, if happy, to become evangelist for your project.

The ability for developer end users to be able to customize and integrate with your plugin via your REST API as an alternative to learning the WordPress hook system is a big deal. It opens more doors and more opportunities. It means more integrations, more contributions and more potential developer evangelists.

Angular + REST API

I originally thought I would use the plugin generator that David and I use for CalderaWP plugins. I couldn’t make it work with the original DB structure I had. The first Ingot demo used a really bad UI I hacked together. I wrote a ton of PHP code full of admin-ajax callbacks and functions hooked to init in order to check for incoming form submissions. By all objective standards, it sucked.

So, I taught myself AngularJS.

Since I was trying starting at a Jon Snow-level understanding of AngularJS, I was bugging Roy Sivan for help a lot. Roy ended up doing a lot of the heavy lifting for me and now pretty much owns the Ingot UI. That’s awesome because I don’t like UI work and he’s better than me.


Photo by: Jonas NilssonBut, I did learn a ton about Angular. What I learned enabled me to write all the example code for the last section of my WordPress REST API course — Angular front-end for WordPress sites. I really like Angular and the angular-ui router. It’s a really great way to work. It almost makes me wish I made WordPress sites so I could make them with Angular.

Our admin doesn’t look very WordPress. It’s a very standard Bootstrap, which is a common pattern that I hope people are used to using. I would love to get a WordPress admin Bootstrap theme made soon though.

I’ve spent a lot of time in the past trying to force the MV* pattern on WordPress, which is insane for a lot of reasons. Using the WordPress REST API to provide data to Symfony or Angular is really great, and fairly simple.

A WordPress plugin, like any product is only as good as its interface. I’m convinced that working with Angular and custom WordPress REST API endpoints was the right decision in terms of UI/UX. It also means we have a solid REST API to use if we make an Ingot SAAS product or if end users want to use it.

This Is The New Way

At this point, I don’t think it makes sense to build a plugin without its own set of API endpoints. Doing so requires a PHP CRUD that is sufficiently decoupled from input to work seamlessly with the API. Writing your plugin knowing you will use the REST API makes dependency injection in your class design a necessity.

That’s going to be an issue for a lot of older plugins, and the backwards compatibility challenge is also there. I think it is worth the rewrite though, if this is an issue. This will make your plugin more easy to unit test, which is a great bonus.


Photo by: Jerry AdneyOlder plugins also have to deal with backwards compatibility concerns. Ingot requires WordPress 4.4 or later. It’s a new plugin so we don’t have a user base to worry about alienating. It’s a concern for me in my existing plugins, and we will see how that plays out as I modernize them to work around the REST API.

I will, because I think that plugins that do not embrace this new way risk being left behind. For new plugins, the REST API-first approach makes sense. It leads to better admin experiences, easier interfaces and allows your plugin to more easily become a part of  a stack that is not totally built in WordPress.

 

Lessons Learned Coding A Big, New WordPress Plugin

Over the last few months I’ve put a lot of time into writing Ingot — an automated A/B testing and conversion optimization plugin for WordPress. Because Josh, I did a lot of other things at the same time — but Ingot was my biggest project.

Ingot is probably the biggest plugins, in terms of lines of PHP code, that I wrote. I’ve worked on bigger plugins, but never as the primary developer. Pods and Caldera Forms are bigger, but my contributions code-wise to those are not huge.

For Ingot I wrote all of the PHP code. Roy Sivan helped me build the admin interface, which is an Angular app. He was also a valuable sounding board and bug catcher for the rest of the plugin.

I wanted to share some of the lessons I learned, as a developer, writing a big plugin. Writing this plugin from scratch allowed me to put to test a lot of my personal opinions on WordPress development. I’m going to follow this article with one specifically about coding a plugin around the WordPress REST API and another with some lessons I learned as an entrepreneur from the process.

ingot-logo

Separations of Concerns

Working with the WordPress REST API helps encourage separation of concerns because of the way defining routes breaks up the process of preparing, processing and responding to requests. In addition, knowing that some of your CRUD will happen via your REST API, but not means you either have to wrap your API callbacks around a standard set of CRUD classes, or you need to keep two ways of reading/ writing/ validating and sanitizing data in sync.

The latter of those two options is insane. I went for the first. Ingot has a CRUD class for each of the different data types — test groups, variants, sessions, click tracking, settings — each of which extends a base class. Having separate CRUD class keeps the validation, sanitization and DB writing separated from every place that CRUD is ever used, including the REST API routes, and objects that represent groups or tests.

This also led to having one class to handle read/writes and  establish a pattern for using CRUD, along with smaller extending classes to define what fields are needed. I liked working this way. Even though these classes are likely to be called multiple times, I used all static methods for them. Yes, there are objects for single groups, tests and sessions that are often needed, but CRUD is just a collection of functions and without any application for an iterator, having to instantiate multiple objects of these classes wouldn’t have provided any utility.

I think of these classes much like how WordPress core’s WPDB class, which might as well be all static methods since we always use one instance, relates to WP_Query. We use WPDB to inject post collections into specific WP_Query objects that we can then iterate over.

The way I worked wouldn’t have been doable without late static bindings. In non-static methods, $this refers to the current object. So if the class is extended, $this is the object of the extending class. The self keyword doesn’t work that way. self in the parent class refers to the parent class, not the subclass extending this.

On the long list of reasons why I didn’t hamstring myself with conventions of a language that is almost 8 years out of date (PHP 5.2) is late static bindings. Late static bindings allow for static inheritance. The keyword static functions like self, except it can refer to a subclass method or property if one exists.

One thing I’m really proud of in Ingot is that I stuck to very small classes. For example, I have a class that creates a conversion rates stats object. This is separate from the class that creates an object for stats for all of the variants in the group, which is a collection of the objects of my conversion rates stats class. This creates re-usable code — the conversion rate class is used for variant and group stats, easier testing, and avoids code reuse.

Small, reusable classes are not just neater and more testable, they make refactoring easier. I rewrote about half of Ingot in the week before release. Short story — CRUD was overcomplicated and the testing algorithm was going to require tons of traffic, which would be a problem for a big part of our target audience. That’s a different discussion, but my point for today is that small classes meant more saved code during that refactor since it was very easy to separate the parts that still had a job from those that didn’t.

This is a concern moving forward. I am considering whether it makes sense to break the plugin into smaller Composer packages that I can assemble into different, smaller, task specific versions. Doing so could also allow for implementing a CRUD system that uses the posts and postmeta table instead of custom tables.

Composer & Dependency Management

Photo by: Steven SpassovI used Composer for dependency management and providing a psr-4 autoload. There is a ton of blog posts out there on why I love Composer and dependency management in general. The PSR-4 autoloader forces a directory and class naming structure on the plugin that makes it highly organized. Between that logical organization and being meticulous about inline docs, I think the code is easy to follow. We will see as other developers get into it.

I did hit some stumbling blocks with dependency management. I used Composer’s file map for including PHP files that are not classes, which I found to be annoying. Classes are added automatically to the autoloader, since it is based on logic. File and class maps are static lists of files and adding to them requires a composer update, which I didn’t always alert Roy to, causing unneeded errors on his end. It also makes switching Git branches a pain.

I chose to use Bower for managing JavaScript and CSS dependencies. Bower is a pretty slick tool, but ZIP file for the first beta version after I started using Bower was 2 or 3 times the size of the previous version. This was because I was enqueuing the scripts from bower_componets.

My solution was to use bower-installer to copy all of the main files — IE the ones I needed — to a separate directory. This allowed me to exclude bower_components and all the extra stuff from the final zip.

I went on a bit of a quest to reduce the file size of the zip files I was creating for releases. Another big win was setting this command in my build script:

composer update --no-dev --optimize-autoloader --prefer-dist 

This pulls in the Composer dependencies without their Git repos, or unit tests and optimizes the autoloader. Even with just a few dependencies, the file savings were pretty nice — about 6GB. Git repos are big.

Since the plugin is in a public Git repository I don’t think removing all this extra stuff that most end users don’t need does anyone a disservice or reduces their rights to modify the software. If an end user is a developer and needs the whole package, they can get it on Github.

I actually used very minimal third-party dependencies. But my testing library, the one I switched to later on, started out as a third party dependency. The library I used was built to use Redis to store data. So, at the least I needed to add a way to store data using my CRUD system.

Photo by: Marta PawlikAt first I kept the testing library checked out from the original source — and that author merged my pull request to fix a bug I found. In order to facilitate this I kept my class to save data using my CRUD in Ingot instead of in the library.


As I found more places where my usage of that library wasn’t fitting well with the original design, I had to make more changes that didn’t make sense as pull requests. So, I started using my own fork and making changes directly there.

I will soon evaluate if my fork makes sense on its own, as a version of the original that stands on its own and is useful to have as a separate project or if it needs to be absorbed into Ingot fully. Either way, being willing to dive into a dependency, learn it, and modify was the difference between throwing it out and having to do another huge refactor and being able to ship the plugin on time(ish).

Iteration vs Throwing Shit Out

Photo by: Rick WaaldersI had a lot of fun with this plugin. Working on something that doesn’t have any users yet is really nice. Once a project is released backwards compatibility and stability are concerns. When you’re iterating on something pre-release, you get to break stuff and start over.

It’s funny how quickly I can fall into the “fix it, don’t break it” mode out of habit that comes with maintaining plugins with lots of active users or contributing to WordPress. I literally had to tell myself a few times “don’t work around that bad design decision, you wrote it yesterday.”

As I said before, I re-did the base A/B testing algorithm pretty late in the process. This led to re-doing a lot of the CRUD and re-working the REST API and a lot of other parts of the plugin.

The lean startup mindset dictates the idea of getting to a minimal viable product quickly and improving it from there. WordPress preaches the idea of continual iteration. I agree with these mindsets and think that they work together well.

That said, neither of them can be an excuse for putting out something bad. When I started on Ingot I create a minimal viable A/B testing algorithm assuming I’d get it right — statistically speaking later — once I had everything else working.

stained-glass-110788_1280This made sense to me, and once I had everything else working I sat down to write the code to do the math. I could have done it and I wrote a lot of it, but I realized that my approach was wrong. Not only that, I was adding it on top of some mistakes I made in the structure of my CRUD — separating price testing from content testing.

So, I spent “two days” throwing out half of the plugin and starting over. It was painful to throw out that much code — OK, I enjoyed it because Josh — but I’m glad that I corrected my mistakes before version 1.

There are somethings you can only do right, by doing them once in a way that is sub-optimal. Knowing when to throw out tons of code that works, has unit tests and documentation is hard. It’s not worth doing when it’s because you could have made the code cooler.

End-users don’t care about how fancy the code is, they care about results and they care if you can keep it working over time. Refactoring in order to meet your product design goals better, and to ensure your code will be more easily maintained over time is worth it.

Give It A Read

A yellow flower in out-stretched hands.I hope you learned something from this post. I’ve resisted the urge to put in big code examples, as I wanted to keep it abstract. That said, you should feel free to read the source code. I’m happy to discuss these decisions I made, or how you can integrate with Ingot. Leave a comment or tweet at me.

Tomorrow I’ll post my feelings on what the WordPress REST API means for plugin development moving forward. It’s obviously something I’ve thought a lot about and putting my own theories into practice was one of the most valuable parts of this whole experience.

How The WordPress REST API Changes WordPress Plugin Development