Some Quick Thoughts On LoopConf

I was super lucky to be able to attend LoopConf last week. Ryan Sullivan and his team put on an amazing conference. I’ve never been to a fancy developer conference before, and I had a blast. Thanks Ryan for having me! I just wanted to share a few observations about what made LoopConf special and share my recommended videos playlist.

Before I go on, I should point out that while I don’t usually stay in hotels when I travel — I prefer AirBnB –Me and Roy Sivan being super classy by hotel fireplace– the Little America hotel in Salt Lake City where they put us up was classy AF. I didn’t know what to do with myself in such a big fancy room, but I super enjoyed sitting by the fire in the lobby and being classy.

One side of the fireplace had statues of dogs. The other side had a painting of wolves howling in the snow. Apex Classy.

Our REST API Workshop And Something New

Caldera Learn BannerRoy Sivan and I gave a 6 hour workshop on using AngularJS and the WordPress REST API. Honestly, we were worried we couldn’t fill 6 hours, but we actually ran out of time at the end. We had almost 40 attendees and people seemed to get a lot out of it.

I have embedded our slides below, and we also put all of the example code to Github. There is a ton of practical examples in there, some not finished to provide a start point for your own work. Some examples are running live on CalderaForms.com right now.

If you’re wishing you could attend an in depth workshop about the REST API from Roy and I too, don’t worry. We recently announced Caldera Learn. This new site will offer live webinars, recorded courses and code communities for anyone looking to level up their WordPress development skillset. It’s going to be awesome.

The Main Event

Photo by:  Anna Anikina

Our workshop was the day before the main event. LoopConf was a single track conference with excellent talks. They also did a great job of accommodating the hallway track. The room that meals were served in was open all day with the live stream playing. This was a great way to network and watch the talks. I wish WordCamps would do this.

The talks were a lot more focused on philosophy of code, then code. Not that there were not code examples. I really liked this trend for non-workshops.

For example, KAdam White talked about why the WordPress REST API was important for JavaScript developers and why he built his node.js client for the REST API, before showing code for a React app using both tools. Similarly, Natalie MacLees and Nathan Tyler shared their experiences learning React. They provided tons of React and general JavaScript resources in context of using the WordPress REST API.

John Jacoby Jones (JJJ) didn’t really show any code at all. Instead, he talked about lessons from Unix Philosophy that could be applied to WordPress. Andrew Norcross talked about improving our community by acknowledging and dealing with unacceptable conduct that happens in our community.

All the nerdy talks on how to code something or why to code something a certain way were book-ended by business-focused keynotes. Josh Koening of Pantheon talked about how the web has trended away from open source recently as companies have packaged what we created for the open web  in better experiences. He made an excellent point that most people can’t afford what free software costs — time and education.

Jason Cohen of WPEngine spoke about building a bootstrapped business. While he talked about pricing and product design, the best part of his talk was about managing yourself. This especially rang true for me when he talked about focusing on 2xing revenue over shiny features.

I’ve been working on both, and beating myself up over not delivering all the shiny new features I want for Caldera Forms. Those would be done if I wasn’t also working on a new tool that we’re testing right now. Then again, February is looking like a 1.5-2x growth for us versus January, so yah.

I really appreciated both of their talks and spending time talking with both Jason and Josh during the event. I was imagining LoopConf would be all out nerdy-codefest with out a ton of networking. But I got both.

Next Generation WordPress

Photo by: Alexey TopolyanskiyIn 2014 I went to WordCamp Milwaukee and saw two talks on the future of WordPress. Ryan McCue and Rachel Backer presented the beta of the WordPress REST API and Andrew Nacin talked about the WordPress REST API and the WordPress fields API being the basis for a modernized WordPress.

I was super-excited for the vision they shared, and got on the REST API bandwagon pretty hard. Of course, things turned out a bit differently then we expected then. At LoopConf Ryan gave a talk called “Next Generation WordPress”.

He talked about going from the blog era of WordPress, to the CMS era of WordPress and now the platform era of WordPress. Echoing what Matt Mullenweg said in the State of the Word about what got us here is not going to get us where we are going, Ryan suggested a new direction.

While State of The Word was all about user experience, Ryan talked about developer experience. I loved this obviously, as there is a reason I prefer to develop most things in Laravel than in WordPress these days — the developer experience — there has to be a balance here.

WordPress is a user-centered platform and that should never change. But, for users to get an improved experience, both from core as well as plugins and bespoke sites, we need to make it easier for developers to fit those needs. Ryan is, per usual a man with a plan. Definitely watch his talk, do what you can to contribute and let’s hope he gets a reasonable fraction of what he’s asking for there.

Vegan Food, Also Videos

I didn’t expect their to be such excellent vegan food in Salt Lake City, but I was impressed. If you’re ever in Salt Lake City, which I recommend strongly, check out The Vertical Dinner.

I’m still working my way through videos of talks I missed, but I created a highlights playlist from both LoopConfs for you. Check it out:

 

2016 FTW

 

At last year’s WordCamp Miami, I split an Airbnb with Vova from Freemius. We took an Uber to the speaker sponsor party together and one of the things we discussed on that ride was Caldera’s revenue from plugin sales. I was worried it wasn’t very good. But, I told him it was 3 or 4 times what it was last time I was at WordCamp Miami, so I felt good about it.

I know the time difference between WordCamp Miami 2016 and Miami 2017 or 2015 and 2014 isn’t exactly one year, but time isn’t linear. Nor is progress.

When I go to a WordCamp, I tend to think about where my career and my company where last time I was at that WordCamp. Since I often lack the ability to evaluate things relative to the proper time frame, this can be really helpful for me to see my growth.

