Extreme Native Perf on the Web with Superhuman

Everyone, before we get in real quick, this is an episode with the head of engineering at Superhuman, and we recorded this before the news of Superhuman was acquired by Grammarly, which is is absolutely wild.

We did not know that this was gonna happen, and I don't think that it changes any of the conversations because we Yarn talking about, development methodology, CSS, their engineering philosophy, and and how they make everything fast. Tons of local first stuff.

But I just wanted to tell you because there's probably a couple keyboard warriors already in the comments being like, this is a sponsored episode. We would never do that to you. It's not sponsored at all. We've been trying to get somebody from Superhuman on for months now, and it just so happened to line up. So enjoy the episode.

Welcome to Syntax.

Today, we have a really great one. We're gonna be talking about one of the most performant and excellent apps that I use in my day to day every single day. We have an amazing guest on the show with us. We have

Loic Oiseu.

Oh, I I butchered it. We you cut to me because I can at least French Canadian accent it, but

one of the only things I've perfect. Yeah. First name was perfect.

Okay. You got it right, Scott. Thanks. I appreciate that. And

we're gonna be talking all about how the heck this thing is so good. You Node? It it's got a army of super fans, and, I was kind of one of those people who saw a lot of people talking about, superhuman being so good and was like, how can it be better than an email app that I'm using today? Email apps are all the same. And then I, I bit the bullet. I signed up, and I regret doing that because it's now ruined a lot of software for me. It is so so wonderful in many ways. So we're gonna be talking all about that.

Louis, welcome to the show. Thank you. Thanks for having me, guys. I mean, I listened to some of you on I was at previous show, and it was, like, super interesting to, obviously, to listen to it. And, I feel humbled, like, now to be, like, joining you there and, maybe, like, sharing some of my, I would say, perspective or, like, experiences if I can provide some some good content. So we'll see we'll see about that. Yeah. Because you I mean, you've been you've been, you know, around a long time. You were at DocuSign for a while before. Right? And that's like a

massively used app. So, you're no stranger to high performing,

applications on the web. Right? Yeah. I mean, I've been around. Like, I have some gray hair, and it shows. So so, yes, I've been around and I've been, both in, like, a massive companies earlier in my career in France, like big Scott, type of companies. I've been in small companies through acquisition. I joined DocuSign.

So where we had, like, the scale up IPO trajectory just before COVID Wes it was a bit, a bit crazy. So and there's some fun stories about it. But then I decided to move back to, like, smaller companies, Node start ups. Usually, Node remote setup, remote and hybrid, and distributed, which had some complexity, but, also, like, more fun. And, just joined, like, Superhuman six months ago. So pretty cool.

Yeah. So yeah. Do you wanna tell us a little bit about, yeah, a little bit about maybe Superhuman as what it is, and then also what you're doing on Superhuman?

Yeah. I mean, I I'm I was a queue. Like, I was not using the the product before, getting in touch with, with the team. And I was like, how come I would pay for something that is free? Like, I'm using Gmail. I'm a Gmail user.

I like all of my setup JS done there. Like, all my filters and all. So I felt productive.

I felt productive. And then I tried the product during, like, when I was chatting with, like, their their teams.

And before joining, I was like, yeah. It's nice. It's beautiful.

It's fast. Now the question is like, okay. It's better. But then would I pay $30.40 bucks a month to get, I would say, that amount of better? So I was like, Node. Not sure. Not sure. And we keep talking, and I I love the people. I love their perspective.

I love, like, the the vision they had about, like, how the craft should be done and how delight can, basically create a business. And after three weeks, they have this wonderful PLG motion, like product like growth motion.

And they kinda, like, trick you into using the keyboard shortcuts.

So, like, the education in product Wes really good. And after three weeks, I was like, holy cow, this JS fast.

There's no freaking way I can go back to Gmail. And I was like, okay. I need to understand how they do this. I need to understand how they basically make me happy to pay $40 a month, like, for something where the competition is basically free.

And and it's super interesting. So I joined six months ago, there.

And with the Scott of like a mandate, like, Wes you come as a CTO or as a as a VPN, there's always some sort of, like, a mandate. And and my goal was to, and the goal is to help the team embrace, like, this new paradigm, like, with AI, and how you bring, like, ESLint basically JavaScript oriented organization, where speed of execution was maybe not the first focus because the perceived quality was way more important.

And how do you balance that more? How do you use AI, basically, to get that productivity gain while still maintaining the bar super high? So that's that's what I joined, and that's what I'm trying to, I would Sanity help the team, I would say get better with. Are you talking, like, adding AI features to the product, or you're talking engineers using AI to build the product or both? That's a great question because both. That's that's both. Because JS, like, every people that are, like, focused on the craft, you have your own set of tools. Like, you have your flow as an engineer. Yeah. And you tweaked it to to be, like, a feel great in your flow.

