Superhuman with Rahul Vohra

The most popular email client is Gmail, the web-based email client from Google. Gmail is dominant, but that dominance has come at a price, namely speed. Gmail caters to the lowest common denominator, serving a large ecosystem of use cases and plugins. This makes for a slow overall performance. Superhuman is an email client built for power users. Rahul Vohra is the founder of Superhuman and joins the show to talk about the design and engineering of an email client that is made to be fast. I want to mention that we're looking for writers and podcasters for Software Engineering Daily. If you're interested in either of those things, email erika@softwareengineeringdaily.com. We'd love to have your applications for writing and podcasting. All right. Rahul, welcome to the show.

Great. Well, thank you for having me.

First question, very simple. Why are email clients slow?

Email clients are slow because no one hitherto, I believe, has tried to make them super fast. It is in fact possible, but it requires a tremendous amount of work.

Elaborate.

Well, the main reason that no one has tried to make them fast is because those organizations who had email clients were busy doing other things. Take Gmail or take Outlook, for example, Google or Microsoft. Incumbents like these gigantic companies really struggle with speed for a number of key reasons. Number one, They have massive scale. These organizations are huge, tens, if not hundreds of thousands of people. Number 2, they have this insane entrenched architecture. The number of servers, for example, that powers Gmail would boggle the mind. And number 3, they have to serve massive scale. Gmail alone has 1.5 billion users who run on all kinds of different hardware all the way across the world. So that optimization problem is really, really tough, as well as the engineering problem, as well as the organizational agility problem. How do you solve those three things? I don't claim to have the answer. I think it might be impossibly hard, which is why startups are even a thing. Now, why is it actually hard to pull off even for a startup? Well, it's only just becoming possible for a startup to build a high-quality email client, high enough quality and amazing enough that people would genuinely choose to use it, and not just use it but pay $30 per month for it. Over Gmail. This has become possible due to things like decent APIs. The Gmail and the Outlook APIs are significantly better than IMAP or SMTP for anyone who's worked with those, or MAPI or ActiveSync before them, better distribution models, and it's just faster to grow a technology company these days. So it's just become possible for a scrappy little startup like Superhuman to build the fastest email experience in the world and actually have people prefer that. Over the incumbents.

How does slow email inhibit the quality of interaction?

It's a death by a thousand cuts. It's— well, let's actually do it by example. So when Paul Buchheit, who was the employee at Google who created Gmail, sat down to do so, he had a rule, the 100-millisecond rule. And this basically said that every interaction should take place in 100 milliseconds or less. Now, for anyone who's used Gmail in the last 10 years will know that it no longer really abides by that rule. Opening an email can take a second, searches can take many seconds. And so when you have this slowdown, it's not really about the physical cost of the time. If you add that up, it'll come to perhaps half an hour to an hour a day, maybe, depending on how much email you do. It's the effect it has on your mind. So there's this notion in human-computer interaction that's actually been very heavily researched that every time you change task or get interrupted, it takes your brain about 20 to, on average, 23 minutes to recover. So if you Alt+Tab, or if you go to Twitter, or if somebody taps you on your shoulder and you stop doing what you're doing and you start doing something else, even if it's for just 30 seconds, when you get back to your original task, your brain is still computing the old thing. And the most insidious thing is you don't even feel it. So when our email goes slow or when our software in general goes slow, you'll realize I'm an aficionado and an advocate for speed. You risk losing flow. You risk this cognitive overload, this distraction effect. And that's why it's so important to never have that. If you're a, you know, if you're a software engineer or you're a founder trying to build high-quality software, you want to squeeze everything down to the last few milliseconds. And we've now got to the point in Superhuman where every interaction takes place in not just 100 milliseconds, but less than 50 milliseconds. And it's to keep people focused, it's to keep people in flow. And I think it's one of the main reasons why people report saving many hours per week.

Is it in any way good for a client to be slow? I mean, we're not talking about a chat client here. Like, maybe, you know, email is good if it's slow because it's a pensive operation.

I think whilst you're writing your emails— well, I was about to agree with you, but even there I disagree. Imagine you were doing a pensive operation, but you tapped a key, and there was a delay between what you tapped and where it appeared on the screen. And Gmail and Chrome, especially if laden with browser extensions, can easily get to that state. We've probably all had the phenomenon of hearing ourselves talk, but delayed by perhaps 200 or 300 milliseconds. And we know how cognitively overloading that is. So I can't imagine any aspect, bar one, which I'll get to shortly, where slowness is actually a positive thing. 'cause I think it's very anti-user. Now the one case where slowness is a positive thing is potentially delaying in receiving and sending. I'm very much a believer in humanistic technology. I don't like, for example, how Slack is designed to engineer fear of missing out. The whole threads mechanism, the whole unread channels mechanism is designed to keep you coming back minute after minute, second after second. And I think in email we can actually start to solve this. So this idea of perhaps pausing your inbox so that your emails are delivered at 3 known times per day, and the symmetrical idea of pausing your outgoing email so that maybe your email gets delivered to other people in 3 batches a day, I think that's a really good example of slowness. But if what we're talking about is how fast does the software feel, then speaking actually as a prior game designer, And as a student of psychology and the areas around this, I would say absolutely, it has to feel fast.