By WordCamp Miami 2017  we should be at 4x the revenue from plugin sales as we were at last time I was in town for that event. We’ve also more than quadrupled the active installs for Caldera Forms. Because a new year is a great opportunity to talk about growth and goals, I want to share some of mine for 2016 and 2017.

But before I move on from Miami, I should mention I was also in Miami twice last year because my wife Alicia was performing at Miami Opera Festival last summer. I’m very happy and very proud that her career is also going well, and she will be an apprentice at Des Moines Opera this summer. What I do is hard, but nowhere near as challenging as what she does. I am so lucky to have her as an inspiration. Also, lucky to have her in general.

TL;DR (And This Is A Long One)

Here is this article in short bullet points for those of you who don’t have time to read the whole thing, and it’s real long:

  • Caldera Forms is growing – 4x user growth in 2016 and a lot of love.
  • Caldera matured a ton as a company. Asking Christie Chirinos to run the company was clearly the right decision.
  • I feel a lot better. Stress is way down, hopefulness is up.
  • A lot of fun stuff coming in 2017 from Caldera.
  • I wish I had written more, taught more and contributed to WordPress core more in 2016.
  • Team Caldera is growing. Maybe including you?

I can’t overstate how much happier I was by the end of the year then I was in the early parts of it. I spent a lot of time in early 2016 looking at job postings, considering taking my marketable skills to work for someone else. But, now I feel like powering through has gotten me what I wanted from doing my own thing — constant challenges, lots of fun and less stress. I’m honestly super happy with where I am now.

The Tasty Recurring Revenue

Photo by: Saul CuellarI’m the kind of person who quits a video game because I know I can win and moves on with life. Or I start over on a higher difficulty setting. I like playing, not winning.

The combined Josh + Caldera revenue is in the same order of magnitude for 2015 and 2016, but it has grown by decent amount. What’s more important is that the percentage of the revenue that has come from one off jobs has fallen significantly.

Numbers-minded people like recurring revenue beacuse it is an easier way to project revenue and therefore budget. Also, it tends to be more profitable.

But, I don’t do budgets — we’ll get to that shortly. What I don’t like about one-off jobs is the lack of personal investment. I don’t care for games with final boss battles.

What’s fun about software is it never ends, what’s fun for me, about working on projects I love or with clients I enjoy working with is that it never ends.

When we complete a Caldera Forms release, I don’t get a ton of joy out of that milestone. But my favorite part about the release process is the last step — I fork the master branch into the develop branch and set the version number ahead.

In addition to increased plugin revenue, we also added recurring revenue from maintenance agreements.  The normal play with that type of business is to sell a bunch of low priced maintenance plans that come with scalable and predictable work.

We did the opposite. High price, lots of work. It’s fun and I’m learning a lot form it. It’s not something we advertise, because we don’t have the resources to scale this part of the business, but we’d consider adding another if the client had interesting enough problems — preferably needing help with improving eCommerce performance and  conversions.

Changing The Team: Part 1 🙁

I didn’t create Caldera Forms, I started out as a user.

I originally tried out Caldera Forms, because I was impressed with work David Cramer, who was the original developer of Caldera Forms had done on Pods. I was immediately impressed and wanted my plugins to have that kind of user interface. This was before WordPress people got all excited about JavaScript driven-interfaces and David had basically built his own reactive JavaScript framework on top of jQuery before reactive frameworks were really a thing.

When I said I wanted to start my own WordPress plugin company and started recruiting those I knew, I was super excited David was on board.

The last time I wrote about the progress in our business, was in June. That article was canablized from a 2015 year in review article I never finished. I didn’t finish it in January of 2016, as I was really unsure at the time where we were going and if the company was going to survive as a team, which at the time was me and David.

In that article I wrote about struggles I had been having with David Cramer, who was the original developer of Caldera Forms, but how I felt we had patched those up and things were going better.

Unfortunately, that didn’t last. David is super-talented and he’s working on some really exciting new stuff right now, but he’s no longer working with us. In the end, we had a different vision for how to develop and manage Caldera Forms. David wanted to build new things, and so did I, but Caldera Forms has taken of to the point that it has to be priority number one.

I look forward to helping promote his new business when it launches. Please check out his new plugin DB Post Types. It’s a tool for organizing WordPress data into useful, and editable reports. A super useful tool that I’ve been excited to try out since I saw the first prototype for it.

When CalderaWP started, I had David keep control of the CalderaForms.com domain name and the WordPress.org repository so he had leverage over me, since I owned the company. When he left, we bought those assets from him. Seriously, I wish him the best and with that it hadn’t ended this way, but it was the right call.

Changing The Team Part 2 🙂

Photo by: Marcin CzerwinskiAt a dinner after WordCamp Pittsburgh I asked Devin Walker, lead developer for WordImpress of Give fame, if he could imagine doing his job as lead developer and doing the math on their budget and physically making sure the bills were paid. He laughed politely at me when I told him that’s what I was doing until recently.

It’s well known that I do too much and I enjoy working on a lot of things. But I also know that too many decisions in a day is mentally fatiguing and it is essential to stick to what you’re good at and find someone who can handle what you’re not good at.

In that post, I also announced that we had merged all of our operations under one umbrella, called Caldera Labs, and that it would be managed by Christie Chirinos. This has gone incredibly well.

Until May of this year, I never received a regular paycheck. Previously, I was living month to month and so was the business. Neither had a reasonable idea of what next month had. This had a pretty strong affect on my stress level.

Now I get a paycheck, the business’ books are in order and we have a budget. These things lead to not just less stress, but the ability to effectively manage the ups and downs in month to month revenue.