And AI is coming here. It's like kinda like redefining what even the flow is. And, so that's that's one aspect. The other aspect is Wes are highly qualitative product, and all the quality just depended on us, Like, on engineers, on quality and, like, all the work that you're doing. And all all of a sudden with LLMs coming, some of your features, the quality, like, garbage in, garbage out, depends on the user now. How do you control the perception of the user so that when the result is not up to their bar, they understand that they are doing something wrong and you help them, like, increase or improve their prompting capabilities, when when needed. So, like, both aspect are really key for our success given that Wes level of expectations. Like, our users, they don't accept okay. Yeah. They're paying a lot. Which is probably like the for the problem. Right? Change for me. Well, let's talk about that. Like,

when you when you talk about, like, this, like, top tier software that is expensive but worth it. You Node? People always think about, like like, Panic, big IO or big macOS and and iOS applications. They they produce really nice stuff. And almost always, when it's just, like, high quality software, it's always, like, native. But Superhuman is not native, is it?

It is. It is. It is on mobile. And, for desktop, we have basically an electron app. But, like, everything like the web app and the, desktop app basically share, like, 90% of the Node. Mhmm. Which interesting using, like, a bunch of the browser capacity for everything that is storage and everything because we are offline first. And we might talk about it, because that was, like, one of the design choices because we have this hundred millisecond rule for every interaction in the product, and you have to be, like, intentional about it. How many milliseconds? Hundred milliseconds. Yeah. We we're targeting 50, but, like, ESLint interaction that is taking more than 100 JS considered bad or poor quality.

Mhmm. And it shows when you use the app. I mean, especially because so much of the general workflow for people who might not know, it is via, like, keyboard shortcuts. So when you're using and you you really get the keyboard shortcuts, if it's not feeling that fast, I mean, you're gonna notice it right away. So you're saying the iOS app is native, but the desktop app is Electron? Yep. And what's the what's the UI done with? Oh, React.

React. It's basic mostly React.

Interestingly, we don't use just yet any design system.

So everything is bespoke mostly because we have Sanity emphasis on local optimum.

When it comes to the user interaction, you want everything to feel great.

And to do that, sometimes, with design system, you're somewhat limited.

So for quite a long time, like, everything was bespoke, in every single pieces of the, of the product. Wow. But yeah. That's that's intense.

How do you mean consistency then if you have no design system?

You need a bunch of senior people. You need to hire engineers that are product slash design engineers. So you need people that just have an eye for something that feels off and that can, like, make it right. So we are very intentional in the people that we hire. We don't hire, like, software engineers. I mean, it's kinda like a a caricature to say that we hire, like, product engineers. Everyone is saying that they they hire, like, product engineers. But a good portion of our interview process is focused on especially for the front end people, is like focused on your ability to to craft, like, your great user experience.

So we just don't want, like, people that are great at, like, whatever the frameworks or all of that. But like, very CSS oriented, very, like, detail oriented. So, yeah, you you have to you have to be intentional when you hire. And we have a lot of, like, internal trainings, I would say, coming back and recurring

about, like, all the engineering principle that we need to apply in the in the way we work. Man, that's wild to know. It it's interesting too, especially because I would have thought, you know, some of the other apps that we've used that have, like, a electron based desktop app that you would use, also something similar for their their mobile app. And the mobile app does feel like it could be very much the same UI code Bos or anything like that. That's interesting to know that it's it's different.

Also, like, I have found that Superhuman looks different than many apps that I use. It doesn't have that same kind of, like, generic looking, style to it. So I would imagine that that designer kind of product developer fits with that as well. And and those type of product developers, they're they're focused specifically on speed as well, or is that speed aspect of it like an entirely separate team?

No. No. No. Speed is not a team. Speed is like, I would say, part of the quality process. So Yeah. Everyone is looking at speed JS, something that is mandatory as part of the user experience. So it's not an afterthought. And and Mike, our chief architect, would basically say that speed needs to be, like, the first thing you would think about rather than the last thing you think about. Like, if you think about, like, building a feature, you need to understand how this would be fast while you're designing, the UDP application. And that's why we moved to, like, offline first. It's not because we wanted to support offline. It's because the number one culprit when it comes to, like, slowness is the network. Especially Wes you're talking emails and you're on your mobile phone, you have a shitty network. Like, you don't want this to be felt, and on the end users, side of things. So we do a lot locally. We do a lot locally.

So it might surprise you, but for example, there's a database on your, I would say, iPhone mobile app. We are not getting the data live. We basically, like, sync the last thirty days and moving onwards. So we have a huge footprint on your phone so that everything that search can work offline and be, like, crazy fast. We don't rely on, the provider of surf, like Gmail or Outlook, for example. Only for stuff that are, like, back in history. But, like, the last days, it will feel, like, instantaneous because it's local.