Okay, let's talk about the elephant in the room. Why is Gmail slow?

I think it's the, the, the 3 reasons I articulated earlier. You've got a very large organization with hundreds, if not thousands of people working on Gmail. I doubt that if you were to get all of them into one room or even ask them individually and said, what is the number 1 priority for Gmail? Any one of them would say make it fast, or maybe a handful would, but that's now point-something percent out of the 1,000 people he spoke to. So there's this organizational agility issue. Secondly, you've got the architecture issue. Gmail is fundamentally a client-server web-based architecture. Superhuman, to my knowledge, is the first time anyone has ever built a JavaScript entirely email client. It looks like a web page. If you go to our webpage, we also have a native app, but it isn't actually. You actually end up hitting an Amazon S3 bucket, you download a JavaScript payload, and it's the first time anyone's built an email client entirely in JavaScript. And so we don't even get slowed down by the network. When you search in Gmail— and Google is excellent, by the way, at putting servers next to everyone, you're only ever 1 or 2 miles away from a Google server— it still doesn't matter. You're still limited by the speed of light and network traffic and hops and so forth. But when you search in Superhuman, you're only limited by the speed of your SSD, which, as you know, is frighteningly fast. And so there's this architectural issue that prevents Gmail from reaching the speed of what native clients can achieve. And we did a whole, whole bunch of work on figuring out how to download, store, and index your email within the browser, within Chrome itself, itself so that it's as fast, if not faster actually, than any native email app, as well as significantly faster than Gmail. And then the third thing is this heterogeneity of audience. Imagine if you were serving 1.5 billion people on everything from an underpowered machine from 20 years ago to a $5,000 iMac. How on earth do you make it fast for all of those people? I mean, it's next to impossible, the heterogeneity. Is through the roof. Whereas we've focused on a very specific subset of users, those people for whom email is work, work is email, they do 3 hours or more of email a day. For them, $30 per month to save hours per week is a no-brainer trade-off. They would take that deal every single time, and they tend all to be on reasonably high-end hardware, so we can actually optimize for that. We can take advantage of the fact that we know the user has potent hardware at their disposal.

And I think it's worth noting that there are all kinds of things you can do with that extra hardware. You can, you know, aggressively preload all kinds of emails. You can do lots of aggressive caching. You could do lots of aggressive prefetching. Can you tell me a little bit about that kind of aggression that you can put into an email client?

Absolutely. All of the above and more. So we do aggressively precache, pre-download the labels or the lists, if you will, that we think you're going to attend to. This is obviously going to include the inbox, it's going to include sent mail, it'll include other labels that you seem to be using, and we'll sync those lists quite far back into the distance. But having said that, we did want to avoid what we found to be one of the key sins committed by other native third-party email clients. So in the first year of Superhuman, I actually interviewed north of 1,000 potential customers on average 2 or 3 customers a day on what their email client pet peeves were. And for the Gmail users, I think this will come as no surprise, it was, "I don't love Gmail, it slows me down, it's clunky, I have to click continuously, it doesn't sync properly against mobile, it doesn't work properly offline, it seems to consume tremendous amounts of battery." And then for the people who use things like MailApp, Spark, or Airmail, or any kind of third-party native email app, it was actually, this thing doesn't seem to sync reliably. This thing seems to be unstable. This thing seems to be buggy. This thing seems to take my CPU and peg it at 100% plus constantly. And so, you know, this is one of the reasons why I'd always recommend any founder, like, talk to 1,000 people in that first year. It's going to be so valuable in terms of getting to product-market fit. And what we learned is that, Yes, you can aggressively pre-cache so many different things, but you should only do it insofar as the machine is capable of doing so. So we actually have two speeds of pre-caching. We have one speed if you're not connected to power, and we have another speed that's about 10 times as fast if you are. And so we're very respectful of the current state of your hardware so as not to drain it unnecessarily. Necessarily, which I think basically every other email client doesn't care. It's just like, cool, we're going to download everything. And then for the next 48 hours, your machine is overloaded and running hot. And if it wasn't connected to power, it would die pretty quickly.

Let's come back to Gmail. Gmail has this whole plugin ecosystem, which I mean, I wonder if the plugin ecosystem actually slows down Gmail. Obviously it does if you have a lot plugins installed, but I wonder if you don't have plugins installed, is there some kind of overhead that is just material that is inherent to this plugin ecosystem? Maybe you can tell me about some of the other causes of slowness in Gmail, perhaps the plugin ecosystem.

