Other posts in this series
Yes, you read that title right: WordPress as a SaaS (Software As A Service) application platform. But wait… WordPress is a blogging platform right – what’s this about building applications? Well, as it turns out, you can do a whole lot more with WordPress than you may think. Using the power of WordPress and the community around it, we built Hello Bar in about 1 month, monetized it, scaled it and eventually sold it. This is the first article in a series where we’ll be exploring how we used community plugins (as well as our own), custom theming, a good server setup and a little automation to build a full subscription based application using WordPress.
The Plugin Community is Your Friend
One of the most powerful things about WordPress is the community around it. Some very talented developers have created thousands of plugins that elevate and expand this little CMS platform lightyears beyond just being a blog. This availability of quality, pre-built plugins and the fact that we were already very familiar with the capabilities of the platform itself were some of the primary reasons we chose to build Hello Bar using WordPress. We wanted to get something built with minimal effort, time and cost, but still have a great product in the end. Functionality provided by community plugins enabled us to focus on building our application and create a compelling product.
Managing Your Users
As with any SaaS application, the first thing we needed was a way to manage our users. WordPress’ built-in user system coupled with a good membership plugin saved us a lot of setup time and provided us with nearly all the functionality we needed with little effort. We evaluated quite a few plugins out there including WPMU Membership, WishList Member, WP E-Commerce Membership and s2Member amongst others. In the end we determined that s2Member was the right combination of features and price to get a low cost application started.
With s2Member installed, we had a turn-key solution to subscription management, payment processing, brute force login security, as well as diverse page access restrictions for multiple user tiers and capabilities. s2Member is a fremium plugin with a very capable free offering and a paid Premium plugin to complement its features. Even with the free version of the plugin we were able to get all of the previously mentioned capabilities as well as integrate a free PayPal account and accept payment subscriptions. s2Member also provided a highly hooked architecture via WordPress’ powerful action and filter based Plugin API, allowing us to execute our own actions on significant events like account tier upgrades and cancellations.
Securing Your Site
WordPress is the perfect system for a publicly accessible website, but it requires a little customization to lock it down for use as an application platform. Knowing this, Automattic set WordPress up in a way that all of these customizations (most of which are free) are readily available in the plugin community. s2Member provided us some brute force login protection as well as the ability to lock down access to certain pages and URLs so only logged in, registered users could view them. VaultPress by Automattic, while not free, provided us an inexpensive way to keep our WordPress application secure and backed up. A few dollars a month for real time backups of our database, theme, and plugins as well as plugin and theme scanning for malicious code was well worth it.
Custom Plugins and Themes to Build an Application Experience
While community plugins got us up and running quickly with a platform base, we eventually needed to start writing our own code to customize our application’s experience. WordPress’ powerful APIs for building plugins, shortcodes, themes, and widgets, it’s highly configurable and flexible code, and its database architectures all gave us a powerful set of tools to accomplish what we set out to do.
Managing all the Data
We created a custom plugin for management of all the Hello Bars that a user would create. This plugin took advantage of WordPress’ custom post type system to store Hello Bar data. This provided us with the ability to use many of WordPress’ built in functionalities for the CRUD (Create, Read, Update, Delete) actions surrounding the data. By using custom post types as the storage method for Hello Bars, we could:
- Easily update the data with wp_update_post()
- Store and read configuration options with update_post_meta() and get_post_meta()
- Read Hello Bar data with the WP_Query Class
- Provide interface URLs for users to edit their Hello Bars with the custom post type’s public page
- Allow users to enable, disable or non-destructively delete Hello Bars just by changing the post entry’s published status.
Customizing the Onboarding Experience
To keep our application running smoothly as we got things started, we created a custom plugin that would require users to be manually approved before they could access the website. This plugin also enabled users to enter unique beta keys either at registration or post registration to activate their accounts. We utilized WordPress’ action and filter API system to hook into the user login and registration processes to enact our own status policies and authentication policies in addition to WordPress’ giving us finer control over who and how many people could access the system.
We later expanded on the capabilities of this plugin by adding a viral sharing component to it through a secondary plugin. This secondary plugin hooked in via actions and filters into the initial Beta Key plugin and allowed approved users to share beta keys with their friends. This grew Hello Bar’s popularity significantly and created a lot of buzz around it, driving the community’s desire to get into our exclusive application.
Besides the Beta Key plugin and its viral sharing add-on, being a design company, we also wanted to have a little more granular control over how the registration and login process looked. While s2Member did provide some basic login and registration page customization capabilities, we wanted to go a little further. To accomplish this we created a simple plugin that allowed us to easily specify and load custom stylesheets for the different states of the login page as well as provide custom re-write rules to make for some URLs a little prettier than /wp-login.php?action=login. By the time we were done, you’d never have guessed it was a WordPress login page.
Customizing the Application Experience
We love WordPress, but this was an application, not a blog or website, so we need to customize the experience to reflect that. To start, we didn’t want users to even realize it was WordPress they were using, nor did we want to expose any administration interfaces that would take them out of the application’s simple and streamlined experience. To do this, we started by locking down access to /wp-admin. s2Member provides this functionality out of the box, so it was a pretty easy goal to accomplish. In addition to locking things down, we customized some of the URL paths by redefining a few constants to obfuscate that we were using WordPress. This allowed us to change where any files were uploaded, where our plugins existed, and where the contents of /wp-content lived. Of course, some plugins didn’t like that we weren’t using standard WordPress paths, so we needed to modify some files manually to make the file paths matched our configuration. Keep this in mind if you decide to change file paths with your application; it makes things a little hard for bots to find, but it might make some plugins a little more difficult to integrate.
Once we had our WordPress environment customized to our liking, it was time to create the application interface itself. We created a few Page entries and utilized the public pages for Hello Bar’s custom post type entries for editing interfaces. This allowed us to easily lock down access to those areas using s2Member’s access restriction system. Of course, since s2Member only provides account tier level access restriction, we still needed to write our own author level restriction for access to individual Hello Bars and their related pages, but everything else just used the currently logged in user’s information to determine the correct data to display.
To output interaction areas for users, we took heavy advantage of WordPress’ theme template engine and Shortcode API. We created page templates and custom styled both a logged in and public experience within a single theme thanks to the Multi Header capability of get_header() and Multi Footer capability of get_footer(). For self user management, s2Member provides numerous shortcodes for users to update profile data, cancel their paid subscriptions, sign up for a new paid subscription, or upgrade an existing paid subscription. We liked this model of portable markup deployment and followed it with our own core plugin to provide shortcodes for Hello Bar interfaces. We used some custom page templates to provide the “wrapper” around the interfaces and then outputted the Hello Bar management table, editing interface, and eventually the statistics summary table and chart detail using shortcode deployment.
Conclusion
So, as you can see, WordPress provides lots of great tools and turn-key offerings to get your SaaS application up and running in no time. Using its powerful API system, plugin architecture and community created plugins you can build an application and start making money in no time. Next article I’ll talk about how we setup our server(s) to handle the service of our application to our users.
Got any questions about how we used WordPress to build Hello Bar or how we got over any hurdles I may not have addressed? Post a comment and I’ll answer you as best I can.
Chuck Longanecker
Thanks for spelling out all the details Dave. Here’s a post of Dave and I telling the whole story at WordCamp SF a few weeks ago: http://wordpress.tv/2012/08/21/chuck-longanecker-how-we-built-and-grew-the-hello-bar-web-application-using-wordpress/
Jamie Hamel-Smith
Awesome post Dave. Multiple headers and footers were fun
Jordan
I’ve been weighing the pros and cons of using WordPress instead of CodeIgniter for an app I’ll soon be working on. Do you consider WP just a shortcut, or a legitimate long term solution?
Dave Shepard
Hey Jordan, I honestly don’t have a lot of experience with CodeIgniter specifically, but we have done a lot of work with CakePHP, a similar competing MVC framework to CodeIgniter. In the end its all just PHP and MySQL with various caching technologies for speed. How you write your own code, how you organize things and handle memory usage in either platform will be the primary factor in determining speed. Both platforms will scale quite easily and can take advantage of a lot of the same technologies for doing so (database sharding with WP Network installations, replicated databases, Memcached servers for object, database and output caching, etc.). WordPress certainly scales (see WordPress.com and its millions of sites hosted there), but I don’t know if that paradigm matches your application’s experience.
We built Hello Bar using WordPress initially as a launch platform. We honestly didn’t know if WordPress would be able to handle what we were trying to throw at it, but it turned out pretty well. There are some different decisions I would have made about how we architected it looking back on it now that would have allowed it to scale a little easier (such as taking advantage of WordPress’ Network installation capabilities), but with the right setup I have no doubt it could scale enough to function as a long term solution.
Rilwis
Thanks for your shared thoughts. People (including me) are looking at a good way to scale WordPress. In the WP hacker list, developers also discussed some techniques and shared on http://scalingwp.wordpress.com/. But anyway, the realistic is the key, that’s why I really like your comment!
Cristian
There is a lot of application overhead in WordPress. For example you’ll need around 40MB of memory just to serve a page in WordPress. However, this is only valid for dynamic content. Even with a SASS, most of the content will be cached and there’s Memcache for object caching.
That being said, I’ve been building plugins to bring backend functionality in the front end for some time and I’m still amazed on what people are using them for.
Wordpress website design
The above details about wordpress plugins and website design details are very useful for who are learning wordpress.
Patrick Rauland
Awesome article. I think if I made a similar SaaS product that I wouldn’t worry too much about hiding things like where the files uploaded – it just seems like more work.
About how long do you think this took you?
Jamie Hamel-Smith
It’s an interesting argument indeed. Security via obscurity definitely has its advantages such as, avoiding crawlers and automated zombies prodding at your WordPress installation, but if a human is behind any mal-intent, your security better not stop at “changing a few paths here and there”. So yes, it’s more work, but it’s not really designed to fool humans.
The amount of time it takes to change these paths initially is not that much, however it can cause problems if you use other plugins that depend on the paths. I seem to remember Dave running into a couple issues like that. (He’s out on vacation, so I’m filling in on these responses so we don’t leave you hanging)
matt
I’d be interested to know more about how you handle the user-hellobar relationship. I run the tech side of things for a membership site built on WordPress, and we’re looking at adding some features that make it more app-like. For instance, we’d like a member to be able to take notes or fill out some custom fields when reading through one of our posts (it’s an educational site). My first idea was to use a custom post type like you did, but I haven’t yet figured out an easy way to associate the custom post with the user who filled it out.
Great insights, and awesome case study of how to extend WordPress in a unique way.
Jamie Hamel-Smith
Hey Matt,
I’m glad you like the post! I’ll fill in for Dave and try to answer this one as best as I can. Adding custom post types for users (in Hello Bar’s case) was largely a manual process. WordPress is after all “a Publishing Platform” with little emphasis on things like restricting a group of posts to a group of users (or one user). Plugins like s2Member help a lot with this, but it’s still not a full solution.
For Hello Bar, each bar is a custom post. Each custom post is then owned (the
post_authorfield) by a user (associated by theiruser_IDwhen creating the post). Before a user is allowed to do any CRUD operations on a Hello Bar custom post, a thorough check of the logged in user, and subsequently the post owner is done. If the logged in user shouldn’t be messing with the post in question, they are redirected and shown a message. The checking functions are mostly manual, and the custom post structure is used to keep things organized and aligned with the WordPress data structure.You’ve just hit on one of the trickiest parts of using WordPress as a SASS platform. Best of luck to you in your custom-post ventures moving forward.
Richard
Nice read. I’m curious about performance – how well did WP perform at serving up the JS, and did you run into speed bumps as more customers signed up?
Where you using any caching of the JS code, or was each request hitting the DB?
Jamie Hamel-Smith
Hi Richard,
The performance of serving bars was great since we were offloading a lot of that work. When a bar was saved, it was baked to a flat JavaScript file and subsequently served via Nginx. RSS bars were updated every 5 minutes (or so) using file age detection. We only asked PHP and WordPress’ database for a new file if the cached file’s age was old enough. So basically, we didn’t even touch PHP unless we absolutely had to.
One memorable speed bump as customers signed up was CSS Mania. When they signed up, we noticed some slowness followed by intermittent failures. After analyzing the traffic that was hammering us, we discovered that CSS Mania had put a RSS bar on their home page that was showing the latest post from their blog. This was the evening when we (Dave mostly) added the time based caching of RSS feed bars. That way, even a site with traffic like CSS Mania would only hit PHP at most once every 5 minutes. The rest was up to Nginx and it handled the load easily. Necessity is the mother of invention.
Brent Shepherd
You’ve nailed it with your topic, but the Hello Bar case study barely scratches the surface of the potential and current usage of WordPress as a SaaS App Engine.
We’re already starting to see great SaaS sites customising WordPress into niche specific web applications, like Happy Tables with their social restaurant features, and the soon to be launched OpenBnB with it’s full booking management system (disclosure, I’m helping with that one). And we can expect to see many more in the future.
Matt Mullenweg featured a heap of other great applications built on WordPress in this year’s State of the Word (jump to around 35 mins in).
First there was WordPress for blogs. Then WordPress as a CMS. Now we have WordPress the App Engine – the most exciting times for WP are yet to come.
Chuck Longanecker
Hey Brent,
Thanks for sharing Happy Tables and OpenBnB. They look very promising.
I’d love to see some more examples of apps on WP that are scaling efficiently. Our road to 1,000,000,000+ Hello Bars served was quite an adventure. We certainly encourage the use of WP as an app engine, but we also need our peers to keep pushing the envelope so that scaling usage is a bit more predictable from the get-go.
jared
As crazy as it might sound, I’ve talked with clients whose whole entire system has been built with WordPress and I’m not talking mom and pop shops but some pretty big sized companies.
Angelo D’Ambrosio
We are building a database and service site for my association, and among the data we would like to store our members info. We are talking about 7000+ people, and since the subscription is yearly we also want to save a stripped down version of these data for historical memory. We are using WP to build it and at the beginning I was afraid about the scalability of the process, but the comments here make me believe this could be achievable!
Pingback: How WordPress is So Much More Than Just a Blogging Platform - ManageWP
Lew Ayotte
I love WordPress! I started coding for it years ago and eventually created my own SaaS solution for a premium WP plugin, leenk.me… the site is also using s2member, which I would recommend over all other user management plugins, for one reason alone. It was the only plugin available at the time that actually used the built-in WordPress usertable. This is an extremely important feature to me! And since then s2member has only grown and the feature set keeps improving.
Great write-up! Thanks for sharing.
Panchoxx
In viewing the dirfnfeeces between the way this plugin differs from the wordbooker plugin, I think I like the wordbooker better even though it has tons of settings that I don’t completely understand. This plugin has inserted a url for my post image which I don’t like. It also includes my wp user profile pic instead of my post pic which I don’t like. What I do like about it is it is more user friendly with only one check box to turn it on. It also lists my website url and related posts which is good.
Pingback: WordPress as a SaaS Application Part II… Speed and Scalability?!
migaber
Thank you for sharing the experience, creating SaaS based on WP is crazy idea but I’m sure that WP is strong enough to do that, Thank you and I’ll cont. reading the series
Pisos en Barcelona
Stunning story there. What happened after? Good luck!
Dave Shepard
Hey Pisos, thanks! Like mentioned in the article, we actually sold the application (http://techcrunch.com/2012/08/04/crazy-egg-acquires-hello-bar/). Not our original exit strategy, but it was a great move for both our customers and us as a company.
Pete
Great post guys…. I’m in the middle of testing custom post types, templates etc in WordPress, I literally have notepad++ open now and came across a small problem on the single post template. If two users happened to name posts exactly the same. The permalink for one may end in -2 or whatever the format is that WordPress assigns. I noticed in hellobar the URL’s end with a number `my-hello-bar-XXXXX`. I thought this might be the ID of the post but realized to post then get an ID and add it to the post doesn’t sound efficient. I know the userID is accessible with WP functions, but what other unique ID can I use to append to the post name before the form is sent which would also be unique to each post?
imeall.com
A guide to using WordPress to build SaaS Web Apps like Hello Bar, appears
to be a good title to give this article. Where exactly could
I learn even more regarding this?
dtelepathy
The WPMU blog (http://wpmu.org/) is an indispensable resource for all kinds of great WordPress tips & tricks! =)
Lucas E. Wall
This is a well documented in depth and clarity article. Thanks for putting it together! I found it looking for exactly how to make WordPress and a SaaS work together. Is it possible to add charts and maps as part of the restricted access area?