Yeah. I I've been getting into a lot of local data stuff myself and sync engines and CRDTs and and those types of things. Can you can you maybe, like, talk a little bit about the tech behind what local database you are using and how the same process works? Yeah. So take everything with a grain of salt. I'm the VP edge. I'm not the engineer. Neither I'm, like, the the chief architect.

But, so right now, we are on mobile, we warp using Realm, but, like, we are moving away. And, we Yarn, like, at the decision process to understand which tech we will, use globally. It's kind of like a secret light, approach. I remember Realm. Yeah. On the browser side, the same.

So we use an extension. So we have an extension that is, that is used both by the electron app and the the mobile the the web experience.

And we still on, like, we use the browser APIs and everything to basically store locally. And, we use a submission of SQLite as well to Scott stuff. There we stop basically emails. We store your, events, agenda, like, calendaring.

Like, everything like this, is locally stored.

But it's stored like like JS, we Scott the emails, but, like, we have, of course, some back end capacity where we store more stuff, more history, for example, but also, like, everything that is needed for rag systems where we have, like, a dedicated, vector database, which is not local. So we don't do AI locally on device just yet. So when you're offline, you don't have AI. And, that's, that's a design choice for now. Maybe it would change eventually, but, right Node, we are sticking with it. And Yeah. Why why is that? Is

because, like, I've I've been talking to a lot of people who are starting to do especially as the processors get faster in these phones and and we have web GPU and whatnot, where you're able to do embeddings, like, fairly fast on device.

What's the choice for not doing that vector search and embeddings on device right now?

Because usually, we do the vector search to do something. It's like the vector search is only one piece of the feature that you want to to provide. So I will give you some example, but we do Node, draft creation, for you. So funny enough, Superhuman moved from being the fastest email app to the most productive email app. And part of the productivity is creating for you drafts that are ready to be sent. Like, you don't even have to think about it. Someone ask you a Wes, we look at your I would say Sanity, and we provide some answers that hopefully are 90% of the time. Right? And you just have to hit send. Boom. You're done.

Typical use case as well is like, you ask a question to someone and, you have like, some sort of like a reminder that JS ready, so that you can Node people pretty fast, without thinking about it. And to do this, we need some tones. We need some, information about, like, the past emails that you sent to those people, and you need to process the email. And everything that is generative on device is still relatively slow Mhmm. Right Node, so the experience wouldn't be great. So the question is, like, are we okay with somewhat, like, a a slow, like, generative feature that would make you wait, or we just don't allow it at all? And coming back to the our principles, okay is not good enough.

So this is, like, typically the case where devices and models, like, running on device are not good enough just yet for our quality bar.

So and and that's tough because we we could, I would say, implement something.

But, like, our user base, like, they need something that is clean and well done. Mhmm. So you have always to ask your question, is it good enough for them given the past of quality and delight that we are providing for every feature?

Yeah. And and as far as AI features go, like and and you mentioned, you know, speed being a highest priority. I know I know that, like, AI isn't always seen as being, like, the fastest, thing. You know? You're waiting for a response, streaming in, etcetera. But, like, what kind of AI features does Superhuman implement or can they implement that don't need to feel, like, instantaneously fast, like, async kind of features?

Yeah. So so that's one point. Like, we do it, I think, so that it's ready Wes, I would say, you open the, I would say, you your superhuman app. So I was mentioning those, drafts or, like, the classification of your email. Everything is happening on our back end. And when we open the you open the app, all your emails are filtered automatically and the draft are created. So we try to optimize for those processing that can happen, basically, before you open the, the app. Most of the features are like this. We still have some features like augmented writing, like you want to and, like, rewrite, like an email because you don't feel right about it. Like, you don't want to go to JPGPT and everything. So, like, come on, Jay, and improve writing. Boom. And you Yarn, like, this being processed.

And then it it's kinda like using some UX tweaks to make it feel that it's instantaneous.

So you cannot just wait with, like, a spinner saying, like, hey. Reviewing your comment. So for example, like, if you compare to Notion AI, if you're using, Notion AI to rewrite some content, it will feel relatively slow. They will basically strike through stuff. So they add some complexity to the user experience Mhmm. Showing they do something.

And, eventually, you accept the modification.

We don't do that. Like, we basically, like, write and basically, like, the streaming APIs are good enough to to make things, like, feel fast. Basically, it's writing faster that you can read.

So you don't need those extra stuff and those extra things that Node is doing, for example. So we try to get rid of the clutter so that the experience feels, like, really fast, there.

Wow.

Yeah. I I I I just popped open my little latest updates thing because it feels like there's always, like, new updates. So you all are are shipping a lot of things really fast, which on the surface level, when you you look at superhuman and UI is not, like, changing substantially all the time or doesn't feel like a different app. But here's just, like, four new features I I didn't even know about. So, like, how is your team able to ship so much so quickly?