Indeed, the plugin ecosystem is a huge contributor to this, and it is in fact one for which I feel rather guilty. You see, my last company, Reportive, was the first Gmail plugin to scale to millions of users. And I'm guessing about half our audience will remember this, but for the half that doesn't, we showed you everything about your contacts right inside your inbox. When people emailed you, we showed you what they looked like, where they worked, their recent tweets, links to their social profiles. We grew rapidly, and 2 years later we were acquired by LinkedIn. And at LinkedIn, I ran all of our email integrations. Now, the thing is, we were the first Gmail browser extension to do that. And I remember in that first year when I started, I told people what I was going to do. Hey, I intend to build this app. It's going to be a venture-backed startup. It's going to be a fairly complicated app actually, and it's going to live inside Gmail. And my, you know, I grew up as a programmer and as a coder and my coding buddies would say to me, hey, so you're going to build this really complex multi-megabyte app and stick it inside somebody else's really complex multi-megabyte app that is constantly being A/B tested, changes every day, doesn't have CSS or DOM laid out sensibly to help you because it's all compiled, and there's no API, there's no plugin architecture, and that's going to be your business? You're insane. Everyone tried to talk me out of doing it. But I think what we showed is that you could actually build really compelling products that way. And since then you have things like Boomerang, Mixmax, Clearbit, Yesware, you name it, people have it. And each one of these is built without an API. There is no plugin architecture. It's only recently that Gmail actually has a sidebar architecture, but that has all of its own pros and cons. And most people actually still use browser extensions because it gives you so much more power. The problem though is that because there is no architecture, What do you do? Well, you end up doing window.setTimeout, you end up tracking every mouse move event, you end up doing things that, yes, they let you create a product that's powerful, but let's be real, like, this isn't how engineering should work. It's not going to be the most friendly thing to the user's hardware. And so yes, absolutely, this whole plugin ecosystem, this whole browser extension ecosystem for Gmail that we helped kickstart at Reportive slows down your Gmail experience. In fact, Gmail plus plugins inside of Chrome is the single biggest reason why your laptop runs out of battery. And I don't like that. I kind of feel a little bit guilty for that. It's not what I had intended when we built Reportive. And in many ways, Superhuman is a, it's kind of like a love letter to the industry, if you will. It's, well, what would happen if we just rebuilt this entire thing from scratch? What if instead of this disparate collection of apps and experiences, it was beautifully designed and as if it were meant to be together? And so that's when we imagined this email experience that's blazingly fast, where search is instantaneous, where every interaction is 100 milliseconds or less, where you never had to touch the mouse, where you could do everything from the keyboard, it just worked offline, and it had the best functionality from the best Gmail plugins built in natively and was still somehow subtle, minimal, and visually gorgeous. And so there was this direct transition from that to Superhuman.

Sorry, so are you saying that the plugin ecosystem from Gmail works inside of Superhuman?

No. So we're taking a very different philosophy. Let's, let's do this by analogy. You can take an ecosystem like Android. Android has Obviously Google, who work on the operating system, parts of the operating system itself, minus their apps, open source, so anyone can take it and make their own. There's any number of handset manufacturers from Samsung to HTC to Huawei. You have the Play Store, but you have other Android stores as well, a disparate array of indie developers. It's a very heterogeneous ecosystem. And as a result, the Android experience is somewhat lower quality and somewhat a little bit more out there and a bit more Wild West than the iOS ecosystem. Now, the iOS ecosystem and Apple in general is much more vertically integrated. If you think about why your iPhone or why your MacBook is so— it feels so designed, it's because the same company made the hardware as made the software. And indeed, there is a phenomenon that directly addresses this. This. You know, most software engineers will have read or come across Conway's Law— sorry, not Conway's Law, because most people don't know that. Most people know the mythical Man Month, obviously written by Fred Brooks. In that book, he mentioned Conway's Law, and Conway's Law states that every app or service grows to represent the structure of the organization that made it. And if you look at the Android experience, if you look at the Apple iPhone or MacBook experience, you can literally see the structures of their companies and the ecosystem behind them. And if we just glommed in Boomerang, or if we just glommed in Clearbits, we'd be no better than Gmail and those things. So what we instead decided to do is we took a page out of Apple's strategy and said, well, what if we vertically integrated this as far as we possibly could? What if we designed the whole thing? Well, then we could unlock a quality of user experience that nobody else could compete with. And so for the functionality that really matters, you know, we'll never claim to replicate all of Boomerang because that's just too much. But for the stuff that really matters, we've built it ourselves natively inside of Superhuman.

Before we get into Superhuman in more detail, while we're kicking around Gmail, are there any other design issues that you see within Gmail?

I mean, I could talk about that for hours. I think the biggest one, and I say this as having been a product manager at LinkedIn, I know what it's like to be in a large tech company. This is less of a design issue and more of a political issue. You see, the way that product managers tend to be rewarded in companies like these are by pushing the needle. Now, you don't push the needle usually by by building new things. You push the needle by, especially when a product has scale, by making something 1% better or 2% better. And yet not everyone can do that. So the growth organizations in these companies tend to be rather small. So what do the other PMs do? Well, they go out on their own and they sort of make new features, but those features tend to be starved of resources by comparison even to a startup. This is one of the most eye-opening things about moving from Reportive to LinkedIn, it felt like before LinkedIn, I had access to way more resource as a venture-backed company, even one that had only raised $1 million, compared to being at a $30 billion company. 'Cause in the $30 billion company, you're competing politically, not really based on merit a lot of the time, against everyone else who needs engineering resource or marketing resource or whatever it is. Whereas as a venture-backed company, It's literally just how much buzz can you make and how much money can you raise and how much revenue can you create from your users. So, there is this notion in a large company of just how difficult it is to get stuff done. I remember estimating at LinkedIn we moved approximately 6 times more slowly than when we did as an independent company, as reported being independent. I don't think that's unique to LinkedIn. OpenAI is a phenomenal company. I don't wanna sound like I'm dunking on them. I just think that's the tax you pay being a large organization. And I can only imagine Google is slower.