At WordCamp US when Christie and I sat down to discuss goals for early 2016, she made me start with not just what I wanted to do, but why I couldn’t do it. She’s been working since on removing the barriers that are surmountable and reminding me to be patient with what can’t be changed yet.

At that point I began to suspect that Christie is doing, on a higher level, is going through the business and identifying inefficiencies and systemic problems and addressing them when solutions are possible.

That goes hand in hand with being strategic about what we do and what we plan to do next. My biggest goal for this year was to stop running a business based on putting out fires and building shit just beacuse it would be fun.

Look, I think that being crazy is in my job description. “Let’s build a WordPress form builder, there are tons of well-loved competitors that are established and years ahead of us” is a crazy pitch for a business. What we’re doing is hard AF, but that’s what makes it fun for me. Also, it’s what sets us up for where we are going.

My strength is seeing how to put things together and what’s wrong with how systems are assembled. It’s a great skill set for a programmer and a product designer. Not a great skill set for running a business.

This part of me is why I’m good at what I do, but it can create bad feedback loops if I’m not patient. My personal growth this year, has been about getting better at focusing on changing the things I can change, accept the things I can not, and find the wisdom to know the difference between the two.

Becoming more strategic and intentional about the business has taught me, as a developer about dealing with technical debt. You don’t just start with the problems that are easiest to fix or those that have the biggest ROI in terms of getting them fixed. You have to evaluate what systems that are badly in debt touch which systems and what their technical debt it. That’s where you start. I learned this from watching Christie add prioritization and structure to our business, which in of itself was independently useful.

I know have a strategic partner who believes in this plan, and sees many ways to get to some version of the goal. That’s super important. I’m lucky to have so many people to call on for help, and to talk things through with, but having someone focused on co-developing that strategy and executing it is huge for me.

When I read Pippin’s year in reviews and he talks about how much better AffilateWP is doing, in less time, than anything else he did, I’m not just happy for Pippin and looking to see what lessons he learned can apply to us. I’m also reminding myself that he couldn’t have had that success without years of developing his team and his process.

So I’m learning to be patient, but I also have a ton more time to work on things. It’s seriously amazing to me that contracts can get negotiated, signed and invoices sent with little involvement from me.

These changes have taken longer than I wanted, and took a lot more work then I can imagine.  But, the percentage of time I spend doing what I want to do (and having that align with the company’s goals) vs doing what I don’t want to do, but have to do, because it’s necessary for the company has also improved dramatically.

Growing The Team In 2017 Part 3: Maybe You

When Christie started, Jason from Postmatic told me to be patient. He reminded me that I was better at running our business than her, by virtue of experience. But, my belief was that by nature of her skills, she could get better at it then me if I was patient and supportive.

Jason was right, and it was an important reminder, because patience isn’t one of my virtues. I’m trying to keep this in mind, as a major goal for 2017 is to grow the team even more. Right now that doesn’t mean partner-level or even leadership-type positions, though we will probably be looking for a lead UI developer and a marketing director later on in the year.

Bringing Christie on was like getting a new developer as it greatly increased the amount of time I could spend writing code. We got through last year with me handling almost all support and development and contracting out development work.

We specifically contracted out development work that required skills I don’t have. This was great as it reduced my stress-level and increased the quality of the work.

But, we’ve been relying on short-term agreements per project from friends who are talented, but busy. We’re currently working through the interview, trial and hire process for a few jobs. It’s not an easy process.

Training and evaluating new people is way harder then just doing their jobs myself. But that’s a long term investment, as I can’t keep doing everything and the more other people handle support and bug fixes, the more I can work on Caldera Forms and the larger Caldera/ Ingot road-map (spoiler alert, its the same roadmap.)

If you’re interested in working with us, we’re going to be very interested in talking with people who are interested in starting with us as a junior developer and support person. That’s where I started at Pods, and it was the most amazing learning experience. And I literally wouldn’t be here today with out that.

If helping our users out, while improving our product and learning from me sounds fun — get in touch.

Growing Beyond My Brain

Photo by: petradrAt WordCamp US we had a running joke about being a “grown up company.” The fact of the matter is this year we really did grow up. Even if part of that was acting sillier than we ever did.

On one hand we know have our books in order, a formal budget as well as an accountant and lawyer. On the other hand, DMing my friend Michal and asking him to put our logo on a taco was a real business man thing I did this year.

After WCUS Taco Club and the WordCamp US, I was waiting for an Uber to take me and my friend Steve to the airport, Christie and I talked about car accidents we’d been in. On the plane ride home I started thinking about what happens to my grown up company if I get hit by a truck again. Because, that’s a thing that happened to me at time, I couldn’t use a computer for 2 months while my shattered collarbone healed.

The point here isn’t that you need emergency plans for your business. But that is a thing we have now. The point is that by necessity our business started out as being mainly run by me, and me alone. As a result so much of the knowledge necessary to work for Caldera is in my head.

For 2017, we’re growing the team and the product and that’s going to require getting more of that knowledge into documentation and other people’s minds. That’s hard AF. This is an incredible challenge that I only recently realized the scope of.

Whenever someone asks us a question, it’s faster for me to answer it then train someone to answer those kinds of questions. It’s faster for me to keep using some hack to fix a problem then to fix it for real in away anyone can use.

I see Marc Benzakein from ServerPress a few times a year at WordCamps and we talk a lot about growing my business. One thing that always comes up is getting more people to associate Josh with Caldera. This goal goes hand in had with getting people to see Caldera as more than just Josh. While that second part is true, to make it efficient, we need to work on documenting our processes better, and better team member onboarding.