We are a startup, and we work hard.

So that's I mean, honestly, that's, that's a part of it. Like, we work Yarn. And the the I mean, I have freaking good engineers, to be fair. Most of the team like, the average tenure is probably around, like, three years on average, with people up to, like, six to seven years. So we have a bunch of seniority and knowledge, that is already in the team, which helps.

We are pretty intentional, and we try to prepare things so that when we work on things, on on features, they are baked, already to some extent so that, we can keep the flow going.

We put in place an organization that is pretty domain centric. So we have three big domains in Superhuman. The calendar experience, which is a new Node. The triage experience. So we have a team dedicated on the, like, the focus that you need to get when you join. Like, for example, you go to Gmail, you have a long list of emails and it's kind of a mess. You have the creative load. You need to go then you need to go through it. So we have a bunch of features like splits or like, automatic, upgrading of, like, the clutter so that you can just focus on the right thing. Wes have a team dedicated to it, and we have a team dedicated with engaging with your emails, where this forwarding, commenting, responding, basically. So those are the three teams. And when you have teams that are, like, laser focused on their persona, the way they use it, the the complaint that they have, it's easier to get velocity because you know your stack, you know your code base, you know the complaints, you know, like, the how people are using it.

It make things, I would say, faster.

And to be fair, AI is a ping a lot. Anecdotal feedback, like, it's based on, like, self, like, we did a survey and people were, like, providing, like, their own appreciation of, like, the productivity gain they they they get from AI. The answers were roughly between 2030% productivity gain. So it's not doubling our capacity just yet, but, like, it's significant.

It's significant.

I wanna talk a little bit about just, like, email overload and being able to find what is important. Because this is something I think a lot about right now JS that tools like Superhuman allow you to just send a whole lot more email than you normally would because it it'll you just said it. It'll generate drafts. Right? And so there's there's, like, this new area of it's not necessarily spam, but it's just like this, like, generated cold outreach that I get. I probably got 15 already this morning, and I'm I'm I'm kinda at my wit's end with my email right now. I'm just I'm sick of it because it's it's so hard to find what is important. So I'm curious, like like, do you have any thoughts about how email in the future is going to look both from sending lots more because it's good for business, but then on the inbound, having to be offensive and try filter for filter all this crap out.

No. No. No. I mean, this is a this is a good point. Like, the one thing that was interesting, like, before talking about the future of emails, like, if you look back, what was the past of email, like, everyone JS, like, our customer base, like, 90% of our users are using Gmail, and the enterprise customers are on, Outlook, roughly.

So that's kinda like the ninety ten is like the Mhmm. The the way Wes think about it. Like, think about Gmail.

Gmail has, like, no interest in getting rid of the spam or, like, the marketing spam. Mhmm. Mhmm. Because, of course, Gmail is a marketing ESLint. Like, Google is a marketing engine, and that's Wes we said they are kind of like bread and butter. So they cannot just help you only receive, what makes sense for you. Like, they need that volume of data. We don't care because that's not our pricing strategy. That's not the way we make money. And and that's coming, like, today. Like, this is what you have right now. We, and especially using AI, it's so much easier to detect whether an email is a pitch. Like, your company reaching out to you to send you, like, the new CICD tool that they've been working, they're out of YC, whatever, and they want to pitch you. Or, like, those marketing emails because you use, GitHub or GitLab on a daily basis, they send you, like, some marketing content associated with, like, the new features and all of that.

Yeah. Pardon my French.

That close. That close.

But we all get, like, all those emails. And and honestly, to be efficient and, especially when you're a see label, there are some stuff that are really crazy important and that clutter that you would love to get rid of. And now we get rid of it. Like, our users, like, everything that is marked as a pitch or marked as a marketing email, you can select auto archive it. So you don't even see it. It's not even showing up in your in your email. And then you can do some, pretty, like, a nice thing that you can point the classification.

You can say like, oh, you know what? Everything that is, like, a podcast related or everything that is, coming from my board, like, as wide as this. And my board are, like, people like this and this and this. So you can write poems now in Superhuman to classify your email so that you can see this is important. This is important. And and it's working great. It's working great. So that's that's Node, like, one way. But the same, like, you can expect those marketing people, I would say, to build some outreach, like, hidden text that we try to mess up with the LLM that is doing the classification. Like, it will become like the the typical spam, anti spam, war. And, it's just like the the weapons are different right now, but it it would be Yeah. Like, we get people Node. They will ingest the transcript from the last six episodes,

and then they will say something like, oh, I also live in Denver to Scott.

And they'll they'll try to make it personal.

You know? Or they'll ingest, like, three episodes and 10 of my last Instagram stories, and, like, they'll it's it's awful how personal they're trying to make it. You know? And now I'm trying to write. I use I use missive, and I'm trying to write these, like, AI rules that I'm on the offense of it, and it's just a waste of my time.