Okay, so now that we're talking about design, tell me some of the high-level design decisions you've made in building Superhuman.

So we are very aggressive about keyboard shortcuts. We have a strong belief that the keyboard is faster than the mouse for about 90% of tasks. 90% of the things that you need to do in your email. There are a few things where the mouse is faster than the keyboard, famously just selecting random points on the screen. Let's say you're playing a first-person shooter or you're doing Photoshop-type work, or you're just trying to create a selection. That is an example of something that's faster with the mouse, but by and large, the keyboard is significantly faster. And so in Superhuman, on any given screen, there are only 3 buttons. And that has been the case since the start of Superhuman, since 5 years ago. And I challenge folks listening to think of a product where that's been true. Think of a product where for 5 years, the designers have resisted adding a button, but have still nevertheless continued to add feature after feature to the product. We have, and the way that we have is that we have this paradigm that we've borrowed from the developer ecosystem called Superhuman Command, a.k.a. our command palette. If there's anything that you ever want to do, just hit Command+K and up will appear Superhuman Command and simply just type in the thing that you're trying to do. Not only will it match it for you and you can even make a spelling mistake. We have a really cool fuzzy matcher. It will show you the direct shortcut to do it next time. And this is one of the key innovations that allows us to add arbitrary amounts of functionality. And Superhuman now is such a powerful tool without ever encroaching on the beautiful, minimal, premium design that the user interface has. So that's one example. Another example would be single-tasking by default. You've got, you've got me on a mini rant here, so bear with me. Let's say you're in Gmail and you hit C, because obviously you're using keyboard shortcuts and you get that little window to start typing. Well, guess what? You're still looking at your inbox. An email is still going to arrive. The next shiny thing will still distract you. And this goes back, Geoff, to the notion of disruption of flow, that 23-minute recovery time that happens in Gmail to Gmail users hundreds of times a day, leaving people in a permanent state of distraction. And Superhuman you single-task. When you hit C, you are looking at a blank canvas that occupies the entire screen. We've rebuilt Reportive over on the right-hand side, that's purely contextual information. There is no way that a new email can come in and distract you. There is no way that you can break focus or lose flow. Now, if you want to multitask, you can, and of course there's a keyboard shortcut for that, but the important thing is single-tasking by default. Default. So those are two examples. I'll pause there. But these are examples of how we create flow and help users move through their inbox twice as fast.

What are some other ways that you've built in performance advantages?

Performance advantages. So I think the biggest one is we figured out how to download, store, and index all of your email in the browser itself. So if I do a search in Superhuman, it's actually a hybrid search. It searches locally, natively on your device at the same time as via the CDN on Gmail. And then it merges those things in real time, which, by the way, is not an easy engineering problem. It turns out to be quite tough, but we solved it. It took us about a year or two to figure out how to do that, and now it works really beautifully. So I search searches feel really, really snappy, really instantaneous. That was one thing. Another thing is making every single interaction optimistic. Let me give you an example. In Gmail, you hit send and the UI actually blocks on sending. Now, about half the time you don't notice it, 'cause about half the time you're gonna be on a fast internet connection. But for anyone who's used Gmail whilst tethered, perhaps in a plane, back when we were all flying around, or in just some other low bandwidth connection, you'll know that when you hit send, it can block up your UI for in the region of 5 to 10 seconds or longer, depending on the quality of your connection. That to me is insane. Every single interaction in Superhuman, whether it's archiving, starring, sending, it really doesn't matter, every single one is optimistic. It doesn't block on the network. The only thing it can do can possibly block on his disk, and we're riding the trends that everyone basically has an SSD at this point, or at least a hybrid SSD/spinning disk, and so the interface can feel incredibly fast. Another example would be our choice of browser. So we work inside of Chrome, we work inside of a native app that's based on Electron. Electron, of course, is based on Chromium. These platforms can use newer HTTP protocols like QUIC and SPDY. We're talking directly to Gmail. Google have spent billions of dollars of putting hardware a mile or two from basically anybody. And so the very nature of the transport protocol and of the hardware, and because we don't— this is something I sort of glossed over, but we don't take a copy of your emails. We don't actually run servers. That would be slower than riding the coattails of Google. So this choice choice of architecture and the choice of using Chromium as the fundamental way to communicate with the network also ends up speeding things up.

Tell me more about the frontend. You mentioned Electron or Chrome, but I assume you're using React?