In July I presented at WPCampus, the same weekend that Christie presented at WordCamp NYC. Caldera had never been in two places at the same time like that and it was something I was intensely excited about and proud of. Also a little jealous beacuse she got to speak at the UN…

No one should be as obsessed with this business as I am. It’s an intense level of obsession, and I hope that passion shows in everything we do. Not to say Christie isn’t obsessed with this too, but she didn’t build it and people we hire to help out with development and support sure didn’t.

Our next challenge is making sure that the passion for the product shows in every other team member and is backed by knowledge of the product.

Branding

CalderaWP WapuuWhen Caldera started, I didn’t think of Caldera Forms as a big part of our plans. I felt like it was a part of what we would create. For example, one of our launch products Easy Pods, uses Caldera Forms to create search forms for Pods content.

We’ve made a lot of different things, but nothing has taken off like Caldera Forms. We started the year at 10,000+ active installs of Caldera Forms and ended it  at 40,000+.

Passing 40,000 installs in late November was huge milestone and it happened right before we pulled the trigger on a site relaunch. The old site was at CalderaWP dot com and tried to present multiple product lines equally. That site was built for a different company than we ended up having. The more I hacked on it to make Caldera Forms more prevelant the weirder it got.

So, last fall I through it out and started over from scratch. In December, we relaunched the site as Caldera Forms dot com. It’s now way more focused. We also added a new build your own bundle feature at the end of the year to respond to concerns from users that they wanted to choose which add-ons went into our lowest priced bundle, instead of the 5 we chose form them.

Building the new site was super time consuming, and we saw a short term drop in sales as we ironed out bugs, and dealt with some problems in search results. But it seems to have picked back up and complaints about the usability of the site or problems finding add-ons or documentation have dropped significantly.

Adding that bundle builder, is the first step of moving towards a Caldera Forms driven eCommerce interface on the site. The content management for products and software licensing will still be managed by Easy Digital Downloads, but the interface will more and more be Caldera Forms.

In addition, we will be making use new tools built on top of Caldera Forms, Ingot and Easy Digital Downloads that I are being developed first for site and then will be externalized as products. I’m really excited about what we’re budiling to improve selling digital products and look forward to showing them off soon.

This kind of dog fooding has been great. I’m trying to take an Amazon-like approach to building everything as a service that can be turned into a product as needed. It’s a bit of a tough balancing act as when I build stuff for our site, I don’t need a UI, and I don’t have a ton of time.

But this forces me to build software with proper architecture from the start. If I can write code that can take its configuration as a dependency, it doesn’t matter if that configuration starts hard-coded. If and when the internal tools I’m building now become products, I can easily add Caldera Forms processors, REST API endpoints, and/ or a CLI for end-users to configure them.

Missed Goal: Teach More

I love to teach. Caldera has from day one, had a goal of providing WordPress plugins and WordPress. One of my huge goals for 2016 was to write more, teach more and contribute to WordPress core more. I wanted to release several new courses.

I released a REST API course in January and thought it would be the first of many I’d do in the year. We held some workshops in September, which were recorded. I loved teaching those and want to do more. BTW fun fact — for a reasonable fee I will come to your city and teach WordPress development workshops to your company or meetup group. For an extra fee, I’ll bring Carl.

The workshop video is edited and I’m going to do some re-recording this month to fill some gaps. I’m really excited to get this course out there and to really make Caldera Learn a great resource for those looking to level up their WordPress development and satisfy my need to teach others. Also, it should be another good revenue source, that will help us grow our team further.

I want to say a special thanks to Ryan Sullivan. He made the workshops possible by sponsoring them in the name of his company WPSiteCare and the conference he organizes LoopConf. We needed sponsorship money and Ryan is super generous and I’m sure he sees a good ROI in having me say nice things about WPSiteCare, which I don’t mind doing as they have an awesome product, that we recommend all the time.

I was a contributor to all three major releases of WordPress in 2016, which felt good. I didn’t do a ton of work on core. I wish I had done more. A patch or two per release is not particularly time consuming. I hope to do more in 2017, and I think that as we work to create more margin in the business that will be great.

Caldera Forms

Caldera Forms Globe LogoThe website project I discussed earlier was long-overdue, our old site was terrible. I was OK with that for awhile, as I was actually trying to slow down our growth in early 2016. In later 2015 people started to really use Caldera Forms. In 2016 we had 180,000 downloads. We have slightly over 230,000 downloads total as of now. That gives you an idea of how big 2016 was for us.

That’s awesome, but going from 1,000 to 10,000 active installs exposed a lot of problems with Caldera Forms. We spent a ton of time in late 2015 and early 2016 fixing the kind of problems you don’t find until you get a real user base. We stopped adding new features and just focused on making what we had be more reliable.

Getting through that wasn’t easy, but I grew a ton as a developer, and the product was well postioned for the rest of 2016 as we went from 10,000 to 40,000 installs while decreasing the number of support tickets and solved most email related issues.

Serious pro tip: setup DKIM and SPF records for your domain and use a transactional email service. If your contact form submissions are going to spam, your DNS is probably not setup right. You can fix it in 10 minutes.

I got into WordPress while I was in grad school at Goddard College, a small hippie college in Plainfield, Vermont. Plainfield, Vermont also happens to be — until recently — the home of Jason from Postmatic. This is purely coincidental, Chris Lema introduced us.

In May of this year, I spent part of a week working out of Jason’s offices in Plainfield, which was a great time. We talked a lot about Caldera Forms.  At the time I was really excited that we had a solid plugin that worked. But Jason opened up a WordPress site and showed me what my next “what’s wrong” was: new user experience.