Give it a try. Give it a try. Let me let me know. Let me know how it works. I have found the the labels, the auto labels to be super useful. I I I posted one in our show notes so Wes could see just to look at labeling a pitch that somebody had, sent me, and it clearly labeled as pitch. I didn't know you could set up your own custom auto labels, though. I haven't done any of that yet.

And search with AI as well. You know? Show me the emails that I don't know. Six months ago, somebody emailed me Wes a print of a sticker. You know? I I hate having to, like, try to hit all the keywords properly.

I use I use this AI search, like, almost on a daily basis, because, like, a lot of my knowledge and content is in my email. The the last example, over the weekend, I was working on my citizenship, application.

And for the people that are going through this, like, in The US, you need to go through the last five years of travels, outside of The US. And I was like, oh, damn. I remember, like, I went to Japan. I don't remember the dates.

Hey. Can you find the tickets, like, for my trip in Japan that I believe happened in around that timeline? Boom. Boom. Boom. And I I get those emails and I have the dates and done. Like, I was done with it. So this JS, like, city examples.

But, like, AI search is definitely something that is, I Wes, like, crazy good. The the next piece that will be, like, very interesting and probably will ship that early q three JS like someone asking, like, a friend of you already in your, like, I would say, indoor list of contact and all of that. Asking for, like, a slot. And, like, hey. Can we meet, somewhere next week, please? Wes have access to your calendar. We have access to your availability. So we can auto draft an answer and propose, like, a slot or a set of slots that are working for you. And then you just have to basically hit Sanity and boom, you're done. So a lot of stuff like this now are possible because of LLMs that used to be, like, just impossible to do before. And if you want to see all of the errors in your application,

you'll want to check out Sentriads. Yeah. I was wondering about I even had on my question list given that there is, like, there is a calendar integration, and it does seem to be getting more and more. I haven't found it to be able to actually replace my phone calendar just yet, but, like, the fact that you have so much information one of the things Superhuman does already really well is contextually aware things. So, Wes, you might not know about this, but somebody in an email will say, like, currently, this is the way they currently work. So they'll be like, what do you think about Wednesday? When you open that email, it will actually pop open the calendar and show you Wednesday already so you can see exactly what your calendar JS like on Wednesday. And I use that, obviously, all the time. How did those type of features work? Is it just simply, like, looking for certain strings and then,

choosing what to do with them? Yep. Totally. This is the type of features that might feel overkill for, like, a typical b to b SaaS company.

They would be like, nah. Let's not do, like, a feature like this. Like, people can click on the calendar and go to that. Like, they can do it. There's a way. And this is where, like, we have a a CEO from the that is a kinda like an art director to some extent and has, like, a product test and understand what are the feature that will create delight, in the end user. And this is typically one. You open this calendar and boom, we can we see there's a date, and it's not that complex to find a date, like, in in a text. And boom, you pnpm, like, the, I would say, the right, sidebar. And it's probably working, like, 95% of the time, but it's just delightful because you you feel you're in the context. And this is something that is really important. Like, you Yarn mentioning the fact that we have a lot of features, but we are not cluttering the experience. Like, the experience still looks sleek. Mhmm. It's not a lot of bittains. Like, we are not adding, like, a new button. Like, every time there's a new feature, we want this to be discoverable, but hidden, I would say first. So you need to, you know, like, learn to use them so that the experience always feel slick and, like, the you always, like, in the focus mode. That's something that is part of our Wes, like, design principles.

That parsing of the date, is that done, like, programmatically, or is that done with, like, a model?

No. It's in the model. It's programmatically done. So this is typically the a place where, like, with the right reg apps and everything, like, token detection and all of that, there's a bunch of libraries that can do this. Honestly, I would need to check, like, which one we're using, and I can, like, also provide that after the show. Node clearly, this is, this is doable without, without LMS. Yeah. Which is so nice because, yeah, it it that allows it to be

fast. It allows it to just happen. But, like, as you it it's funny that you said delight, obviously, because that seems like really what it is. But the first time it happened to me, that was the discovery moment. When you open an email, all of a sudden my calendar is open, and I'm like, woah.

Oh, this is, this is it's a delightful experience. I get I know you've only been there six months, but how how do those types of experiences

even, like how how do those types of ideas even come to people? Because No. It comes down it comes down to the product taste. So I think product taste is something that you need someone to teach you, to some extent. And, Raul is probably the person that has the most impressive product taste. So, like, he's doing every single product reviews and design reviews in the company. Kinda like the Brian Chesky of the world at Airbnb.