We are, except for the places where React would be too slow. And one of the classic examples is an infinite list. So one of the fun things I like to do just to see just to see how fast we are, is go to my inbox and scroll down. And this is a very complex piece of UI. You imagine you have 20 to 40 items on the screen. Each item has recipients, they have, which each individual React objects, they have a subject line, they have buttons over on the right-hand side, they have checkmarks that could be clicked to, or hits with keyboard shortcut to select the thread and so on. Now imagine you potentially have hundreds or thousands of those in your inbox. Well, clearly that would bog down the page to an unreasonable degree. The DOM cannot get that large. Your JavaScript stack shouldn't get that large. So what do you do? Well, most people who've done this know that to render an infinite list, you actually just keep a subset of the list around. And as you scroll down, as things scroll up off the top of the page, you unmount them and you remount them down at the bottom. It turns out that even doing that in React was too slow, as that is the only part of the app where we've actually unrolled it and hand-rolled it.

Very interesting. Well, so we talked a little bit about the front end. Tell me about the back end.

The back end uses Go, and it takes care of things like making sure that an email gets sent even in the most adverse of network conditions. So we have all had this experience, and I've heard this a number of times, you know, back when I was asking people people what their pet peeves about using Gmail were, or any other third-party email clients, the problem when you hit send and then you're in a rush, so you close your laptop and then you travel somewhere, and in the worst-case scenario, this could be like days because you're going to the airport or something, and you open up your email again and you connect to the internet and you realize that email didn't go because you closed your laptop too soon. So the way that we solve this is as you're writing the email, we actually stage it, just the draft, on our servers, on the backend, such that the instant you hit send, it's actually gone. And of course, we wait a little bit for undo send, but you're safe to close your laptop the instant after you hit send. You don't even have to wait for attachments to upload or anything like that. And so, that's part of what the backend does. It goes a lot deeper than that as well. Another example of what the backend does, and again, this is all written entirely we're entirely in Go, is this concept of a mass archive. So again, some of our users, or listeners rather, would have had this experience where they wanna declare email bankruptcy. And so what do you do? Well, you go to Gmail, 'cause you're not using Superhuman yet, and you select all, and then you click, no, select all really, and then you hit archive. Well, if you've got more than a few hundred messages selected, God help you, 'cause if you have 1,000 or more selected, you're actually going to rate limit yourself out of Gmail. And we've had customers who've done this prior to coming to us said, "I got myself rate limited out of my own Gmail account for 2 days at a stretch, and there was no customer support I could talk to. I just had to wait for the machine to let me back in again." Now, the use case is very legitimate. It is totally reasonable to say, "I am never gonna reply to any emails that are older than 7 days. I really just wanna archive them all so I can search them, but I don't want them in my inbox 'cause I actually want a chance of achieving inbox zero. So we do this on the backend. And what we do is during our onboardings, as you might know, we onboard every single user one-to-one. We actually ask that user and we say, hey, you know, we're super keen on getting you towards inbox zero. How about we archive everything that's older than, let's say, a few days? And obviously we can leave the starred items around or the unread items around or whatever permutation filter that you want. But we'd really recommend getting rid of those old emails and getting them archived. This is something that the backend does. And we've built a rather complex piece of machinery that can take an instruction like, archive everything older than 3 days that is not starred and which is read. And it will run that process gently in the background over time, always keeping an eye on the rates, never getting you rate limited, can be stopped, it can be paused, it can be reverted, it can be resumed. It's controllable by the user from the UI. And this is one of the many responsibilities of the backend.

Email is kind of interesting because there's a lot of functionality you can push to the client. You can have some functionality in the server, you can have as much as you want kind of in the client though. How do you balance that functionality? What do you try to push into the client to make it more eager?

In as much as possible, we put almost everything in the clients. These few exceptions would be where we want to share technology or capability between our mobile clients and our desktop clients, because at that point there is potentially some speed of development benefits to be gained And also, you know, lower maintenance overhead. You've got less code to look after in having it on the server. But for the most part, it's very, very heavy clients. I mean, this is by design. It's part of our strategy. We know that our customers tend to have really beefy clients. And so clearly we should take advantage of that in delivering the fastest email experience in the world.

How eagerly can you grab emails from the server?

Pretty eagerly. I forget the precise rate limits. If I recall, it's something in the region of 50 requests per second. Second to Gmail. If you go more than that, then obviously you're going to get rate limited, and the degree to which you get rate limited depends on how much you abuse the system. But that's fairly fast. So you could download a corpus of email potentially over the course of a few hours. It really does depend on the size of the email account, of course.

Can you tell me any more of the interesting client-server interactions?

Let's see. I mean, this is just a tiny little one, and it's an example of how we really try go above and beyond. So when you send an email in Superhuman, there's obviously a notification in the bottom left. It says message sent. In that notification, it says undo. Now you can hover over that notification. When you hover over that notification, a really cool thing we've done is the client tells the server, hey, by the way, users in the zone, they might decide to undo sending this email at any point. Hold on to it. Don't send the email. Don't send the an email. And this is because I've personally had the experience, I've had users had the experience of in Gmail, they send an email, they're moving their mouse all the way up to that undo button, and the mouse is hovering over it, and guess what? As the mouse is there, it disappears from beneath you. It's the most utterly awful feeling, especially if you said something terrible. And so it's a fun little client-server interaction, but if you're hovering the mouse over our undo notification, the client will forever tell at the backend, don't send this thing until you move away for a certain period of time, or of course you click undo.

Let's talk about some more engineering subjects. So what about reliability? Like, this is— it's email. This is really important. Your email messages should be sacred. They should not be tampered with. How does reliability factor into your engineering?

