How we gave SSL to all our customers in 5 days, for free

 I regularly talk about the HubSpot Product Team's culture – both internally and externally – and I always start my discussions on our culture with the following idea:

It’s hard work. There’s a lot that can go wrong. But every so often, all of the right ingredients come together and magic really does happen. And being able to witness this and see a team operating at a totally different level is, well, magical.

Recently, I got to watch one of these magical moments.

An Impossible Task

Google has long made it clear that they give preference to sites that are SSL-activated. For example, a while ago they changed their ranking algorithm to give an extra boost to secure sites. And furthermore, we started to hear some rumblings that they’d be raising the bar yet again inside of Chrome by warning users who are filling out forms on sites that aren't SSL-activated that their data might not be secure.

There are a few reasons why these changes are a Very Big Deal to HubSpot and our customers:

1. Google is still king when it comes to our customers’ sites getting found on the internet. Therefore, any way we can help them rise to the top of the search rankings is at the top of our priority list.
2. A fundamental part of HubSpot's Inbound Methodology involves using forms to capture information about leads who want to engage with you.
3. We host over 70,000 customer domains on our platform. For every one of those sites, it's incumbent on us to provide the best experience for our customers and for their customers.

With this in mind, we’ve been tirelessly working to make it easier and easier for our customers to get SSL when they host their content on our platform. For a long time, this was done manually, and only when customers requested it. Then, we spent a huge amount of time automating as much of this process as we could. And while this automation was great, the process to turn on SSL on your domain was still rather cumbersome and slow.

Our long term goal was to provide SSL to everyone, automatically, for free. But we just didn't have the systems in place to make that happen yet.

Then, in September, we learned from our contacts at Google that Chrome 62 – the release that would start flagging forms on non-SSL pages with scary warnings – would be going live by the end of October. Which means that in October, any of our customers whose sites weren’t SSL-activated would have that scary warning on their site.

Image source: Google Security Blog

Crap!

Our support team was concerned that once this release hit, customers would rush to turn on SSL for their sites. We knew that our current SSL setup process was pretty glitchy, and it would likely cause a flood of calls to support. It wasn’t out of the question that 10,000 calls could hit our support team (and while they’re amazing, even they have limits on what they can do), and we were trying to figure out how we'd deal with that kind of load.

It wasn’t too long before we got some even worse news. The Chrome release wasn't going to drop at the end of October. It was going to drop in mid-October.

So the team that builds our CMS got together. And they asked themselves, "What if there's another option? What if we could automatically provision SSL for 100% of our customers? And what if we could do this BEFORE the Chrome release goes live?"

Those were some pretty big what-ifs. It was an insanely audacious plan. It would require tons of work across a bunch of different teams. But that's exactly what they set out to do.

And over the course of a five day period, they did it. They provisioned SSL for nearly 47,000 domains that didn't have it before.

To put this in context with a very Boston reference, in the previous years that we'd been working on this, we'd provisioned 12,000 domains with SSL. That's fewer than the number of seats in TD Garden. Then, over the period of five days, we turned on SSL for more sites than there are seats in Fenway Park. And today, we have more domains on SSL than there are seats in Gillette Stadium. Go Pats!

And they got all of this done before the Chrome 62 changes went into effect, which means that all of our customers who host content on our CMS don't have to worry about that scary warning. And we did it automatically, without those customers having to take any action. And we did it for free, because it was the right thing to do.

Was there a secret to the team pulling off this amazing feat of engineering? Hardly - they just had all the right ingredients in place. The team had a compelling mission. They had the autonomy to attack the mission the way they saw fit. For instance, they had the freedom to deploy new technologies, including new APIs we hadn't had access to before and AWS Lambda - these were the key to being able to make this change so quickly. And they had massive support. Teams from around HubSpot rallied around our product teams to make the process as seamless as possible. Folks from our infrastructure team helped with configuring DNS and networking. Our product marketing department did an amazing job educating customers on what SSL is and how the upcoming change would affect them. Our pricing and packaging team moved mountains to make this feature free to our users, knowing that it was the best way to protect them given the impending Chrome release.  And our support team encouraged the team to move quickly and take risks, even though they knew it might cause some extra support load, because they knew that the payoff was worth it.

This is a classic example of our philosophy in action. When mission, autonomy, and support combine, the result won’t just be remarkable. It will be magical.