Like, it's kinda like a Vercel of that. I I don't want to enter, like, the founder mode, like, discussion. Like, it's a really great founder that we have and we we love him. But he has that. He always ask those questions. He always try to, understand, like, how far are you from getting to that wow moment? Like, how many steps to hit? And I've been here, like, only six months, and now I'm asking those questions. Now I'm looking at the the demo that my team now are doing. I'm like, feels clunky. Doesn't feel superhuman. Feels too complex. We need to do something, like this. So it's it's kinda like trained to some extent by being exposed to Rahul that has that, JS, I don't know if he learned it. It's a gift. But it's different. It's a gift. I think it is. I think it is.

But, like, the same way, I would say, when you work with someone that is just great, and you get mentor, then you see how they operate, you start to build a Vercel, and you start to build, I would say, that taste. It's kinda like drinking wine. Like, you drink, like, shitty wine at first. You start to, like, a better taste about it, and you meet someone that is just, like, great at explaining why it feels better. And you're like, oh, you're right. I see the food now. I or, like, I can feel the hook. Now you tell it. And then you build on it, and you become, like, more expert. But you need that first person to sort of, like, open your mind about those, like, different aspects.

And and that's a big part of it. Here's a product question. Will there ever be a true dark mode? In the app.

The dark mode, Wes, is one of the disappointingly, light gray dark modes in my mind.

So we call it carbon. We call it carbon. Yeah. But I I'm a dark mode user, and I'm complaining every freaking day.

I think that's the only thing I've ever submitted to feedback in the app Wes, can you get a real dark Node here?

No. No. No. So that that's that's very true. Like, it was, like, mostly, like, I Wes I made for, like, white and clear, like, mode for, like, a long time. And then we, basically, implemented the dark mode because of the request, but we didn't do it everywhere. And as we are not heavy on design systems, making those changes make that also takes time. And we Yarn we want to optimize locally. So, like, every single interaction needs to be thought through with dark mode now, like, in in mind. But, no. I'm with you. I'm with you. And you know what? Even worse, I'm an Android users, user. And Android is lagging behind iOS. So, like, for my team, I complain about, like, the two things that are lagging. So it's it's it's really bad. It's really bad. I I've noticed that, you know, the two main ways that you interact with superhuman are through the command palette and keyboard shortcuts, which are Wes, most of the keyboard shortcuts are just, like, one character.

So, like, you know, e or enter, you know, those types of things. Right? Like, I hit e and then immediately marks an email as done. And you kinda j and k, you kinda really get used to using the keyboard to navigate this thing. To me, these all feel like very, power usery type of even, like, like, programmer type of ways of interacting with an app. Do you see that, like, normal people are able to utilize these features effectively?

This is a great Wes, and this is a question we have internally because Wes, initial ICP, so, like, the ideal customer profile, was the, like, barrier or, like, by extension, like, tech industry funder.

So usually young, usually tech savvy, and highly productive and wanted to, like, say, gain some time. So those people were the the right target to get, like, keyboard shortcuts and everything. They were, like, looking for it and even, like, expecting it. It's more clicky, now JS we we were, like, more and more, present of the market. So basically, all startups Wes, yeah, I would say, and still are using, like, superhuman.

Those startups got acquired by by bigger groups, and you see those, like, c level of startups being acquired complaining, I would say, to the bigger group saying, like, Node. No. No. No. We wanna keep it. So now we have, like, big companies basically saying to us, hey, guys. We need to standardize in superhuman, but, like, not all the population is tech savvy like this.

What do you propose? And and that's something that, that is tricky, to some ESLint, but and this is where the I I was mentioning in the beginning, like, the PLG motion and the education motion is something that, is very important for us and and our success because even the people that are not that tech savvy, if you go through the basically, those, like, in product, education moments, you get used to it. And you're like, oh, damn. It's easy. Like, enter.

Anyone can do enter. And then you start with enter, and then maybe you start with, like, the e, which is archiving things. And like, oh, archiving works well. And maybe you use that one, and then you learn about the second one maybe, like, weeks later. So the pivot of the addition is might be, might be, like, a bit slower for the non tech savvy people. But eventually, like, the the speed at which you operate with those keyboard shortcuts is crazy. And it's interesting because there's a a lot of discussion about, like, the change of user interaction with devices and voice becoming more and more important. I still believe that keyboard shortcuts, like, would be, like, so much easier than voice, like, for, like, doing the archive for a while. Sure. Like and and things like this. So so, yes, we are talking about it.

Not yet to the point Wes we want to add, like, a lot of, like, you know, a ribbon. Like, I can't imagine having a ribbon with, like, a different actions for people that are very outlooky,

to to to some extent can feel that, oh, yeah. That's the same or close enough. So but that's a question we have. Correct? I do I I would see that the, like, more, like, voice type of thing would be very useful on on mobile, where you don't have access to that. Right? Although you do have swipes and and those types of things that that tend to fill that space. The keyboard shortcuts I use the most are archive, the up and down to to traverse them, and then the h to reschedule an email.