Absolutely hugely. To the point where if something is affecting reliability, we treat it critically, it bounces the queue to everything else. And internally we have two tags that we use to label a potential reliability issue. And unfortunately we haven't had to use either of these for quite some time. But one is lose data, and this is an issue that has potentially caused the user to lose some piece of data. Perhaps they lost a draft or something else went missing for some reason, or look foolish. Which depending on your perspective, could be even worse. This is where the user has done something which has caused them to not represent themselves in an ideal fashion to somebody else. Maybe they sent a half-finished version of their email or something like that. Now, we haven't had to use these for a while, but in the early days when— because you're right, building an email client is super hard. The surface area is immense and reliability is mission critical. We use these labels to triage what we we did.

What about testing principles?

Testing principles, I mean, we obviously write a ton of tests, and that's everything from unit tests to integration tests. I wouldn't say that we have a testing principle, like it's— we're not as extreme as saying, oh, we do test-driven development or anything like that. For us, what's really important is making sure the product works well in practice. And the way that we've accomplished that over time, in addition to using the lose data and look foolish labels, is through this notion of onboarding. So folks might not know, but we onboard every single user one-to-one in a 30-minute video call for Superhuman. And initially we did so deliberately slowly. Back in the day, about 2 years ago, when it was just me doing the onboardings, I would do only about 5 or 6 onboardings per week. Why? Because that would give me the opportunity to sit down with each user and watch them do their email for about 30 minutes. And actually, back then, the whole onboarding process was 2 hours. So I got a lot of face time with users, and inevitably I would find 5 to 10 bugs, some serious, most not so serious. But in any case, I would take those back to the team and insist that we fix them before we onboard next week's cohort of users. Now, why did we do that? Well, if you don't do that, what you end up with is a piece of productivity software that's like basically every other productivity software that is 2 years old. It's immature. It will only be usable by early adopters because most people, most mass market consumers have a really high quality and reliability bar, and if you don't fix fix the obvious bugs, people aren't going to run into or report the non-obvious bugs. This is what I call bug reporting fatigue. Any given user, let's say, might only ever have the enthusiasm or the energy or the initiative to report 4 or 5 bugs over the course of their lifetime with your product. Now, if your product is buggier than that, then given a certain number of users, you won't actually find out about the rest of the bugs. That's why it's so important when you're building complex software to onboard users slowly, to observe them using the product, and to critically fix their issues so that the next cohort of users can uncover the next cohort of issues.

Tell me a little bit more about how you manage the engineering across your different teams.

Well, these days it's very different to back in the days I was just describing. We have a head of engineering, Mouya Reynolds, She's amazing, you should totally talk to her at some point. There are only 14 people in the world who've been making iOS apps for longer than she has. She was back at Apple in the early days of Apple. She runs our overall engineering organization. She reports directly to me. She also serves on the leadership team, so she takes a hand in running the company. And she also runs customer delight, which is what we call customer support. —there's probably an interesting side conversation there. It kind of relates to your reliability question, but I deliberately decided to put support adjacent to engineering to make the distance between users and support and therefore engineering as small as possible. And this, it turns out, increases the velocity at which you can fix bugs and maintain quality and reliability. She then works alongside Conrad Irwin. Conrad is our CTO. He's a co-founder of the company. I've been working with Konrad for over 10 years because he was the first employee I ever hired at my last company, Reportive, and he is also phenomenal, probably one of the best engineers you'll ever meet. He was a core contributor to Pry. It's used by about 25% of all Ruby developers. And, you know, when we sold our last company, Reportive, as a fun little story for you, we obviously interviewed at a bunch of different potential acquirers. There was LinkedIn, of course, who ended up buying us, but also Twitter, Facebook, Salesforce, and a few others. When Konrad interviewed at Twitter, he scored the highest engineering interview scores of any engineer to have interviewed at Twitter in the entire history of that organization. So that sort of gives you a sense of the caliber of the leadership team, and both on the head of engineering side, on the CTO side, and we've continued to make maintain that bar. So we split the team up into mobile, desktop, and backend, and every single engineer on the team has come to Superhuman having done something incredible in the past, whether it's a work achievement or a piece of open source that they've worked on or something that they've contributed to the community or something that they've hacked on. Everyone's done something really, really cool and is continuing to do something amazing at Superhuman. Let's talk a little bit about the future.

Do you see any opportunity with WebAssembly?

Actually, yes. I was talking about this just yesterday with our dear Conrad. So one of the things I'd like to get to is writing assistance. This is a set of technologies broadly related to helping you write better and faster. I think people are familiar with the macOS style autocorrection, also available on iOS. Folks will be you're familiar with Grammarly, that gives you style advice, and there's a bunch of things in between as well. Now, having done 500 onboardings myself, if not more, I've witnessed firsthand that one of the next frontiers of speed that we can unlock is helping you write faster. And of course, this is something that Gmail and Google more generally is working on with things like Smart Reply and predictive autocomplete. So I actually think we can do better than that, I'm not going to reveal exactly how, but part of how we plan to do it is by leveraging WebAssembly, because this stuff isn't easy, you've got to run machine learning, or at the very least inference models, on hardware, you've got to do it fast, and you've got to do it in a way that doesn't impede typing. So one of the things that we might actually do is not write this in JavaScript, how we've written most of the rest of our apps, but actually, perhaps work with existing Java libraries or write it in really any language that we want, but then compile it down so that it will work in WebAssembly.