We call Caldera Forms “A Different Kind Of WordPress Form Builder.” Many of our users are new to WordPress, but others are trying us out after using other form builders. Last time I checked the stats, Contact Form 7 was the 3th most common plugin to be installed on a site using Caldera Forms — that’s behind Aksimet and Yoast SEO. Getting people passed their existing expectations of what a form builder can do is not easy.

Caldera Forms 1.4 started with that talk with Jason and running his feedback by other developers and users. In that release, we emphasized form templates over creating forms from scratch, changed a lot of our verbiage, and added a lot of context clues to the form layout builder.

Getting users to start from a template helped the form builder teach itself to users. No amount of documentation, which we also improved, including a new getting started guide, can beat that. Still some, users will start with a blan

In his Caldera Forms webinar for iThemes Training, Benjamin Bradley said he appreciated that the Add Field button was blinking when the form had no fields. This was pretty great vindication for me, as making that button “pulsate in order to draw the user in” was one of my wackier ideas I had, but like Taco Club, it worked out pretty well I think.

It was very liberating to refine things that worked, but could be better instead of just putting out fires.

While Caldera Forms 1.4 was our only major release in 2016, we did add a lot of new incremental improvements to Caldera Forms, and some new features. These include magic sync for fields, SendGrid integration, improvements to conditional logic as well as hidden fields, better file upload fields, field duplication, and a ton of new features as well as better infrastructure for add-ons.

Most exciting new features came in add-ons. We released recurring payments via BrainTree and Authorize.net. We added ConvertKit and Aweber add-ons for email marketing. We also added a form translations add-on and several other cool new add-ons.

Our Form to PDF service is our first SaaS product, and my first time launching a customer-facing app in Laravel, which I’m loving working with. In 2016 look for Caldera Space — we’re too cool for the cloud, we went to space — to grow even more cool new features to make Caldera Forms better.

After 1.4 came out, we split our Git development between a 1.4.x branch and 1.5.x branch. The idea was new features went in the 1.5.x branch and bug fixes went into 1.4.x. On one hand this has been great as we put out a minor update for Caldera Forms roughly once a month with small bug fixes and occasional small new features.

On the other hand, version 1.5 is full of big, exciting new features. Some of them are interdependent on others and it makes sense to work on them in isolation without worrying about breaking the branch we count on for bug fixes.

But, there are some really cool new features that were relatively simple, that could have already been in user’s hands like conditional recipients and scroll to top after submit. I think I’ll revamp this approach once 1.5 is done, and it is almost done. I like having a safe space to break stuff and rebuild it while developing internal APIs for multiple features, but I also with I had finished 1.5 already.

More importantly Caldera Forms 1.5 is going to be hella awesome. It’s got a 9 new field types, a new front-end entry viewer powered by the WordPress REST API, new default processors and more. I also removed all the inline JavaScript rendered in post content. This will reduce bugs with themes that do strange things to post content, and also allowed me to improve the efficiency of our front-end JavaScript a bit. We’re also loading less front-end JavaScript and CSS, so performance will be better.

Last time I searched the source  for “@since 1.5.0” I got over 220 results. For everyone of these new features I approached the work with a “no new technical debt perspective.” This meant new internal APIs and formalizing conventions into programmatic rules. As result the time spent developing new features was also time spent improving the quality of the code and therefore stability of the system.

Pricing Changes

strawberriesAt WordCamp San Diego I sat down with Pippin to talk about our growth and what we could do to improve it. He asked me what our average cost per sale was. I didn’t know, but he told me it was a safe guess that it wasn’t great.

I wrote a quick plugin to do the math and he was totally right. Increasing our average cost per sale has been a huge focus. BTW I later found Scott Bollinger’s EDD Metrics plugin which is great for tracking these types of numbers.

Soon after we launched bundles, which has gone well, but we’re still seeing too many single add-on purchases. When we launched bundles, the single add-on pages on our old site were made to highlight single site licenses or bundles.

That didn’t go well as it hid multi-site licenses making our add-ons seem way more expensive. For example, it wasn’t obvious that you could get a $89 five site licnese for our MailChimp license, it seemed like you would need $250 worth of single site licenses, which if true wouldn’t be fair.

In December we launched our 3 add-ons for $79, 5 add-ons for $139 bundle builder. This required building a cool new Caldera Forms integration for Easy Digital Downloads. I also modified the site to make the options more clear. It’s too early to say if this is working, but early numbers for January look good.

Taco Club

WordCamp US Taco Club Caldera Forms LogoOK, this is getting really long, but I have to mention WordCamp US Taco Club, beacuse that’s a very real thing that happened this year the night before WordCamp US. We had more than 30 people over to our AirBnB for a taco party.

This event was great, we got to meet Caldera Forms users, make new friends, see old friends and enjoy a taco bar together. It was great fun, and on a suggestion from our friend Kyle, we made an epic WordCamp Mannequin Challenge.

I look forward to having more fun, and non-exclusive events around WordCamps this year. They might not all be Taco-flavored, but I hope their corresponding limited edition stickers are as cool.

Personal Life

One thing I strived for this year was to get out of bed earlier and limit my work hours a bit. Working 100 hour weeks definitely took a bit of a toll on my health and ability to relate to other human beings.

That said, I’ve also come to peace with the fact that my work is my life, beacuse I love what I do. I know I’m supposed to strive for better work/ life balance. I definitely spent more time reading and otherwise indulging in my passion for science-fiction. But, I’m OK with the long hours and I’ve never found anything more fulfilling than what I’m doing now.

In sadder news, my cat Shy died in 2016. She had been with my wife and I since we moved in together in 2001. When we moved to Florida she claimed my office in our new office as her own. I spent most of those long work hours with her sleeping on my lap, on my desk or on the futon behind me.

