Transcript from Thursday June 6th, 2019
Conrad Irwin, Co-founder & CTO of Superhuman, an Email Client Built with React/Electron
# Q: Probably a basic question – what made you choose to use Electron instead of other desktop options? – yeehaw
A: Good question. We actually started with node-webkit, but found that we were one of the largest consumers of it, and ran into many issues.
Electron had a much larger community, and so we switched over — everyone else has fixed most of the problems already.
# Q: How did you build your team? Finding lots of talented React+UI people is difficult, especially in the bay area. – burtonator
A: Various ways — team-building is definitely a slow process. We've hired people I met at conferences, through AngelList/Hired etc. and through a bunch of meetups we've run at the Superhuman office.
# Q: What are some of your favorite chrome extensions? – dpalazz
A: I used a few, I have a love-hate relationship with BetterGithub and Vimium so would recommend you try them but they're quite opinionated.
# Q: What would you offer as a suggestion to people when learning electron? – Fiery Raven
A: I think they have a create-electron-app. When we were starting out we already had a web-app so getting the web-app to load was the first thing; then after that it was a lot of googling to try and find how to do all the native stuff.
One of my favourite things you can do is fully transparent windows so Superhuman looks amazing on inbox zero:
# Q: Mobile apps must be important for an email app company (or if not now will be soon). Is there any commonality between the desktop and mobile code base? Did that factor into your decision? – Just Lurking
A: Mobile apps are very important. Email is read mostly on the phone (but written mostly on desktop, which is why we started there) — we have some shared code in js, and some shared logic that we hand-recoded in C++ for email parsing; but otherwise the clients are distinct. The UI for phones and desktops is very different, so there's very little common UI code.
# Q: What are you going to do about native mobile apps? Are you going to do a PWA or implement native Android/iOS?– burtonator
A: We're still deciding for Android, it may be react-native, Swift or Kotlin — we're about to start building out that team, so it will depend a lot on the strengths of who we hire.
# Q: – Given your Swift comment, does that imply the app is built with React Native? If so – how do you go about leveraging React Native versus native code to ensure that all of your actions (screen changes, animations, et al) are below that 100ms threshold? (If this question even makes sense 😄) – yeehaw
# Q: Do you offer any trial period for Superhuman? Thinking of buying the subscription but without testing I can't know if this is worth it! Or maybe to rephrase what are the killer features of Superhuman i won't be able to be without once i get used to it! – oorestisime
A: There's no trial period yet. We've designed Superhuman to work well for some users, but the switching costs are high; so we invite people to a screenshare as part of the onboarding. We haven't yet found a way to scale the hands-on approach to trials, but it's something we want to explore.
# Q: As someone who has looked up to the little guys in programming history what would you say is a way to start a company based on an idea? – Fiery Raven
A: My favourite book on this is "the art of game design", you should prototype, talk to people, and repeat with ever more detailed prototypes until you have a product 😃.
# Q: Did you ever face scalability issues? If yes how did you solve it? Also suggest best way to Deploy react apps. – Cypher
A: Scalability, yes — for now we just pay Google Cloud more, but we're hiring to work on that specifically. Deployment is pretty simple — we use a CI server to run the tests, and then upload to Google Cloud Storage with versioned urls. The harder part is doing app updates and making the app work offline, but service workers get a lot of the way there.
# Q: How do you do the screensharing as part of the onboarding? – burtonator
A: Mostly using Zoom, as that has support for iPhone screenshare too.
# Q: As a woman in tech, I try to always ask about what companies are doing to attract more women in the field. I would love to hear about what Superhuman is doing and what women in tech can do to be more attractive candidates for your type of company. – dpalazz
A: We do several things to try and make us more attractive to candidates; from promoting the awesome women we have internally, and running job specs through gendered language detectors, to internal discussion on how to keep improving.
(re awesome women internally, Emuye Reynolds runs mobile engineering: https://women2.com/2018/08/02/she-helped-invent-apple-tv-now-shes-reinventing-email-at-superhuman/ )
To the second half of your question, I'm not sure. It's hard to speak for all companies, but we try and look for people with potential regardless of gender (that said, we deliberately bias to meeting more women, because that seems like one way we can help avoid any issues with how profiles come across).
# Q: Are you open to discussing non-technical questions on this chat? Curious about your prioritization process for new subscribers, specifically AFTER the referral. On social media some folks seem to get scheduled right away and some languish for weeks or months.
Some enthusiastic users on Twitter seem to offer to refer anyone, do you depriorititize those referrals because they aren't personal connections? Or is it simply a bizdev decision, focusing on users with most revenue or positive press potential? – Just Lurking
A: I can answer that part: at this point, we prioritize people for whom we know the product will be a good fit due to their existing workflows and tools. E.g., Superhuman is not great on Windows and we don't have an Android app yet, so it doesn't make sense for us to onboard these people yet.
# Q: As an addendum to dpalazz' question – I've just read about the accomplishments of people on your team, the profile of your investors, and overall – the refreshingly inclusive approach it seems you take to hiring!
As a junior developer – how do I make sure I'm one of the first to know about relevant positions with you all 😛. – yeehaw
A: You can always email me 😃 firstname.lastname@example.org. For companies like us we advertize across AngelList, LinkedIn, etc. and most of the active platforms; even if you're not actively looking being around there may give you a sense of what's available
A: It's a long story, but to summarize, Rahul and I have been working on and off since I graduated; the first company we collaborated on was Rapportive — a tool to make Gmail better by replacing the ads with contextual information. Rapportive was acquired by LinkedIn where we built a similar tool for the iPhone email client.
We went our separate ways for a few years, and then in 2015 we realized that two things were still true: 1. people spend too much time in email, 2. Gmail was not serving the email power-users. So we started Superhuman on the premise of "make people brilliant at what they do" and for the first problem to tackle, chose email. : (based partly on our experience in the space, partly on the total number of people who email ~3Bn, and partly on the frequency with which people we knew complained about email).
It all started in 1971 when the first email was sent 😄
# Q: @Timothee Do you consider onboarding Android users who don't do much email on mobile? I'm guessing some folks would be fine with desktop and then falling back occasionally to the GMail mobile app. – Just Lurking
A: We do to some extent if they're insistent that they'll be fine. But it's tricky when you need both platform to really leverage the value. Not many people only use one platform (cross-platform features like read receipts, snippets, drafts, etc.).
Follow-up: Makes sense, thank you. Android ETA 2020 at this point or could it be earlier?
Yeah likely 2020.
# Q: So if I am correct you only can connect it to Gmail, there is no option like in Rainloop to connect to an manual SMTP server? – MrHpower
A: Not yet — we made that decision to reduce build time, as Gmail has everything in JSON over HTTP.
At LinkedIn I did a lot of work with IMAP and SMTP, and they're fine, but awkward (from the days before JSON/XML, so each command has its own parser rules, and sometimes even character encoding can change on the fly).
With the Gmail API we can connect from the web client with no proxy required which is also nice.
# Q: What information from your customers email do you store on your servers? How do you guys tackle privacy concerns? – pierre
A: Good question. The short answer is incoming emails are not stored, outgoing emails you send through Superhuman are stored until they are sent and then deleted. We have a send queue to provide features that are not available over the Gmail API.
We work with a good law firm to ensure we're up to snuff on privacy, and a good security auditor for the security side of things 😃.
Everything potentially sensitive is stored encrypted of course.
# Q: Following up on the no proxy required, can you discuss your security / privacy architecture? How much access to a user's email do you have by design? Email obviously very sensitive. Via password reset access to a user's email often can provide "keys to the kingdom" for other sensitive apps (setting aside 2FA). Sorry somewhat of a repeat. – Just Lurking
A: No worries — it's a question we get a lot
To make Superhuman work we have to store encrypted refresh tokens on our servers, which as you say are the keys to the kingdom.
A lot of our security and risk analysis focuses on protecting both the database and the encryption keys for those.
(We don't have passwords, luckily!)
# Q: What kind of iteration did you have to do before you got a product that fit well for users? – vcarl
A: Great question — as a company we're relatively intentional about the things we build, and quite metrics driven.
So we wanted to find a way of measuring how well Superhuman was working for users.
My co-founder actually wrote up the approach here: https://firstround.com/review/how-superhuman-built-an-engine-to-find-product-market-fit/
The biggest surprise to me was how long it takes to build something truly amazing.
# Q: Thanks. Have you had time to build in internal controls and monitoring so e.g. a rogue employee couldn't get away with murder in addition to the obvious focus on external threats? – Just Lurking
A: Yup — any employee access to potentially sensitive data is cross-posted to slack (in addition to Google cloud audit logs).
# Q: What do your dev teams look like (designer/devs/prod mgr)? What are you super proud of about your development process? – dpalazz
A: Right now we have two teams, desktop (5 people, incl me) and mobile (4 people, incl Emuye), and one designer — we're actively hiring our first PM (Rahul the CEO has historically done that).
The process is mostly weekly sprints pushing ideas through a cycle of "product design -> product review -> architecture design -> architecture review -> code -> code review".
Depending on how big the feature is how quickly that happens and some phases might be skipped.
I think the bit of our development process I love the most right now is CI and deploys.
Grant who's on the team just built a parallelization framework so we can run the tests in about 15 seconds (down from about 15 minutes) using lambda; and once the tests pass master is auto-deployed to canary for 24 hours and then to production.
One thing I've really enjoyed in terms of our dev process recently is Zen, a test runner that a coworker wrote that made writing and fixing tests quite nice and enjoyable (ah, Conrad beat me to it, because my n key doesn't work 😃).
# Q: Have you ever been scammed? – TheOriginalAse
A: In small ways, yes — people sneak into the product through friends without telling us, nothing major yet.
# Q: Do you think that electron is going to work long term? I've worked a lot with electron, really like it from the development side but the RAM usage and a few other things have made me hesitant. – Hum4n01d
RAM usage is an issue though, we have a bug in Github about it (and CPU usage too...).
I think it's that + DOM + JS — the trade-off for us is that we can re-use a codebase that's been improved for a few years, and anything we do to make it fast on the web makes it faster on native.
So until we're a much larger team, that advantage is likely key.
We have customers who want Superhuman in Chrome, because that's where they spend the rest of their time, others prefer not to to separate tasks. Having that Electron layer is really great to update both platform at once.
# Q: Not sure if it's been asked but do you guys use any UI toolkits like bootstrap or evergreen or material UI? – burtonator
A: Not been asked yet. Mostly we built from scratch, we use something similar to BEM for CSS syntax; but all of the UI paradigms are hand-tweaked. We really wanted Superhuman to look and feel premium, and have high information density; most current style frameworks don't push those directions super well.
AFAI'm concerned, I've found CSS frameworks like Bootstrap fantastic to start fast but cumbersome to maintain in the long run.
# Q: Not sure if you can discuss, but are there plans to go more mass-market? Maybe a lower price for fewer features and you don't get the personal onboarding, things like that? – Just Lurking
A: The real answer is "we'll find out as we go", but the current plan is to keep scaling based on onboardings for a bit — it works extremely well for the metrics we care about (Net promoter score, friends referred, perceived product quality).
We'd rather build a sustainable company that focuses on building out things that people value than "growth at all costs".
# Q: Do you guys have any designer on site? How does the process goes at this early on your startup, from idea to production? – pierre
A: We do!
We currently use figma for designs, and then do a design review.
One of the fun things we do as a company is friday wins where everyone demos what they did that week.
Teresa normally walks us through the designs.
Once we have everything pixel perfect in Figma we'll build it out in the product — and measure it down to the half-pixel to be sure 😄.
A lot of it is integrated with the product process I described above.
The ideas come from lots of places, what we want to do, what users are telling us (we have a great dashboard with all user feedback we've received).
# Q: UI is interesting. What approach have you taken with fonts and text legibility? Oh and is your app multi monitor friendly? – Just Lurking
A: To be honest the approach has been "start with not enough contrast, and bump it up and up and up".
We also try and detect what monitor you're using, and we bump up the contrast on non-retina displays as they tend to have worse contrast.
We also have a dark theme for people who struggle with reading on a light background.
Multi-monitor works, not sure if you were driving at something specific?
One thing that's very apparent in the product is our trying hard to not show things that aren't necessary. That helps with clarifying what's important and thus legibility.
Follow up: No I've just found some non native apps don't work as well on multi monitors. Alerts pop up on wrong screen, app won't stay on designated monitor, stuff like that.
We should get you on a free trial so you can help us find the bugs 😄.
# Q: Interesting. Do you standardize incoming emails into the same font? – Just Lurking
A: To some extent — one of the few things that's shared between the two clients is the heuristics around "should we render this email as a person-to-person conversation and strip out formatting that looks unintentional".
For some emails that seem like marketing we leave them alone.
But usually when you send an email with one line slightly the wrong font size, or color, that was a mistake.
And we want emails to look good in Superhuman.
# Q: Do you guys have a design system internally? If yes, how far down the process did you guys decide that would be worth to invest on it. – pierre
A: We don't yet, but it's something we've talked about. We have a few guidelines and a lot of bespoke UI.
As we build out more and more of the product, things begin to get more similar, e.g. we have a standard way of doing dialogs now which we never used to do.
But a lot of the UI is single-purpose, rendering an email is not going to be reused in a different part of the app 😃.