SaaS That App

If you sell on-premise software like we do, SaaS can be a daunting idea. Do you move your software to The Cloud? How? What should you do about your pricing? What technical changes are required? Is it worth the effort?

We recently made our app, HelpSpot Help Desk Software available on “The Cloud” and I wanted to talk about some of the decisions we’ve made both technically and on the business front. If you have an app already or if you’re thinking about building an application you’ll likely find this helpful.

Why move to SaaS?

Well, I won’t spend a lot of time here as you already know the answer. A lot of customers are asking you for it! Some reasonable chunk of your potential customer base wants to outsource the hosting and management of their software infrastructure.

There’s also some secondary reasons as well. If you run an on-premise application now, you know that supporting it is a bear. Figuring out technical issues with someone else’s server (or even worse their $5/month hosting) is burdensome.

There’s also the improvement to the sales process. With a SaaS version of your software you can get customers right into the product and using it. No trying to make sure they download it and get it installed, so it can be a big boost to your sales cycle.

Should we keep our on-premise version?

Of course! Regardless of how the SaaS version might make support a bit easier and the sales cycle a bit faster, having an on-premise version is a huge competitive advantage. There’s still a large market for on-premise applications, companies still have hundreds of billions of dollars dedicated to internal IT groups. But, best of all, NOBODY is building new on-premise apps in most markets.

If you’re a bootstrapper this is niche gold. Serve the groups that are underserved. Some companies like running their own software and many industries are required to do so or at least outsourcing it is cumbersome and expensive due to regulations.

Will this be the case forever? Who knows, but for the foreseeable future there’s enough on-premise business.

If you look carefully, you also see smart SaaS’s embracing on-premise. For example, GitHub has an on-prem version that they charge substantially more for than their SaaS offering.

So, if I run a SaaS should I convert it to on-premise?!

Maybe. This is really a topic for a separate post, but like I said very few new on-premise apps are being built. Everyone is trying to differentiate in SaaS, but there’s really only a few knobs you can turn. If you’re bootstrapped, you have even less knobs to turn since you probably can’t outspend competitors on design or advertising.

If you haven’t yet started building your app, I definitely think you want to give consideration to how you could make it self hosted in the future. At least leave that option open.

What that is generally going to mean is to not let your tech stack get out of line. Most SaaS apps are hardwired into too many server techs and even worse, too many other SaaS services. It’s practically impossible to uncouple those hard requirements on other SaaS services. So pick and choose very carefully and try and keep things as simple as possible. This is good advice even if you never go on-premise.

Technical considerations

In creating a SaaSish version of HelpSpot we had a number of technical challenges to deal with. I’m going to go into a bit of excruciating detail here, but try and stick with me non-tech folks. This stuff is important!

Shared hosting or dedicated servers?

One of the biggest considerations you’ll have is how exactly to host each customer. A traditional SaaS application will generally have all users accessing a shared cluster of servers. Depending on the structure of your application though, you may not be able to do that with your on-premise to SaaS app.

This is very specific to each app, so I’m going to focus on what we decided and why. When we looked at how HelpSpot was structured and also it’s features we had a few tough decisions. First off, one of the key advantages HelpSpot has is it allows for a lot of customization. More than any traditional SaaS app can provide since we allow access to the underlying PHP itself in several ways and provide API points that expect custom written PHP files (there’s also REST api’s, etc).

If we went with a traditional SaaS configuration we’d need to remove all those features as there’s not really a nice way to let any random person who signs up for your service to run their own PHP code when in a shared configuration like that.

One option we did consider and that would have been cheaper for us to do was to run a traditional PHP shared hosting setup. So a bunch of customers all on one server, but with some walls between them. This makes things a bit safer, but there’s still not a rock solid way to keep customers separate.

In the end, we decided it was worth the extra expense of giving each customer a dedicated virtual server. Prices have come down significantly on small servers and as most HelpSpot instances require a fair amount of database power (more on DB’s in a bit), but relatively little web server power it made sense.

Giving each customer their own server has some distinct advantages. First, we can still leave all our customization features in place. The customers are completely isolated to their own servers and so we can continue to give them the powerful template customizations and code access.

Next is probably my favorite feature, by isolating each customer we are able to isolate downtime to specific customers verse a shared stack that could be overloaded by a spike (or technical glitch) in one or a few customer installations. While there are still ways a larger chunk of customers could go offline together, isolated servers limits this to only a few places like the database, which is AWS RDS with auto-failover.

The flexibility this provides is also extremely useful. We can roll out updates to select customers or groups of customers. We can easily run beta builds for ourselves to test on production infrastructure and more. Yes, these can all be done in a more traditional SaaS setup as well, but it’s more complicated and costly to develop.

While it would seem like per-customer instances would be more costly than a traditional SaaS setup it really isn’t too much more. We use AWS t2.micro instances by default, only using a larger instance if required by the size of the customer.

When you use the zero up front, one year reserve pricing you save about 35%. So you end up spending $6/month. Yes, this is a lot if you charge $10/month for your service (don’t do that!), but considering all the upsides and given our average sale is significantly more than that the cost is minimal while providing us with maximum flexibility.

Costs are continuing to be driven down on VM’s so I expect within a year or two we’ll be able to get the per customer cost to under $3/month. In fact, AWS just released t2.nano which would let us get to around $3.25 today, though those servers are about half the size of the micro’s. For now, we’re sticking with the extra headroom the larger servers provide until we see how Nano’s perform with HelpSpot, but that may be a change we can make in the future for further savings.

