A brief look at hey.com stack

Two weeks ago, Basecamp launched its own e-mail service that aims to challenge the main online e-mail platforms, called Hey (and which resides in the attractive e-mail hey.com). The launch was announced on June 15, in a tweet by the company's CEO and co-founder, Jason Fried:

Jason Fried

@jasonfried

Two years of work comes alive today. Couldn’t be more proud of our team. It wasn’t easy, but it was incredibly fun. And today we get to show the world what we’ve been working on. Email’s new heyday is here. HEY: hey.com

14:15 PM - 15 Jun 2020

323 2777

The platform, which was initially made available through invitations, generated excitement in technology enthusiasts, for bringing a different approach to the so common e-mail service: right after logging in, we came across the "Imbox" (with M, of IMportant ), an inbox that only shows pre-authorized e-mails, a separate place for newsletters and even a "paper-trail" where receipts and order confirmations will be stored.

An interesting point to be noted by technologists: hey.com is far from being an MVP as we have seen in other startups. The tool was developed for two years until its launch, and its initial version already offers advanced tools such as the ability to merge email threads, notifications for specific contacts, etc. In addition, the service is not free: it offers a 14-day trial version, after which an yearly fee of \$99 is charged.

However, the point that intrigued me most during the week was trying to understand the stack and infrastructure behind hey.com. Because it was launched by Basecamp, known for its software quality and agile development practices, there was certainly something interesting there.

In a response inside Jason Fried's thread, CTO David Hainemeier made a joke about hype technologies, making it obvious that hey.com uses a simple stack, and obviously with Ruby on Rails (which was created by David in 2004):

DHH

@dhh

@Leefrog2 @jasonfried Went with a serverless, microservices architecture on the backend based on Go, Rust, and Flubber, paired with a nanoservices frontend, mixing react, redux, vuejs, and actually angular together for a best in breed combination ✌️

19:47 PM - 06 Feb 2020

91 1162

Unfortunately, hey.com is not open source, so I had to do a little research to get a better idea of the technologies used.

Important disclosure: as the hey.com code is not open source, and no official announcements have been made, the statements I make here are all based on information from social networks and superficial analysis I made looking at the platform's html.

Web application

As we could imagine, hey.com is a Ruby on Rails web application rendered on the server, without using any front-end frameworks on the client side (like React, Vue). When inspecting the code, we can easily note the use of turbolinks, a library for displaying page blocks without the need to reload all the HTML, and which provides a very quick and smooth navigation:

I'm not going to dive into the hey.com Ruby on Rails application here very much, but if you're interested, Matouš Borák wrote a very in-depth article here.

Infrastructure

Regarding the application's infrastructure, David Hainemeier explained that they chose Kubernetes to orchestrate the application's containers. Asked about the real need for the tool, DHH argued that for tools like Hey, where it is not known whether 10 or 1 million users will register on the platform, an orchestrator like Kubernetes is extremely necessary:

DHH

@dhh

@wycats @joshpuetz @Leefrog2 @jasonfried Because the cloud is actually a great place to run a product where you have no idea whether 10 people and a dustbowl shows up or if half a million people suddenly wants in. Uncertain scale = great fit. (And K8S is a great way to run cloud).

21:12 PM - 08 Feb 2020

1 40

Still on infrastructure, Blake Stoddard, Senior System Administrator at Basecamp, wrote in this article of April 20, 2020, that to manage its clusters, the team uses Amazon EKS to automate Kubernetes execution.

Development workflow

Inspired by GitHub's branch-lab system, the hey.com development team uses a system that immediately deploys any branch at a specific endpoint for that branch and that will be immediately available to test the changes made.

As soon as new branches as new features are created, continuous integration through the BuildKite tool is started and a new environment is provisioned in a few seconds.

Full details of the hey.com team's development flow can be found in this Blake Stoddard article, Senior System Administrator at Basecamp.

Bonus insight: the hey.com domain

In this article, CEO Jason Fried explains how he managed to buy the hey.com domain. Despite not exposing the final offer, it shows how, after 18 months and more than 60 emails exchanged, the negotiation took place. Also, how difficult it is to get a good domain today.

Would you risk making a guess about the final offer?

I hope this article has given you some inspiration on how to create a modern and scalable product like hey.com!