So, yeah, that one to me you know, Wes, you really liked Century's date selector Wes you could just, like, kind of type whatever you warp in. Yeah. This thing JS, like, next level. Yeah. Yeah. This thing is next level like that. You could say, you know, three days, 8AM. Next week, sometime, whatever. I mean, you can you can type in whatever the heck you want in this thing, and it it manages to

get your next Thursday, whatever. And it it just works. How does something like that work? So, like, the h one, for example, that's the one that I use the most. So h to basically, like, make your email disappear and only come back when you believe it will make sense. Good example is like, oh, I don't want to treat that today. I want to focus on this tomorrow.

So h t enter, boom, your email is Node. And the t for tomorrow, that's probably the one that I use the most. Like, next week, next month, or like, I would say today or tomorrow at 2PM.

So that's, obviously, the type of things that, I I use a lot because I want to reach Bos Deno. Wes, like, one thing, like, that is really key for our users is reaching inbox zero because you just get rid of the cognitive load. And when you reach that point where you have nothing, like, oh, everything has been treated. And you don't have to mark stuff and read because you you want to get to it at some point and everything, which is which is like the typical flow for like Gmail or Outlook.

It feels so great. And to do this, basically, you postpone stuff for to when it makes sense. So usually, like, oh, yeah. I know that I want three to three, like, those type of email on Friday. H f and Friday. Beam. It's done. And, one second, and it's ready. So you can go through, like, a 100 of emails a day, which is roughly said what I receive, this way into, like, the, like, fifteen minutes at the end of the day. It's pretty awesome. I don't want the audience to think this episode is a

No. Yeah. Sorry. Endorsement. No. No. You're you're fine. But I have found personally because I I when I get excited about things, folks, I I tend to, like, turn into a salesman for it, so I I apologize for that.

But I have found that I I hit inbox zeros just about every morning with this thing, and it's turned what I do in my daily ritual for email is that I tend to not look at email more than twice a day. I'll open up my email in the morning. I'll either get rid of things I need to do in another day or whatever, mark them as done, take care of everything I need to do, get to inbox zero, and then close out the email for the day. And I haven't found another system that allows me to do this as quickly primarily because just yeah. H t h t for the stuff I don't wanna do, today. I can take care of it tomorrow. And as somebody with, like, attention issues, treating your inbox as your to do list ends up becoming just like a really pleasant experience overall, which I I tend to hate email. So yeah. I I Everyone hates email. Everyone hates email.

So so that's a good one. And interestingly, maybe like the the last plug, I would say, for superhuman. But, what we see is in the, I would say, our customer base is like this. Save, like, four hours a week.

So it doesn't apply to I would say, if you're a typical engineer, with, like, in a in a big team, so you don't manage third parties, you don't manage a board, you don't manage, like, a lot of people, you will be probably living your life in Slack way more than, hopefully, in in Slack and not in teams or like any other one. So that might not apply. But when you start to be like in leadership roles or your role, maybe you are like you're a freelancer and you spend, Pnpm would say, a lot of time in emails, night and day. So, like, four hours a week, this is typically what people save, and they reply usually, like, 48 faster, than before.

So that's the type of, like, metric that we have, and some people are crazy, I would say. That there's, like, a a wide range of people within that, but, like, that's the average.

I think one of the big takeaways I have from Superhuman in general is that, like, you all have made a technical choice based on, you know, company wide philosophies of it it being fast in quality. Right? And and you made your check technical choices to align with that, to use local data. And through that, you've created a a product that, delights people.

It is fast as hell, and Vercel, like, really feels good to use. And I I I've been talking a lot about local data on this show, and I I think that's an like, an important thing is that oftentimes we think about, well, I'll use local data. But, like, you you all started with the experience, what need experience needs to be there, and then that probably determined to use

the local data and then the keyboard shortcuts and all these things. And it really, really, I think worked out in a great way for you all. So But it has a cost. Like, one thing that is really important for people to understand, like, if you're starting your company, and this has, like, a freaking cost. Like, you need to basically understand that, delight and, like, that speed is something that is an investment.

We are native, mostly for iOS and Android for that purpose. Being native JS a cost, we could have used Flutter or whatever, like, or the framework to basically build once and and use everywhere.

We decided to be, like, a very intentional.

We, I would say, are local first. So you were talking about, like, sync engines. Like, syncing is probably, like, the number Node, not pain, but, like, channels that we have that is tricky because you have network, no network. So you have someone like a pub sub, like, mechanism on every single device pnpm every single platform that we are using. But that's typically business logic that you would typically provide and only once in your back end, or your back end for front end, like, whatever the the architecture that you're following. But typically, in a b to b SaaS company that doesn't care about speed, you would manage that there and manage, like, the pub serve back on the back end. But we want to be offline first. So you need to have that approach on the local device. It has a cost. Every time we want to do some modification about syncing, so you are talking about calendar.

