In 2007 I partnered with Darren Hoyt to release Mimbo Pro, one of the earliest premium WordPress themes. In 2012 Mimbo Pro was published on wordpress.com. Last week – on October 5th 2016 to be precise – my 20th theme was published on wordpress.com.
The theme is called Label, and it’s the theme I am currently running on this site.
As an aside – I was thinking about the fact that I have 20 themes running on wordpress.com – and I now wonder if I’m actually the most prolific themer on the platform? The internal theme team make many themes as well – but there’s a lot of people on the team, and I’m not sure there is anyone who has individually published as many themes as I have. Would be interesting to know from them?
Anyway; I’ve learnt a lot about running a theme business since Mimbo Pro was first published. Pro Theme Design is not the biggest theme shop around – but it’s currently a sustainable business that I run single handedly and it generates enough income for me to look after my family comfortably.
Below are some of the lessons I have learnt over the years from releasing 20 themes on wordpress.com.
Code Reviews are awesome
All of the themes I sell on Pro Theme Design have been through a wordpress.com code review. They review every line of code, and they test the theme in various situations. In every review they have found something to improve or fix that I have missed. No matter how hard I have worked to make the theme perfect – there’s only so much I can do, and a second set of eyes will always improve things.
Without exception I have learnt something new from every code review on my themes. If I ever stop selling themes on wordpress.com then I will continue soliciting code reviews from a third party (probably through ThemeReview.co). They’re worth every penny.
I have automated my development process using Gulp to build and deploy themes (I am going to write a series of blog posts on how I do this).
I have a global SASS library that includes a series of boilerplate styles that I then reuse in all my projects. If I find a generic css bug I can update the library and all my themes update.
I use IFTTT to email me when there’s a new forum post on the wordpress.com premium theme support forum.
I use Gulp to generate rtl.css, bundle zip files, deploy demo site updates, and submit theme updates. This alone saves me hours a month.
I use Google Alerts to email me when one of my themes is mentioned on the wordpress.org support forums.
I use Buffer to schedule social media updates.
I use Automatic post scheduler to schedule blog posts.
Anything I can do that will save me some time and effort gets automated. Even if each task only saves me ten minutes – that’s ten minutes more I can spend with my family or on other things that I enjoy doing more.
You get what you pay for
I host my website and my themes site with Liquidweb. They’re not the cheapest. In fact I keep thinking about moving to DigitalOcean, but I don’t want to have to learn to manage a server myself – and I like that I can call on the Liquidweb support team to help when I break things.
I do my accounts and taxes with Freeagent. It costs me money each month but it’s so much easier than having to keep everything in a spreadsheet and hunt for receipts at the end of the year.
Bootstrapping a business is good, do everything as cheaply as you can, but remember time is money too. Sure, you can use Gimp to edit your photos, but if you’d be quicker using something else then spending $30 to gain a couple of hours a month is probably worthwhile.
The way I work out whether it’s spending worth money is to take my hourly rate (I don’t do freelance work, but I have a value I use for this sort of thing) and then work out how many hours I would save each month. If my rate is $200 an hour, and I am going to save 5 hours a month by spending $20 a month on some app, then that means I am freeing up 5 hours (= $1000) a month of time that I can spend elsewhere on things that would benefit me in some other way.
Sleep on it
Sleep on it when a customer is rude. Leave it a while – and you will be able to be more objective and reply politely rather than in haste/ frustration.
Sleep on it when a design isn’t quite working. A brain reboot often helps you to see problems you couldn’t see before.
Sleep on it when you have a late night code problem. You’ll be amazed how quickly you solve code issues when you’re not tired.
Going for a walk can also work.
Get comfortable saying no
I get a lot of support from people asking how to do X, or if I can add Y. Sometimes these are good ideas, and I add them. In fact there’s been a few times I’ve updated all my themes based on a suggestion for one theme!
Other times they are ideas that will only benefit a single person, or they are features that simply are not possible (or not within the scope of a theme). In these situations there’s nothing wrong with saying no, and you have to accept this.
If the theme is on wordpress.com then often it’s a hard no since there’s no other solution – but where possible I will point users to another feature (or plugin for self hosted users) that may help them out.
Support all the features
Support everything WordPress (dot com) has to offer. A couple of times I have neglected to include features like custom backgrounds, or custom headers in my themes, because I felt users might abuse them – and then in the code review I was asked to add them.
After I did this a couple of times I realised the wordpress.com theme team were right. The customers have purchased a theme from me. If they want to use a funny colour for the background, or upload a massive header image, then that’s their right, it’s their website after all.
These days I support as many of the default WordPress features (and many of Jetpacks features) as I can. Most of the wordpress.com custom functionality is in Jetpack so I can develop and test features locally – and my self hosted customers can get the same benefits by installing the Jetpack plugin.
Follow standards and best practices
When I started making premium themes in 2007 there weren’t many standards or best practices but since then a lot has fallen into place and by following best practices I can make products that are a lot more robust. So what standards do I use?
- I use the Customizer for all theme settings – and I keep settings to a minimum.
- I always use WordPress core functions – even if they don’t work exactly as I’d like. Using core features means they will be improved without me doing anything, and means my themes will work with plugins that hook into core functionality.
- I use the WordPress Coding Standards in Atom Editor so that I can make sure my code meets the WordPress recommended standards.
- I use consistent naming conventions for menus, sidebars, and templates so that when users switch between themes their settings will continue to work. This is particularly important on wordpress.com where many themes follow the same conventions. You can read about the standards on the wordpress.com theme user experience page.
- I try to follow the PHPDoc rules for documenting my themes. Every theme I make has better documentation than the ones before.
You can do a lot of Support with CSS
WordPress.com does not support plugins (unless you’re paying for VIP), so the only real customisation option you have is custom css. And over the years I’ve realised that 99% of the problems and feature requests can be fixed with a
display: none;, or a
Another handy tip is using the
content property. It’s a super simple way to change text on a site when you aren’t able to edit the underlying html.
Next 20 Themes?
What will I learn making the next 20 themes? I don’t know. It’s been a busy few years, but I’m sure there’s still loads to learn!