It was definitely her time, but I miss her.

On a happier note, our other cat Gus has really thrived as an only cat. He’s closer with us and he’s actually made friends with our dog Josie. They cuddle together sometimes, which is super cute.

Josie is doing great and was even selected as our vet’s pet of the month for December. I’ve never been prouder of her. She’s a great doggo.

As I said earlier, this was the first year that I got a regular paycheck for an extended period of time. I also turned 34 this year, so it shouldn’t come as shock that my personal finances are not great. Nothing too terrible, but my wife and I spent a lot of money this year on paying down debts, which is annoying, but important.

At the end of last year my wife bought me a Chemex for Christmas. Coffee optimization has become a big passion of mine. Thanks to having a great way to brew coffee — you’re not still using a machine are you? — and the fine work that the people of Lucky Goat Coffee do, I’m drinking better coffee and coffee has become a shared experience — this thing takes awhile, but it’s worth it — we do most days together.

2017 Goals

Photo by: Ales KrivecOK, so now I need to stop before this turns into a book, though I do wish I could tell some more stories. I have so many great stories, like the time Rich Robinkoff talked me into going to WordCamp NEO to talk about the importance of stories.

I haven’t talked about everything. I’ve barely touched the 10 or so WordCamps (I’m counting WPCampus) that I attended. Nor have I talked about some of the cool projects I’ve been a part of — for example I got to work on Cookbook a very cool new recipe plugin from WPSiteCare. I’ve glossed over Ingot, beacuse I’m annoyed I didn’t get to work on the core plugin this year, but I’m excited for the evolution of that product line, which is underway.

But it’s time to go, so here’s what I want to do in 2017:

  • Triple user base and revenue from Caldera Forms
  • Convert all checkout and license management forms on our wsbsite to Caldera Forms and externalize that as products.
  • Improve the analytics and marketing automation tools we use for Caldera Forms and externalize those as products. I gave a preview of some of that at WordCamp US and am pretty excited about what come next.
  • Release the course we’re working on now, create shorter content to use for lead generation to help sell the course and test new tools discussed above.
  • Grow the team.

wordpress-logo-simplified-rgbOk, that was a lot, but it was a huge year. If you’re reading to the end — or just skipped here — the shortest version is I’m a lot happier with my professional life now then this time last year. That’s awesome. A ton of people have had a lot to do with that and I hope that everyone of them and everyone in the WordPress community knows how much I appreciate them for being so awesome.

WordPress Authentication (over) Concerns: A Quick Case Study

A big push back against the WordPress REST API has been a feeling that a lack of authentication system makes these endpoints not useful. This is strange to me, since the content endpoints use the exact same permissions system as the rest of WordPress.

I think a lot of this confusion comes from the excitement about building cool apps that connect from outside of WordPress via the REST API. In those cases, WordPress’ cookie-based authentication does not work. Therefore a different solution is needed. oAuth1, oAuth2, JWT, a custom system, etc.

I like JWT a lot by the way in those scenarios. This plugin makes it very easy.

But what about when we are using the REST API to improve WordPress from inside of a WordPress theme or plugin? Or what if — presuming the content endpoints make it into WordPress 4.7?

In those cases, cookie-based authentication, which is super easy to use, is all we need. This is especially exciting for core. I’d love to see the REST API used for content editing in the front-end and/ or the customizer. Also, what about new ways we could work with terms or custom fields in the post editor, or combine editors for multiple content types, or build dynamic list tables?

Today I made up a quick prototype of a front-end revisions browser for posts. It took me about an hour, and most of that time was spent figuring out how revision endpoints worked — I had never used them before — and working through a bug in the REST API that was quickly resolved.

I’d like to briefly show you how it works, and discuss using cookie authentication, as well as why that was the best choice.

If you want, you can check out the code here. Also, if you want to learn more about authentication using the REST API, I have a section of my REST API course that covers this topic.

Photo by: Philipp Reiner

Why Use Cookie Authentication?

The first question is why use cookie-based authentication for this type of problem. The short answer is “why not?” I mean, why does having a REST API in WordPress mean that we have to suddenly start using a second authentication system? We don’t do that with admin-ajax?

The REST API does force us to use a nonce, in a way that admin-ajax does not, which complicates this by 2-5 lines of code. If only admin-ajax had been designed the same way, we probably could have skipped a few thousand XSS and CSFR vulnerabilities in plugins and themes.

How Does Cookie Authentication Work?

Cookie authentication works exactly the same way as it does in any other WordPress request, which is to say pretty much automatically, if we send the right nonce. That nonce, which must be created using the wp_rest action, can be sent as a header or as part of the query in a GET request or the body of a post request.

In the plugin I built as a proof of concept for the revision browser, I localized the URL for the current post’s revisions endpoint, and included the _wpnonce query argument, like this:

	$api = add_query_arg( array(
		'_wpnonce' => wp_create_nonce( 'wp_rest' ),
		'context' => 'view'
	), rest_url( sprintf( 'wp/v2/posts/%d/revisions', $post->ID ) )  );
	wp_localize_script( 'revision-browser', 'REVBROWSER', [
		'api' => esc_url( $api ),
		'nonce' => wp_create_nonce( 'wp_rest' ),
		'content' => $selectors[ 'content' ],
		'title' => $selectors[ 'title' ],
		'links' => $links
	]);

That’s pretty simple. Another approach would have been to put nonce as a key in the REVBROWSER object I was localizing. Then I would have had to add a header to my request. To make that work I would change my AJAX request from this:

$.get( REVBROWSER.api ).success( function( r ){ ...

To something like this:

$.ajax( {
   url: REVBROWSER.api,
   method: 'GET',
   beforeSend: function ( xhr ) {
      xhr.setRequestHeader( 'X-WP-Nonce', REVBROWSER.nonce );
   },

} ).success( function( r ){ ...

Either way pretty simple and works perfectly with WordPress as-is. No one who isn’t authorized to view revisions can see these revisions.

What About admin-ajax?

I could do that with admin-ajax (image meme)This is the point where someone mentions that I could have used admin-ajax. That’s totally correct, but let’s talk about what I didn’t do when I built this, but would have had to with admin-ajax.

I didn’t write any new code to collect revisions and convert them to JSON. The content REST API does that for me. This kind of efficiency is why we use open source software.

I also didn’t worry about authentication, authorization or cross-site forgery. That’s handled by the core API for me. I could do all of that myself, and hopefully not mess it up. But I didn’t have to. The next person who does this might be not as picky about security issues as I am. When we off-load those concerns to core, we get help from all of the other people working on the project. This is why we use open source software.

And it’s important to say again that not everyone exposing private content or allowing updating of content via admin-ajax has added the right permissions and nonce checks. Our ecosystem has been harmed by the fallout of those mistakes. The WordPress REST API will not make developer-errors that cause security vulnerabilities go away, but it will help.

By the way I did this once before for Lasso using the custom API I built for that plugin. It took Nick and I a long time. What I built today, needs some UI work, but could, if there is a content API in WordPress core, be polished patch for WordPress core without much more work. I’d love to do that if possible.

Being Loved Isn’t Enough

My dog Josie begging in my kitchen.
This is my dog Josie.

One argument for the REST API’s inclusion in core is that so many people are excited about it. I think that is a decent argument. We need people to be excited and passionate about building cool stuff with WordPress.

But that’s not enough. Having a standard way of working with WordPress content via a REST API is about creating new tools for end-users while following a standard and working together on improving the tool we all love. That’s why we use open-source.

The Core Team Wants To Know What You Think

Earlier today, Helen Hou-Sandi, a lead developer of WordPress and the release lead for 4.7 asked a question on Twitter that led to a bit of a discussion and then this proof of concept.  There has been several posts on the WordPress core development blog asking for comments on the REST API merge proposal and invitations to discuss further in Slack.

That’s awesome. This is a big decisive for a big project and I love that those making the decisions are so open to a public discussion.

Get involved y’all.

 

Getting Started With Modern WordPress Development: What You Need

I’m teaching a few workshops this month aimed at those looking to level up their WordPress development chops. It’s got me thinking a lot about what you need to do quality WordPress development.

It’s a very subjective question, what software to use, what principles to value, what resources to learn from… So I wanted to share my thoughts on what is necessary for getting started. The list is less about software, and more about concepts because in the end, it’s about the wizard, not the wand.

Tools

You can write code in notepad and FTP it up to a shared host and hope for the best, but to do it right you need some basics tools. Here is my opinionated list. I’ve broken it down into “basics” and “important”. The first category is things you should have right away. The second list is important, but can probably wait.

Basics

Code Editor and IDE

A code editor is a specialized text editor designed for writing code. I like Atom as my simple code editor. It’s the application I use when I just need to open up a file, read it and maybe make a few changes.

An Integrated Development Environment (IDE) is more than a code editor. A good IDE provides everything you need to develop in a language. I do most of my work in phpStorm. I use it as a code editor, web server, terminal, sFTP client, Git client, and more. I probably don’t use half of its features.

Git and A Git GUI

Github Social CodingYou must use version control. It’s just not optional if you need to do anything large in terms of development or work with others. It will also be a part of your deployment strategy.

I wrote more about why you should use Git on the CalderaWP blog. WP Pusher, which is an excellent tool for deploying Git repos as plugins and themes, offers a Git course on their site that is worth checking out.

While I use the command line and phpStorm for Git most of the time, I am still a big fan of SourceTree and it’s one of a few reasons I miss using a Mac for my primary development machine.

Local Development Environment

Installing A Site With DesktopServerThe reasons to use a local environment are numerous. The short answer is — it’s faster, more secure, and no one can see your fails.

There are a lot of ways to set up a local environment on your computer.  Here are the ways I recommend, in order of ease of use:

  • DesktopServer – A simple application that gives you an interface for creating local WordPress sites. Start here if you are new to local development. It’s easy and might be all you need.
  • Valet – Made by the Laravel project, but works with WordPress. I use this on my Mac (never figured out how to get it to work in Ubuntu.) Requires Composer, homebrew and a bit of setup.
  • Vagrant – Vagrant creates a virtual machine on your computer that you can use for development. I use the popular VVV project for setting up a WordPress development environment on my main computer.

Important

Dependency Management Tools

Mandelbrot FractalI’m going to go less in depth here, as I’ve covered Composer quite a bit here and on Torque. Seriously use Composer, it makes PHP development better and easier.

Other tools I use for dependency management and task running:

  • Composer
  • NPM
  • Grunt
  • Bower

xDebug

When doing JavaScript development, you can use the browser’s developer tools to debug your code. You set a break point to stop execution and see what the variables equal at that point.

xDebug gives you that for PHP. It’s an amazing tool that takes the guess work, and the vard_dump()/die(); out of development. xDebug comes pre-installed in VVV and works great with phpStorm.

Concepts

Basics

Photo by: veeterzyIf you’re brand new to development, you need to get PHP and JavaScript fundamentals down first.

I’ve written a ton on PHP over on Torque. I recommend starting with my PHP fundamentals article and then looking at my article on using WP_Query to learn object-oriented PHP.

For JavaScript, I like CodeAcademy’s JavaScript course. The book “JavaScript The Good Parts” is also worth reading. Like most WordPress developers, I started with JavaScript by using jQuery and starting in jQuery being a smart start is the consensus we came to when we discussed this on an episode of The WPCrowd, which I followed up with an article on the same topic on Torque.

The WordPress Way

It’s hard to define the WordPress Way, without jumping into WordPress code, which you totally should do. The best way to learn after all is to read the source.

In addition, you really should read the WordPress handbooks:

If you take one lesson from the handbooks, it should be that there is a standard for documenting code and that you should follow it. Inline documentation makes it easier to work with your code, it makes it easier to read your code and it’s super useful to developers who are not familiar with your code.

Principles

I am very much a believer that pragmatic adherence to certain principles will make you a better developer. At a minumum, I think you should familiarize yourself with the single responsibility principle and the do not repeat yourself (DRY) principle.

Class Autoloaders

I’m a huge beliver in using a class autoloader. It’s becoming more common in WordPress, but is still behind. I covered using a PSR-4 autoloader and Composer’s autoloader in an article for Torque.

An autoloader is simple to setup and it forces a logical directory structure and class naming system on to your plugin or theme.

The WordPress REST API

As you probably know, I’m a huge advocate of the WordPress REST API. I think it’s super important for advancing the quality of code and end-user experience we can deliver.

I’ve written a ton on the REST API to help you get started. But, in my mind, it’s not just about learning the REST API. It’s about learning how to write plugins, themes and site-specific code that can be used with theme templates, shortcodes and the REST API.

TL;DR

Photo by: Paula BorowskaPaula BorowskaOk, that was a little long, but here is my summary:

Use local development (start with Desktop Server) and Git (Github and SourceTree FTW.) Composer and autoloaders are awesome. Read Carl and Tom and document your code.

I’ve linked to a ton of free content, mainly by me, to help you learn. I have two WordPress development courses. One on the WordPress REST API and one on modern WordPress development. You should check those out if you want to learn more and say thanks for all the articles and WordCamp talks that I’ve done to help educate the community.

Deploying WordPress Plugins and Sites Built Using Composer

I’m a big fan of Composer, which I believe will give you super powers. I am happy that it is gaining in popularity in the WordPress world. I often hear from developers who love it, but are not sure what to do about the vendor directory in their plugins or themes or sites.

I spoke about the advantages of challenges of using Composer in a recent episode of The Plugin Architect podcast. I use Composer in most of my plugins. Most of Ingot’s code is in Composer packages, which helps us share code between different versions and add-ons. I also helped refactor the plugins Maps Builder and Maps Builder Pro by WordImpress to make sharing code between the pro and free versions easier.

Often times people are not sure what to commit or gitignore and the best way to deploy their code to keep their package size small. I’d like to answer a few questions to help you make the best of Composer for WordPress development.

Should You Ignore The Vendor Directory In Your Git Repo?

TL;DR yes.

A lot of people are hesitant to gitignore the vendor directory and other dependencies in their GIT repos. Most of the managed hosts encourage you to use GIT to manage your dependencies when using GIT as a deploy tool. This is not good practice for  a few reasons.

First, it is messy and redundant. Why should I use a GIT to manage changes in code that is managed by a different VCS system? It doesn’t make sense. A change to a dependency should require a commit in the configuration file for Composer, Bower, NPM, etc, but not commits of actual code.

Also, keep in mind that by default, Composer checks out all packages as GIT repos. That’s great in development, but not something you want included in your final product. Composer is built with this in mind. But you should not ship your plugins with Composer packages as GIT repos or push GIT repos of dependencies to your site.

Down with redundancy and bloat, folks.

Solutions

TL;DR –prefer-dist

Let’s talk about two scenarios, site deployment and shipping plugins. The solutions are pretty similar.

Site Deployment

The first situation is where you are deploying a site using GIT and Composer. If your live server has Composer installed — a rarity for some bizarre  reason in the WordPress managed hosting space — then this is easy. Use Composer to manage dependencies and gitignore the vendor directory and when you deploy use the –prefer-dist argument to tell composer to not checkout the whole GIT repo.

Laravel Forge, which is a server provisioning and deployment system of industry, has this line in its default deploy script:

composer install --no-interaction --no-dev --prefer-dist

This tells Composer to install with none of the packages that are required for development only, like your unit test framework, and to get the packaged distribution of the dependency, not the whole GIT repo. I have no idea what --no-interaction does, but let’s assume its good.

You probably want to add –optimize-autoloader to that if you’re not using Laravel, which runs that in one of its post install scripts.

Plugins

CalderaWP WapuuI make more plugins than I make sites. Most Caldera Forms add-ons use Composer to manage at least two dependencies. I’ve written a Grunt script that helps automate this process. It checks out all of the dependencies using composer update --prefer-dist and then copies everything to a sub directory, which it then zips and deletes.

This means that my plugin repos, have a directory, usually called releases, with a ZIP file I can upload to our site. I used to add an automated SVN deploy when I was working on plugins that need to go to WordPress.org. Now I just open that ZIP file and drag it into a new tag inside the SVN repo, opened with phpStorm and commit that.

What Else?

TL;DR Alot
Photo by: Jasper van der MeijThere are a few other challenges when using Composer. But I really do think they are outweighed  by the benefits. Composer is an essential part of the workflow for modern WordPress development.

Nor are these issues unique to Composer. I should probably write a follow up on using Bower Installer to solve a similar problem with Bower and NPM.

Composer is a great tool, and I hope you will try it, and when you do, this will have helped you learn how to make it work properly with GIT.

 

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

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.