Fascinating. As far as the competition with Gmail, I wonder, can you compete with Google's kind of economies of scale and what they can do with the, for example, the smart autocomplete? Like the smart autocomplete in Google is kind of a killer feature. I wonder if you can replicate that. I think we can.

I don't think we could individually as an organization, but it's so obviously beneficial. And I would actually argue it's more beneficial— this is what I personally find in Google Docs compared to an email— but it's such an obviously good idea that I can think off the top of my head 5 startups working on it right now. And I'm also an active angel investor, so it's something that I pay very to pay close attention to and stay close to. I think that, and especially given the advances that GPT-3 has made, and we're working closely with OpenAI as well, I think that in a fairly short period of time, it might be a year or two, there will be libraries widely available to do that kind of thing. Probably actually, I'm gonna rewind that, not libraries, there will be services. I think that this stuff is hard enough and requires venture capital You'll have to pay for it, but it is totally feasible that this will become integratable in the order of magnitude of years.

So you think this will be available as a service and you can just import it as a library or something? Like I said, I know, yeah, at least 5 teams working on precisely that. Fantastic. What else? What's the biggest engineering problem you've had to solve in building Superhuman? Biggest engineering problem.

There have been so, so many. I'll tell you a fun story of when it was particularly hard to debug something. Debug stories are always fun. So for example, in order to power our blazingly fast search, we index emails using WebSQL, which some folks might know is actually a SQLite database built into Chrome. It turns out we are basically the only production user of this, I think in the world according to the Chrome team, at scale. Now there was an extremely esoteric bug in the full-text search of SQLite that crashed if certain specific requirements were met. And this bug was very hard to track down because the database had to be in a very specific state. In particular, let's dive into the example just for color. You had to have unbalanced search trees, unbalanced in such a way where the adjacent node was in fact null. So you'd have to have an index with, let's say, a lot of words starting with the letter A, none starting with the letter B, but some starting with the letter C, such that when you insert a new word starting with letter A, it tries to split the A node, 'cause the A node has got too big. But because B doesn't exist, guess what? It segfaults. And this was happening to hundreds of our customers every single day, because Chrome had updated the version of SQLite that they use. And then our CTO, Konrad, completed a feat that is truly heroic, working feverishly morning all the way through night, I'm not even sure if he slept properly, through one weekend. He jumped into Superhuman, the codebase, found out that the issue didn't exist there, jumped into Chrome, the codebase, found out that the issue didn't exist there, jumped into SQLite, the codebase, git bisected himself all the way through the recent commits, and by the way, this is software that's extremely widely used, it's super battle-tested, and found the single errant line that was causing this crash. He then reproduced it locally, wrote some tests, submitted a patch, SQLite accepted the patch, updated their code, we pinged the Chrome team, they updated their SQLite, they released that new code, and now that code with Konrad's bug fix is running in every instance of Chrome around the world. So sometimes the bug is not in your code, it's in somebody else's, and in this case the bug was not not in Superhuman, and it wasn't even in Chrome, but we fixed it nevertheless. And that's just the kind of thing you have to do if you're serious about quality.

Interesting. Well, any other parts of Superhuman that we haven't really explored in much detail engineering-wise? Sure. I mean, there's going to be quite a few.

What kinds of things would you like to go into?

Technical things, distributed systems. Yeah, you got any distributed system stories?

Not really. I'm sure we have, but it's probably a little bit further away from what I personally get involved with. I'll tell you another WebSQL story just because it's sort of top of mind having, having talked through all of that. Like I mentioned, we are, as far as we know according to the Chrome team, the only production user of WebSQL at scale. And there was a point in time where they did not know that, and so they were actually planning to remove remove WebSQL from Chrome, to the extent that they had removed it from upstream versions of Chrome before it hit production, but in Canary and in beta. And this caused a considerable degree of panic inside of Superhuman. Imagine if you've worked for years on an app, and you know like clockwork there is this thing coming down the line. You've got about 4 weeks before it hits production, and it will literally break your app that you've built for everyone, an app that people people are paying you for. And we didn't have long to deal with this at all. So this really isn't an engineering challenge, it's more of a sort of an existential crisis for a startup. I mean, how do you deal with this? And this is really going to be more of a sort of a founder tale, but it's a good example of why you want a diverse cap table. It's why you want lots of different investors in your company. So I went to Firstround Capital, who led our seed round, and I said, look, this is the issue. I need the highest level introduction to the Chrome team possible because the folks that we're talking to right now, they don't seem to be able to help us. And they tried, they figured out the people that they knew who was running Chrome, tried to get connections, but it just didn't work. I tried it with our other major investors. It just didn't work. And then sort of as a last-ditch attempt, I downloaded our cap table about every single angel investor who's ever invested in Superhuman, and it's sort of 200 at this point, and I basically mail-merged everyone, sort of this panicked email saying, "Hey, this thing is gonna die shortly. I'm pretty sure they're not doing this deliberately. This seems like a complete oversight. Please, can someone help us?" And I got a bunch of emails back saying, "You know, I'm really sorry. I've put some feelers out. I'll let you know if something can be fixed relatively shortly." And I got one email back actually from Sam Altman, most of our listeners will know as having run YC for a period of time. And he said, "Yo, I happen to be at a party where Sundar is standing and he's standing right here next to me." This is Sundar Pichai, the CEO of Google. He said, "Give me an hour and I'll get back to you." And so, I can only imagine what happened because at that point, of course, it's no longer via email, but I assume that Sam goes up to Sundar, they have this conversation, the next Next thing I know, this whole train of events is set in motion and Google reaches out preemptively like, "We're so sorry. This was totally not deliberate. Our goal is obviously to push the web forwards and we didn't know that this was being used in production. Now we do. What can we do? Let's work together." And since then we've had a really, really strong relationship with the Chrome team and they've been fantastic to work with.