Dedicated VM’s also offer a unique marketing advantage vs all our SaaS only competitors. We’re able to provide dedicated server resources and more direct isolation than any other competing systems. In the future we could also easily offer hosting in customer selectable physical locations. While this isn’t a factor for all customers, for certain types of customers this can be a compelling difference.

Single or Multi-tenant database?

Let’s talk a little bit about databases. Since HelpSpot was already on-premise it’s database was single tenant. Meaning, it expects only one customer per database instance. Most SaaS apps are built multi-tenant, meaning the database will have some kind of tenant id column to separate all the data between customers.

I’m not going to get too deep on this, but converting your single tenant database structure to multi-tenant is a very big and potentially error prone process. While you’re first instinct is to convert to multi-tenant you may want to give that a lot of thought.

We ended up not converting and keeping each customer in their own database. This has some distinct advantages.

You could literally put a database on each customers VM. Alternatively, you could run a central database server but as each customer has their own database instance you can more easily balance and distribute customer data (this is what we’ve done). In this setup it’s trivial to add more database servers, rebalance databases, put database servers in different physical locations, etc.

It’s also easier to offer premium services. For example, enterprise customers who want to pay a premium could have their own database server.

Database maintenance, management, and movement is easier in my opinion as you don’t end up with a giant terabyte database to manage. For sure, having many smaller ones can have it’s own issues as well, but keeping it centralized to one server broken up into individual database has worked well for us so far.

There’s also a security gain as no coding error alone would ever allow one HelpSpot customer access to another’s data. We couldn’t miss a tenant ID and accidentally expose data. We’d literally have to go on our customers server and update their database pointer variable to a different customers (along with the username and password). Not impossible at all, but much more unlikely than a single database query change slipping by that opens data up across all our customers at once.

Application level changes

For the most part, by putting customers on their own servers very few application level changes are needed. However, in our particular case there was one substantial change.

Traditionally HelpSpot has had only a web based installer/updater. So you’d download a new version, update the files, and then run a page in your browser to update the database and make other changes.

As we needed to be able to script the deployment of new HelpSpot instances to HelpSpot Cloud, having to run something via a browser (or curl) wouldn’t be optimal.

Instead, we created a new command line updater. The command line tool lets us run the new installation and upgrade processes via the command line for easy scripting. It’s also now a feature that customers can use to script deployments or simply to use the command line option if they prefer.

It’s also something we’ve needed to do for a long time to allow us to make larger changes to the database than you can otherwise safely do via a web browser based updater.

Updating back office systems

One thing you’ll want to plan a lot of time for if you take on a conversion to SaaS is updating back office systems. Our little online store has grown to a robust deployment management system responsible for customers, servers, deployments, and more.

You’ll need this centralized control and the ability to have an application that manages customers purchases with their status on the cloud infrastructure.

This is a lot of work! Most likely months of work by the time you figure out all the edge cases and iron out all the bugs so plan for this.

Pricing your SaaS vs On-Premise

I’ll have another post on pricing coming soon, but for now I’d recommend that when you go to SaaS you change your pricing to a subscription model (if you haven’t already). Customers expect to be paying by subscription at this point and they’ll find it confusing to compare your cost to other systems if you don’t.

When we first launched HelpSpot Cloud (actually still today, but changing next week!) we made Cloud an add-on on top of license costs. So we had license costs, support costs, and then cloud hosting costs.

This is confusing to understand and a lot of work to explain. Simply saying it’s $25/user/month is what customers expect to hear and prevents them from getting distracted and frustrated with the pricing.

Another upside is you’ll likely be able to charge more than you’re currently charging now for one off licensing plus hosting as a separate fee. At least when you do the numbers over a few year period.

Support considerations

There’s actually a lot of things I don’t like about running a SaaS service 🙂 but not on that list is support. If you’ve been doing on-premise support you know the pain of dealing with cheap hosts, fixing customers broken servers, and diagnosing IIS issues.

SaaS changes all of that, essentially eliminating all your worst support in one swoop. Freeing up time for support staff to do other more useful endeavors such as providing live training, improving your documentation, taking more time with each customer contact they do get.

This is also a large reason why with our upcoming pricing change we’ll be pricing HelpSpot Cloud and HelpSpot On-Premise exactly the same. While cloud does cost us more to run, it’s far less costly to support.

Results for us

So was all this work worth it? Well, I’ll have to follow up in a future post to be more definitive but so far it seems like a smart move.

In the first few months we’ve offered HelpSpot Cloud about 7% of all customers have moved to it. Considering we’ve been around for 10 years that’s a pretty solid number. Of course, we have new customers signing up for it and starting on the platform from day 1 as well.

That process has also become much smoother as previously we had a hosted trial system, but it wasn’t for production use. So potential customers could kick the tires but they couldn’t really use it for live data unless they downloaded a trial or signed up with a hosting company.

Now customers can instantly use HelpSpot in a production environment cutting decision time and reducing the amount of additional setup required on their part.

Of course, we still offer HelpSpot On-Premise and will continue to do so indefinitely. On-Premise is a fantastic niche, but for companies looking to get out of the running servers business (many of them these days), offering a SaaS option that you control and is integrated tightly with your sales flow is a big win.