And I've got one, I would say, feature of all our users. Like, they are bring us calendar the same way you save email, and and we are working on it. But Wes it means that on every single device, we need to kind of, like, adapt our we're, like, syncing engine for managing, like, the different events to, say, work with the API of Mhmm. Outlook and and Gmail. So it has a cost. It has a cost. But we do believe that, this cost is worth it because I mean, we have, like, our users, they love the product, and they don't go elsewhere because the experience is so great.

So, again, it's different business strategy. The business strategy here was a a bit like Apple. We might not be the first.

Well, we'll be a close second, but we will be the best. So it has a cost. It has a cost. Your sync engine, is that all custom stuff, or is that being done through Realm? So the the the storage capacity JS, like, through Realm, but, like, we have this concept of modifiers.

So it's roughly said a PubSub mechanism.

So when we want to archive an email.

So we have a modifier that we basically log, like, every single stuff that you're doing on that email. Archive, unarchived, archived, unarchived if you want to play with it. On top of it, we have, like, the undo capacity. Like, we give you, like, ten seconds because, oh, Scott. I made a typo, a typo, and I didn't choose AI to rewrite my email. No. No. No. No. No. Z, so that you don't send the email. So, like, you need to have, like, basically, like, a stack of actions, that you can go through, And we want to implement that offline. So it needs to be present on every single device.

So we call that modifier, and it's roughly said like a a stack of actions that will be synced. I would say, as soon as you have the network, it will be synced with the back end that implements also those modifiers and will then implement the changes in Gmail or in Outlook.

Well, it's, it needs to happen.

Awesome. Yeah. This is so fascinating as a, one, a fan of local data stuff, and two, as a big time user of this app. I I sincerely appreciate all the time you've taken to to break this down for us. Yeah. And maybe, like, you want Node interesting things like our front end engineers and, like, JavaScript engineers. We have two kind of engineers, like, people working on the

UX and the people working what on what we call the background, which is kind of like the back end of the local stacks. And, we have, like, a a platform team that is usually treating those, like, nitty gritty, almost like back end problems on the device, because it's I mean, you you face, like, the same race conditions, the same, like, eventual consistency of shit that you sorry. This time I said it. Yes. Like, that you have typically on the back end, which is not typically common for, like, JavaScript users unless you're using Node on the back end, but, we are Goshawk.

Sick. Wes, do you have anything else you wanna get to here?

No. I I think that's good. I was I I was specifically going to ask about that of, like like, the logic layer and the UI layer, but you pretty much just answered it. So that's really interesting when it's when most of the code runs on the device, there's not really a back end. Right? So that was really neat to hear.

No. The the back our back end is, lightweight to some, to some extent Yeah. Compared to the the number of, like, emails we are we are managing. But, like, the the back end on the device is pretty extensive. What code do you run on your servers? So it's Go.

We are a GCP shop.

Everything is running on GCP.

We have a, like, small cluster, running on the GKE, which is like the, managed Kubernetes, platform. We use Postgres.

There's some, I would say, Redis, here and there for caching.

And, the pubsub is like the I would say that the pubsub from, from Google, there. So pretty, pretty lightweight.

I think we have something like four or five, I I wouldn't say, like, services, but, like, we have one monolith.

So it's mostly like a module, architecture to some extent on the back end. So here here's a question.

Last week, Google went down for a couple hours, and it took CloudFlare down with it as well. Correct. Did you have downtime? And what did that look like for your app?

Yeah. So this is a great question. So we are offline first. Yeah. So which means that during that outage, the only problem that you had was that we couldn't receive new emails because, like, Google was basically down. So, like, Gmail was downish. So receiving new emails was not possible. But we stuck everything. So we had to replay transparent for our user. They send emails. Like, everything that is email answering, email sending, and all of that, totally transparent because it's managed locally. And then it's like, going to our back end when they have the network.

And the the back end is kinda like replaying everything. So we had like a a long stack of emails that we're waiting for the outage to be done and tack, tack, tack, tack, tack, tack. We basically managed, we managed that. We had some issues because of the attachment, and there were some issues with attachment because, like, we had the one bug. So it was like Yarn not an incident. Like, it was an incident internally, but, like, not seen by our Wes users. Wow. So we're used to it. Like, your Outlook, like, their, graph API tends to break every new version because they are I don't know what Yarn doing, but, like, they they break stuff, relatively often.

But the kids mostly not seen, on on our side. So the only impact is, like, you will have, like, a small notification. Hey. G Gmail is facing some issues, but that that's about it. That's about it. Alright. I think that's all for today. Anything else you wanna add before we wrap this sucker up? No. No. Thanks for having me. That was super cool, guys. Great discussions, and,

always great to to talk about, like, tech stuff. Yeah. I appreciate it. Well, thank you so much for coming on, and, appreciate all your time. Thanks, guys. Uh-huh. Peace. Thank you.