That's a great anecdote. You got any more cool anecdotes?

Not off the top of my head, but maybe you could jog some memories if we ended up talking about something else.

Well, one thing I wonder is like, how much scalability is there in your infrastructure? Does it really matter? This is kind of just like one client and it kind of pings the server and then that's it. You don't really need to scale it up, right? Exactly.

This was one of the core reasons why we decided to architect it the way that we did. And okay, so you wanted a fun anecdote. Here's another little fun anecdote, our last company Reportive that Conrad and I also worked together was the opposite architecture. Everything ran through our servers and we had a very complex database schema where for each user we stored a representation of the entire world, what they can see, what they can't see. It's sort of the n by m problem for anyone who's familiar with that. And as a result, we were running the largest database on Heroku. For 2 years in a row, we had the largest database on Heroku, so large in fact that they had to provision special machines and special services just for us. You couldn't achieve the database sizes that we needed to via their dashboard and their user interface. And it was really, really expensive to run that. We've all heard horror stories of how expensive Heroku and AWS can get when you're at scale. And for this company, Superhuman, we knew that unless we were careful, it would be significantly worse, because back then it was only just contact data, it was only just social profiles. Per person, you're talking about perhaps 15 to 50 gigabytes of email data, so clearly we're not going to store that, let alone for the performance and the security and the privacy issues. So we decided not to, and we decided to instead index everything on the clients themselves, to not store it on the servers, and that gives us an inherently significantly more scalable system. Now, that said, there's still a backend. There's still a users table. There's still sending emails to deal with and all of the things that we've talked about. There's still the gentle archive process that I ran you through. And so there's still bottlenecks there. It's just that with the architecture that we've chosen, we've pushed out when you would have to scale to significantly later And this became readily apparent with me when I spoke to the old Mailbox team. They've now moved on, they're building something new and it's super cool. But they shared with me how when Mailbox launched, they didn't make these choices. They centralized everything. And it was one of the things that critically slowed them down because they had to spend so much time and energy just trying to scale their service to keep up with demand.

Interesting. Well, I guess we can begin to wrap up. I want to thank you for coming on the show. It's been a real pleasure. Talking to you, I'm trying to think if there's one more question I can ask, 'cause Superhuman is something that a lot of people wanted to hear about. Here's a random one. Any engineering difficulties in maintaining consistency across iOS, Android, and web? Do you use React Native?

We don't use React Native, no. So almost all of the iOS app is built using Swift. There's a few areas of the app like quoting logic, dealing with the internals of HTML data itself, we are doing very complex string manipulation that is in fact written directly in C++. For our Android app, we're using Kotlin. So, I think the most interesting answer to your question is, and I'm going to give you a product management slant, because we started the iOS app a little bit later, compared to the desktop app. The desktop app had a 2-year head start, so it was quite a lot more featureful. It's only recently that they've sort of come into feature parity. And we'd get asked this question a lot by customers who write in, and they say, "Hey, why haven't you built my pet feature?" Which incidentally would take us a year or two to build, of course. And so I think of our team capacity now like a glass jar. You know, launch projects are big rocks, medium and small projects are pebbles of small sizes, and the most efficient way to fill that jar is a combination of big rocks and small pebbles. First you add in the big rocks and then the pebbles can fit in and around them to fill the jar, but if you were to add the pebbles first, fewer big rocks would fit in, but if you only added big rocks then there would be unused space. So what we do is each quarter we identify one massive rock and a few medium-sized stones and a large number of small pebbles, and we know roughly exactly the order we're going to do them, but what the small pebbles give us is the opportunity to be flexible with the plan in the face of unknown unknowns. Let's say we run into an API issue, which I'm sure everyone listening has, or there's a scaling problem, which we've all dealt with, or something else, maybe a key engineer leaves the team, so something happens that throws a wrench in our otherwise beautifully designed plan. Well, then what we can do is we can move those small pebbles around and still ship with high cadence, high quality, high reliability, despite the headwinds and despite the changes.

Well, that sounds like a good place to close. Thank you for coming on the show, Rahul Vohra.

Well, thank you so much for having me.