Software Huddle - Why Building an API for Email is Hard with Christine Spang

Episode Date: May 15, 2024

Today, on the show we have Christine Spang, Co-founder and CTO of Nylas. Christine was the keynote at the recent Shift Developer Conference in Miami, and we caught up with her there. Nylas is a unified API for email, calendar, and contacts. We talked to Christine about why she started Nylas, and the challenges with building an API for email. Email is this massive distributed system with a very diverse set of implementations, it's a super gnarly ecosystem going back decades. It's generally not something you want to spend a lot of time on if you don't have to. Christine was a lot of fun to have on the show. Follow Christine: https://twitter.com/spang Follow Sean: https://twitter.com/seanfalconer Follow Alex: https://twitter.com/alexbdebrie Nylas: https://www.nylas.com/ Software Huddle ⤵︎ X: https://twitter.com/SoftwareHuddle Substack: https://softwarehuddle.substack.com

Hey folks, Sean here, and today we have Christine Spang, co-founder and CTO of Nylas on the show. Christine was the keynote at the recent Shift Developer Conference in Miami, and we caught up with her there. Nylas is a unified API for email, calendar, and contacts. We talked to Christine about why she started Nylas and the challenges with building an API for email. Email is this massive distributed system with a very diverse set of implementations. And having written an email parser myself in the past, it's a super gnarly ecosystem going back decades. It's generally not something you want to spend a lot of time on if you don't have to.

Christine was a lot of fun to have on the show. We probably could have talked to her for hours. One last thing before I kick this over the interview is if you're watching the video version, we did unfortunately lose the last few minutes of the video content. The audio is all intact, so you'll hear the end of the show, but you won't see the camera feed as we wrap things up. Sorry about that. We tried very hard to avoid something like this, but technical glitches sometimes happen when you're recording on the road like this. Anyway, let's get you over to the interview. Christine, welcome to Software Huddle. Hey, it's great to be here.

Yeah, as we were chatting beforehand, as we were getting set up here, I'm from Canada. You're also from Canada. I also was a CTO and co-founder of a company that also did a lot of stuff with email. Not completely unrelated to what you guys are doing, but I feel like we have some commonality. Battle scars. Yeah, battle scars, I'm sure. And now we're here at Shift Conference in Miami, so there's a lot of commonalities there. But I'd love to get to start off, just get a little bit about your background and what led you to starting Nihilus. Yeah, for sure.

So, as you mentioned mentioned i was born in toronto but i actually didn't grow up in toronto my family moved to upstate new york when i was three and a half so secret canadian mostly american we'll still claim you yeah my my canadian like childhood friends we would like go back and visit um every spring break for a while and they would make fun of my upstate New York accents hardcore like when I would say sorry instead of sorry could not get not teased about that and that kind of thing so I have the passport but pretty much not much else. My family is Canadian. But so I grew up in upstate New York, and I think sort of how I ended up starting a company. So I always kind of, I knew I wanted to build stuff when I was growing up, do some sort of engineering.

My dad's an electrical engineer. My grandpa was actually a chemical engineer who got into electrical engineering later in life because I guess he kind of got bored of chemical engineering and wanted to do something else. So I had all these great sort of engineering role models around me, but I didn't really have the concept of wanting to get into software until I was in high school. And I was really into medieval fantasy books. Yeah, I hear you. See, now you're speaking my language. Should we nerd out about some little Lord of the Rings?

But I got so into this stuff, and I was a voracious reader and eventually I discovered computers and I got into these text-based role-playing games called MUDs and so I actually started I got so into playing this Lord of the Rings themed MUD that I started helping run it and then I wanted to learn to code so I could change things in the game and so it only ran on Linux and so I had to like my my uncle was a software person who did Linux and so I had to install Linux and that sort of let me let me to discover the open source software world where I just thought it was so cool um people all over the world mostly volunteers in their spare time at the time it wasn't quite as commercial a world back in the sort of early 2000s

um but i was just amazed that you know people could collaborate mostly asynchronously and like produce something that worked and that like powered of the internet. Yeah, it's actually pretty unbelievable when you start to think about it. It's crazy. So I was super inspired by that and sort of as a side thing from trying to work on the game, I got kind of nerd sniped into learning about this flavor of Linux called Debian. So I started contributing to Debian when I was in high school and then pretty much decided I wanted to get into software

and applied to a bunch of colleges. And the one that was like my super secret stretch school was MIT. And I was really excited about MIT because of the movie Good Will Hunting. Yes. It was like a hilarious growing up story of like, how did you choose where you wanted to go to college? Well, I saw this movie. And free software is from there. So I think that was really a differentiator for me, kind of getting into college,

not just having good grades, but having this um you know passion for for yeah i mean you have like artifacts where you're actually contributing yeah so i went to mit and then um there was kind of this culture a bit of entrepreneurship there and uh i honestly didn't really think that I was going to start a company until some folks that I knew from the computer club. Essentially, they started a company to commercialize the master's thesis of one of the members. So they had built this cool technology for Linux that essentially allowed you to take a source code patch and apply that update to a running Linux kernel without restarting it, which is pretty cool tech at the time. And so they had started a business to commercialize this technology. And it was kind of like the new hotness at MIT where everyone was really psyched about

this MIT spinoff startup because MIT was a school where all the hardcore nerds went, but it had less of a reputation for kind of creating businesses than, say, Stanford or Harvard, where there's sort of more of this hustling culture. MIT was more about the super hard tech. Yeah, you also have proximities to Stanford. You have GSP, their business school, Harvard, Harvard Business School. MIT has a business school too, you have like GSP, they're like business school, Harvard, you have Harvard Business School.

MIT has a business school too, but mostly we would just make fun of the business school kids. Like, oh, the Sloanies, those guys aren't real MIT people. So, you know, looking back, I honestly, I don't think that culture is that helpful. And I think sort of the practical side of, you know, bringing technology to the world and also kind of all the skills that you have to develop in order to do that well is actually really important. And I don't think people should dismiss it because it's not all, you know, about the hardcore technology. If you want to make an impact on people, you have to also get people to use your stuff. And there's tons of really great technology that never turns into good companies because the person who wrote the code can't make friends with someone who can sell it.

Yeah, I built a ton of stuff that I thought was very cool in my 20s that no one ever looked at because I had no idea. It was kind of just like, no one ever looked at because i had no idea it was kind of just like no they will come i have no idea like yeah that's not true at all like you have to sing it from the mountaintops and also um be able to talk to people in a way that makes it understandable and resonate with them so that they can see like what is this thing valuable for because a lot of time like new technologies um it's not like really obvious like what yeah what you would use it for and um even um even starting nilas back in the early days like our elevator pitch for like what the company did in the beginning it was like four hours long

people would be like wait so what do you do yeah just sit down for a minute yeah it's like uh at mit there's this building called the green building which is like 14 stories tall or something and then um if you were like training to climb a mountain what you do is just do laps in the staircase wearing like a backpack um so this elevator pitch was like the green building walk of elevators, which is to say you walked up and you were slow. Yeah. Do you enjoy the business part? Like, do you find you enjoy that part in addition to, like, understanding that it's important?

Sort of begrudgingly. I would say it's kind of like eating your vegetables. Where, like, for example, like, if I'm, like, giving a conference talk, I get nervous every single time. Yeah. And I kind of hate the week before it because I'm like stressed out about it. But then I like give the talk and actually love both the act of presenting and the conversations with people afterwards um but i think i just like i have like a bit of social anxiety that i haven't quite cured yet even though i i feel like i've been i've been training yeah like let's let's call it eight out of the last 10 years of like oh you gotta talk to people and i i love connecting

with people um but it's still like uh you have to to push through the pain and just exist in a state of discomfort to get to the good stuff. It is way nicer to go to a conference where you're speaking because you have a natural way to… Yeah, it takes care of some of the awkwardness of the intro part of it. or to introduce yourself to 50 or 5,000 people at the same time than it is to go and give your same little elevator pitch, here's me, here's what I do, here's what my company does, to individuals in sequence. Pick them off one by one. Yeah, I feel like I had a really hard time speaking in front of people originally,

and then I've conditioned myself to a point where I actually really enjoy it now. And I have no problem, you know, standing in front of a bunch of people. And I think I'm good in the context of like one-on-one. I think the place where I struggle is like the sort of networking cocktail situation where it's like small groups.

Yeah. Yeah. Socializing. I need, I need more reps. I don't have eight to 10 years on that. Yeah. I agree.

The great thing about like giving a talk or doing some sort of online podcast or writing is that then the people that are interested in the same things that you're interested in will come and find you. It's awesome. So if you want to skip the small talk, just you know put out there you know artifacts for what you care about and then people can kind of self-select and show up true yeah do you do a lot of speaking in a year like are you speaking it really varies um i would say i i go to at least like three to four conferences a year and then whatever whatever other stuff pops up so So Nihilist is this, you know, back to outside of presenting at conferences,

but your actual company, is this like unified, you know, modern API for email systems. So why build an API for email? Yeah, so, you know, where it really came from was I had this friend at MIT who, so you have to do like a thesis project in order to graduate. And he decided to build a, basically like a customized email client that pulled in your contact information and showed stuff side by side. And, you know, this was back in like 2012 where no one had really done that yet. And just sort of like watching him try to build,

a lot of things were surprisingly difficult that you wouldn't expect to be difficult. So this was actually back in the day, way before there was even any sort of REST API for any email provider. And the way that you connected to an email mailbox was by using this protocol called IMAP. Yeah. And if you don't know anything about IMAP, the things you want to know are like, one, it was designed for kind of the time sharing days where like, you know, you have this like huge mainframe computer and everybody dials into it. And like being online is like you're dialed into the time-sharing machine. And so there is this original assumption in the protocol that, like, the client is connected at all times. And then, like, all the functionality that was built after that for, like, disconnected operations was sort of bolted on to the protocol. So even sort of the concept of mail persisting across different connections

was a thing that wasn't a first-class citizen in the protocol, and also it wasn't designed for the web. It was designed for a sort of sticky client connection. And so you just have to do like a lot of weird stuff. You know, you have to hold a lot of state in the connection in order to essentially interface with the mailbox. And then email itself is even older than IMAP. So once you even, you know, have the connection to the mailbox and you can like list all the messages in it. Then you have to do stuff like, you know, fetch all the messages in a thread.

Threads actually weren't like a first, like when email came out, there was no such thing as a thread. It was just a message. And later we were like, wow, we kind of want to group messages where you're talking back and forth together. So, you know, people added a header

that allowed a client to figure out that these are the same sort of topic of conversation. So all that stuff is on top of things. And beyond that, so like you have, you know, all of the headers for a message, which can in some cases be like 60 or 80 percent or even like 90 percent of the message contents if it's like you know one sentence yeah it's literally like like you know a bunch of kilobytes of of message headers and then like you know three lines of of actual message um so there's this a lot of overhead and then um email is also really flexible in terms of the message payload especially when email first started, there actually wasn't even the concept of sort of non-ASCII characters. So that's also a thing where like in the headers, you have to sort of see like what character set is in the message in order to interpret it correctly.

And then there's this complicated system called MIME that allows you to essentially send attachments. But it also gives you sort of the capability to structure an email message as like a tree, essentially. And so an email client is actually like taking a tree and like flattening it and then deciding how to display it. So there's a lot of interpretation on the client side. There's also, you have plain text, rich text, HTML. So each part can not only be in a tree structure, but it can be

either HTML, like a webpage, or it can be plain text, or it can be a file attachment. And so there's actually quite a lot of complexity into just what a message looks like. And say if you're building a custom email client and you want to just sort of display the message, doing that's actually quite complicated, even if you have the ability to just make an API call and get the body payload.

So long story short, there was a lot of complication in doing simple things. And what I took away from that was just that, like, there's all this really valuable data inside email and that the data should really be connected to other applications because especially when it comes to business, email is kind of like the communication sort of record of truth. Like, people tell you, like, you know, don't put anything in your email

that you wouldn't want to have read out loud at a deposition in the case of, like, a court case. And, you know, the reason for that is because, like, the emails that a business sends are sort of like a part of the record of that company. And so it's not only things like customer communications, internal communications, but there's like, you know, contracts that are in there, you know,

less so on the consumer side these days for sort of like personal stuff, like photos and things, unless you're my family, in which case, you totally just send emails still where everybody else is like on WhatsApp or whatever. Yeah. I think a lot of personal communication has shifted off email yeah to more kind of chat based mediums yeah why do you think email still continued to thrive in businesses like what was like you know it's one of those systems been around for a really long time and it's like doesn't seem to be going anywhere but like when was the last like sort of innovation in email uh probably the last innovation i can think of is is when gmail essentially

released you know large inbox storage that really changed email yeah like when you didn't have to think about deleting stuff anymore because that's what enabled it to become this sort of system of record yeah the system of record where it's like just a giant pile of documents um and having kind of search as the the way that you retrieve stuff and find old stuff yeah i remember in the early days of email you would not only be constantly triaging your inbox to delete stuff but you'd also be categorizing your 10 megabyte storage like you're like oh i gotta like delete stuff, but you'd also be categorizing. Your 10 megabyte storage, you're like, oh, I've got to delete stuff and maybe take these photos and put them on a file system somewhere.

And then, yeah, like categorizing stuff, putting them in your little folder hierarchy so that you can find things. So I think Gmail was really the last paradigm shift when it came to email. And then obviously everybody copied the infinite storage piece. But other than that, like since then, it's all been very incremental. It's like, well, some email systems now will try to auto categorize stuff so that you can filter through the noise a lot. And other than that, it's like incremental user experience stuff. So what are some of your customers doing with that?

What problems are they trying to solve by using this approach? Yeah, so because, and just to go back to your previous question a little bit, I don't think I really answered it. The reason I think email is so sticky in business is like a couple different things. One is that it's the only sort of digital communication system that is both federated and also at its core an asynchronous medium. Like you can do async on a chat medium, but it's not really, there's like this whole like cultural piece on top that it's like, it's hard actually to communicate between like different instances of like sort of an

internal corporate thing like you know if I have my company slack I can connect that to other businesses through these shared channels and things like that but it's like funneling everything through this like one little connector and it doesn't feel very seamless whereas like with email you have you know your own custom domains so you know it feels very first class. You can have the flexibility to choose a different provider. Though it is the case that these days, the market share of Gmail and Microsoft is definitely far outpacing the long tail, at least in North America. It's actually different in different geographies of the world.

Like there's actually more sort of like ISP type providers in Europe. And then when you go to Asia, it's just like a whole different ballgame. Yeah. Like I'm curious in Asia because I feel like when it comes to Internet use, you can kind of divide the world into people where basically western artists world people's identity is defined by an email address and then for people who were essentially mobile first adopters of the internet their like identity is like a phone number where it's like you have whatsapp we chat all these types of services so is emails even something

that's driving business engagements in parts of APAC, or is it less, you know, they are essentially leveraging more of the phone-based systems? In Japan, people use email for everything. Like, instead of being on messengers, you just, like, use email. So I think it's very cultural in different parts of the world, and also even in sort of different subcultures. Like, if you talk to kind of Bay Area startup people, they'll be like, why would you care about anything but Gmail?

And then if you talk to like enterprise businesses, they'll be like, why would you care about anything but Outlook? And also like my server still runs like in the basement. Yeah, we have our own exchange server. Of like RHQ, you know, in Plano, Texas. So, you know, there's a lot uh heterogeneity in kind of the ecosystem and you know the the blessing and the curse of email is that all that infrastructure manages to talk to each other in a very reliable fashion um while not locking you into any one given vendor and I do think that's's something that corporations still care about. Right, yeah.

Are there a lot of quirks across Outlook and Gmail and specific things they have went for you when you're building on top of those? Yeah, for sure. There's core differences between Microsoft and Gmail. And so our API is a universal wrapper for all the email systems, all the calendar systems, all the contacts, address book systems out there. We unify the vast majority of things. For the couple things that we can't unify because it's different error messages and things like that that might be provider specific. We, you know, we document those really well and try to return something that just makes it obvious, like, what to do as a client.

But sort of conceptually, I would say one of the biggest differences between Outlook and Gmail is whether sort of categorization features is one-to-one or one-to-many. So Outlook still uses folder structures, and you can actually have nested folders. Whereas Gmail is all label-based, and you can have one message with many labels on it. It's more of a tagging type approach. Yeah, so that's kind of a big difference between the two. And then there's tons and tons of sort of little long-tail things. And one of the reasons that people come to Nylas is because none of this is rocket science. If you can go and read the manual, you can figure it out.

But all that takes time. And the people that are building on our platform, they don't want to care about email. That's not what their business does. What they're trying to do, and I guess this gets to your second question, is what they're trying to do is like pull all the context for some task together. So about 30% of our customers are various different flavors of what we call customer relationship management. The commonality there is that for actually lots of different roles, the core thing that you're doing in that role is communicating with a bunch of people in another group, whether that's customers or prospects or people you're trying to sell to. And you're trying to keep track of the state of that relationship. And then you're trying

to do the right thing to manage that relationship on a day-to-day basis. So you want to keep track of all the communication that's happened, things like emails, things like calls, things like meetings that were scheduled. And you need to have there be continuity, even if you leave the business. The next person that takes over that account wants to be able to have all the history as well. So you need the history of the interactions. And then people are also trying to kind of pull out sort of the essence of what's in those communications, whether that's sentiment or sort of structured information

that's within there, and automate workflows based off of all that data. So that's kind of like one category of what folks are trying to do with Nylas. We also have sort of a long tail of other use cases where, like, you know, people are, like, in real estate and actually email is this, like, huge part of how, like, the MLS or real estate system works. And so in some cases, people are actually trying to automate stuff that has email as a data source.

Yeah. I mean, if you look at a lot of stuff in HR, like applicant tracking systems and stuff like that, a lot of those are like you're receiving emails for CVs or resumes, applications, and then you need to be able to parse that information and put it into something. Yeah, we have a lot of recruiting companies. And it's interesting that even if you like think about like these one vertical or one sort of group of customers, like recruiting, there's actually like lots of different kinds of recruiting companies, whether that's people that are focused on a specific geography and their sort of cultural and language

and just sort of differences in how you'd build that business in that geography. Or they might have different target markets. So like some companies are targeting high volume recruiting where, you know, you're hiring like warehouse workers or something like that. And that's actually way different than for people who are hiring technology professionals. And so you think of, is CRM a really large market? And it's huge. There's like, even like within recruiting in HRr real estate sales marketing there's sort of a fractal of like

different focuses within that that can sustain thousands of businesses around the globe and each and every one of them needs to connect to these data sources and don't have time or will to do it themselves and then we also have a ton of customers who are just automating scheduling. Like everybody needs scheduling. And it's a pain. It's a big pain to build. So we actually have a part of a product that even provides sort of the UI components for that.

So you can just like plug in like an HTML component into your app, and then you don't have to build the UI for the calendar picker and the dates and then handling weird time zone stuff. Or we do group scheduling and things like that. So there's all sorts of complexity that comes with just kind of these specific workflows that people care about and so we're kind of like the lego block toolkit that allows people to just grab the piece that's the shape they want and then you know maybe add some modifiers and plug it into to their app and avoid spending a year with a team of six engineers building out that thing and then having to maintain it forever. Like a lot of customers, even if they have the capability to build a thing,

having to sort of resource that. And, you know, it's not just sort of the engineering bandwidth, but it's also the domain expertise. So, you know, companies get turnover and when you're building integrations, things like that, it tends to not be a really core part of the product experience. And so you don't have like the competition from all your best engineers of like, I really want to build the outlook integration for our product. Put me on the calendar. So you're never going to have your best people doing it and also like,

you know, maybe that person will be gone in three years and then you have to like train someone else up. Yeah, that one person that took the time

to read the manual right now. customer support issues come in and like you don't know what to do and we just sort of abstract that and we're like,

we're your domain experts. Just call us and we'll figure it out. What were some of the, like we talked talked about some of the challenges around, like, just the, I don't know, the, like, difficulty parsing emails, the different, the way that some of the protocols work and stuff, but, like, to actually design an API on top of that, were there design challenges because you're sort of limited by the medium that you're trying to you know design these apis for yeah um i mean like i think there's like a few

different things um one is that we try to figure out like what will give people patterns that they're used to. So, for example, our authentication wrapper implements the auth for all these different providers, but then it actually exposes just an OAuth-compatible API. So if you're using tools that implement OAuth or you've done OAuth before, you kind of already understand how it works. And that's like when you're building developer tools, the way that you can decrease the learning curve for whatever it is you're building is by fitting into expected patterns for the way things work and also making your product consistent across the board.

So like, you know, our calendar API works the same as the email API and the auth is the same. Right. So that way, if you learn one part of it yeah you can just sort of extrapolate to another part of the product and that just makes it a lot easier to learn across the board how do you handle some of the like sensitive nature of email like we were talking about like how you go and you work for a big company and they'll warn you as part of the onboarding like don't put anything you know certain things in you but people inevitably or even even if you're not putting something that's like, uh, like you don't want to show up in court, there's still a lot of sensitive material within email. Yeah. It's interesting. That's something that I would say

we had to solve that problem early on because, uh, it, it did come up a lot. Uh, now that we've solved it, it's sort of a solved problem. I don't think about it that much. And I guess the way that we sort of help people through this is like a few different things. One is just like having a great reputation and sort of set of like certifications for security for the product. So we went out and got kind of the standard enterprise security certifications for SOC 2 and ISO and kind of all those types of things pretty early on. Like nowadays there's all these companies that will help you deal with that compliance and we did it the hard way back in the day. But that's the kind of stuff that's very much table stakes for like selling to an enterprise

type company. But the flip side of that is that like, if you can sort of show the right things that help people trust you, it becomes a non-issue. Other things is like, we allow people to specify, you know, the permission set for what data they're asking for in their app. So Microsoft and Google both have granular permissions. I actually think that the granular permissions that are offered by the providers are actually not that granular. It's like email read only or email read write or calendar read only. So it's like the top level data types and then it's sort of your standard kind of CRUD type stuff. But one thing that I

actually really hope to have happen in the future is that, I guess the thing that I've learned is that, you know, for all these underlying data providers, you know, they have APIs. And the reason they have APIs is because they need to grant access to the data so that other people can, you know, integrate it with their apps. But they don't really have anybody at like Google or Microsoft who's like really deep diving into like, what are the kinds of things people are trying to build on top of our email api or on top of our calendar api it's more like you know if we've like exposed the data and made it accessible um and we like keep that reliable and up like people can go wild but like it's sort of not our problem my job here is done yeah Yeah, exactly. So they kind of like check the box and sort of move on.

And the thing about that is like, I actually think there's a lot of room to improve the security even more. Because, you know, think about an email mailbox. You have a lot of different sort of levers there. We actually also allow some control sort of on top of the base provider security scopes, like how far back in time you can go, things like that. And I think if you have a deeper knowledge of the applications and what people are doing with the data, you can actually sort of drill down into subsets of the applications and what people are doing with the data, you can actually sort of drill down into subsets of the data in a much more useful way.

And I hope that someday in the future we'll not just have like read-only access to my entire mailbox for the end of time. But say we have like a personal finance app that wants to connect to the mailbox to seamlessly import things that I've bought and match that with the line items on my credit card. So I don't have to do that, and everybody has AI algorithms for this, but they'll be much more accurate if you can actually get that receipt. What if that app could just connect to the receipts from my also sort of narrow down based off of sort of type classification and sort of AI system on top of the mailbox data, which we have the beginnings of that today. Like we can do sort of order parsing and receipt tracking, but we don't have like enough sort of category types and sort of a robust mailbox wide system to be able to use it reliably as like you get this

slice of data but not this other slice of data but I think it'd be really exciting to be able to do that because you know the number of apps that are connecting to these data sets is only increasing and like something bad is going to happen. Yeah, especially as like, I think companies start to also try to like suck in email as a data source for either like their analytics layer, like down into like a data lake or, you know, a warehouse or use some of that data to, as their like source of truth to power like LLM training or like a rag model or something like that. Like, you know, you might want to use some of that data, but you don't necessarily want to give sort of cart launch read access to the

CEO's email. And I think we're really seeing this explosion of interest in a lot of different types of data because obviously like with LLMs and kind of the new sort of Renaissance in AI technology, all of that is about the data at the end of the day. It's like programming with data. And the model is actually, you know, like somebody builds the base for the model,

but like the actually really important and interesting thing is like what data are you feeding into it? Because every company out there is not like building their own base models or algorithms. Yeah, very few. But most of them have or should be trying to make use of the specific and custom data that they have that allows them to better customize and personalize and sort of drive insights and actions in their software that is based off of that data. So, you know, I think that we're going to, there's sort of like this arc of technology progress where, you know, I think it's always the case that like people figure out the use cases before they figure

out like, how do we do this in like the best most secure way um you can even see that with like email or the internet or whatever like you know we had mosaic and like all of the open papers on the web before you even had any way to encrypt uh access to a web page yeah well it's years later yeah yeah so like the sort of nice right way to do it is not it's not obvious when you're still trying to figure out like, what is the what? Yeah. So I think we're going to see this kind of explosion and renaissance of like connecting data to systems in different ways.

And then it'll become more obvious both in terms of like the progression of the technology and then like how that maps to the use cases of like, how can we do this in a way that like best protects people and makes it clear like what is happening with their data? Because like right now, like customers on our platform are actually really mindful of this because they're all business users and some of the providers do require that, you know, you sort of lay out, what are we doing with the data? But this is the kind of stuff that's like in their terms of service.

And even with the current sort of data regulations in place today, like you could get sued for a lot of money for misusing data. So people do try to be transparent about what is happening, but it's still, it's like buried, you know, in like a 10 page terms of service. So, you know, I think we're kind of still at the beginning of what it's going to look like in five years. But I think it's really exciting that people are able to personalize their tools better and also um just having that sort of custom data being uh filled

into the tools makes them a lot more powerful at the end of the day and it makes like everybody wants their tools to be personalized and powerful um they just don't want it to be done in like a way that feels creepy um it's like when i go to, even when I go to Google, like I don't want to see ads that are for stuff that I don't care about. I actually love, most of the time I love the ads on Instagram because there's stuff I like. It drives a lot of sales. The targeting is good. Yeah.

I mean, I think marketing is done right and actually matches sort of like the the person to like what you care about like it doesn't bother people it's when there's a mismatch and it feels like inauthentic or like an annoyance that people get upset yeah like you know if someone's reaching out to me about a thing that i actually care about or i want or it's relevant to me like i don't mind that. But it's when it's like, you know, hi, like, whatever, something that's not my name. Hi, bracket, first name. Do you want to buy some, like, fancy golf clubs or something? I'm like, I don't know, you got the wrong person. Don't bother me.

So, like, I assume, like, a lot of your customers are essentially, they're using, like, the essentially using the API as part of their core infrastructure because they're basically building applications on top of that. So how do you work on meeting some of their scale and SAL requirements? What does the infrastructure look like? Yeah, for sure. I mean, for a lot of our customers, we're in kind of their top five infrastructure vendors. So it'll be like, you know, AWS or GCP or Azure and then Austin, maybe one or two other vendors. So we take that really seriously.

You know, we have obviously like a dedicated infrastructure team with SLAs and all our stuff. We actually just launched a new version of our API. V3. Now it's API V3, which is all Kubernetes from the ground up and auto-scaling. And it really represented a big leap forward in terms of the reliability that we could promise for folks. Is it all offered as a SaaS or can people run Nylas themselves if they want to? We don't have an on-prem offering these days.

We can run people on a single tenant instance if they're large enough scale and they really care about that. It usually comes down to, like, what people want to deal with in terms of, like, cost and their own sort of internal security requirements. We have experimented with, like, a true on-prem offering at various points. And I think just, like, there's not enough value add from that to like it's a lot of extra uh it's a lot of extra work both for us and for the customers for sure because you then have to like learn how to like operate this thing that you didn't build yeah which um is typically difficult yeah it's bad enough to operate the stuff you did build you know, you want my team of SREs getting the pages and not yours. Yeah, so the company's been around for seven, eight years around that, right?

Ten actually. Oh, ten, okay. So, yeah. There was sort of like two phases to the company. We probably spent the first four years just trying to find product market fit. We did build the APIs as one of the first things, but we built this actually desktop email client at one point, and that was a terrible business. So we ended up going back to the infrastructure, but it's really from about 2017 to today that we've been 100% focused on the infrastructure business and growing that, scaling that. We've learned a lot about what are the things that people have succeeded at using us for. And at this point, we know enough about the kinds

of places where it makes a lot of sense to use us to go out and knock on people's doors when they sort of fit the profile as well. In terms of like how it all works are they are you just like are people giving you IMAP or PUP3 or whatever to their accounts and it's like forwarding all emails to you and you're basically indexing them and storing them like are you storing a full copy of their their inboxes, essentially? We used to on our V2 platform. The reason for that, actually, was because, really, of IMAP back in the day. It was hard to essentially retrofit a REST API onto a fully IMAP backend with things like having to have sticky connections and stuff like that.

So the first version, and I guess the second version too, of the platform did do a lot of caching. And basically every piece of data we served in the API was something that was stored on one of our systems. That's not the case with v3 because with the native provider APIs from Microsoft and Google, we can actually streamline a lot of that where we can eliminate the sort of syncing phase of having to sort of pre-process the data in an async fashion and have our data store be up to date in order to be able to serve the data. Whereas by, when we can sort of fetching and transforming the data on the fly is actually, it's kind of

better for everybody because it's always up to date. If you get a response, you know, you know, that's like what's on the provider. There's no room for any sort of sync lag um which can lead to confusing sort of ui stuff um and then we're actually able to innovate a lot on kind of the imap side of things as well and um we we no longer store like a full mailbox copy for that. We kind of pre-process it for search and do kind of like a metadata type experience there because you have to store more data for those protocols just because it's not easy to translate it to a REST API. And then we support on-premise Microsoft servers as well,

which uses this protocol called Exchange Web Services, which is SOAP. Yeah, the Microsoft ones are just all XML. Before EWS, there was a different XML protocol that actually the transfer was binary encoded. Windows B binary XML, which was designed for, like, the BlackBerry mobile phone days. Or where, like, I really need to, like, save these bytes for, like,

my low-speed data connection. Do you still, like still have support for that? Is that still used anywhere in the wild? Or is it like now nothing's using it so you could rip out support for it? I wish. Unfortunately, Microsoft has been pushing for all of their customers to move to the cloud.

But people still use it. And in fact, for our customers, the more kind of enterprise-y they are, the more they tend to have, like, not necessarily like a high volume of customers in mailboxes that use the on-prem exchange stuff, but those customers tend to be paying them a lot of money and very important. So we don't want to be in the place where like we are, are, are pestering our customers,

customers to like go modern. So unfortunately it's like a thing that we have to support. We want to continue supporting as long as people are out there using it. Probably a good moat too now that you've built it, you know, like other people want to go build that. Yeah. Nobody wants to build that.

But I think it's going to be around for the next five or ten years. Where do you end up like running into actual scale issues? Like is it on the data side or, you know, compute? Like where's sort of the bottleneck end up happening? Yeah, on the V2 platform I would say was definitely entire well the biggest bottleneck was on data we had like you know petabyte plus of just like compressed mailbox data. Yeah there's a lot of unstructured or semi structured data I guess. Yeah and then actually kind of the compute side is pretty significant as well just

pre-processing all that data um i don't actually have like stats off the top of my head of like what the biggest stuff is on v3 um we definitely store less data which um our customers actually really like because um it really enhances the sort of security story where you don't have to say, you don't have to convince your customers that like both you should trust me and you should trust like3 webhook system will just sort of send you the entire payloads of the data that you care about as you subscribe to triggers for you know whatever objects you're you're working with and then we'll just send you the updates and then like we don't keep it it's yours it's yours now and there's even some customers where we will sort of push that data into like a pub sub or sort of like a streaming type system on the customer side if they prefer not to get pushed to and they want to sort of consume a stream at their own pace.

So I bet it's a little more compute than with the new raw data storage but also just like network bandwidth like a lot of data is passing through the system a lot of network calls yeah and then you have to manage like connection limits and rate limiting and just sort of managing all those different parts of like how you scale up. There's always more complexity sort of behind the scenes than you think of off the top of your head. Yeah. So you've been at this for a decade now and you just launched V3. So what's next? What are the big things that you're focused on? Yeah, sure. So with V3, the way I really think about this is that it's an amazing new modern foundation that is going to allow us to both scale in a more reliable fashion and also put more

resources and effort into the kinds of things that people are doing with the data. So I mentioned before that we have some parsing capabilities of the platform where we're actually extracting info from the messages and providing that sort of parsed essence of the data to people instead of just like a raw message. And so we're a platform that is a set of Lego blocks. We're going to be building more Lego blocks on top of the Lego blocks to do things like help people filter down to the set of data that they care about, to look inside those messages or calendar invites and figure out

what is the important parts of these and how do I get it in a structured fashion that makes it easy to connect to my other systems. And then on the scheduling side, we were also investing more in kind of different composable building blocks for kind of different kinds of workflows where, you know, maybe you're building with different kinds of front-end systems. You want to be able to configure things and plug it into different places. Our goal at the end of the day is to find the patterns in what kinds of things people want to build and launch and then make it really easy for people to do that in a way that they don't have to think about the maintenance and upkeep of that. So a lot of things where right now we say that you have to build it yourself,

we'll be investing more in sort of making that easier for the next person that comes along and sort of offloading things that people shouldn't have to care about. We already, with just the launch of v3, we now have built-in bounce detection for email. So a lot of people who are building on top of the platform, they're sending as a user, and then they're automating some workflow based off what happens after that. They want to be able to know, like, did this message go through properly? Was it open? Was it open?

Was it read? Did someone respond to it? And then, you know, basically have, like, conditional logic for, like, what do I surface up in terms of actions and information, depending on, like, what engagement did I see from the other person on the end of this? And so there's a lot that we can do to make it easy to to build that even sort of having like first class sort of like templated workflows where you're just thinking about kind of the the business logic and outputs that you want and not like what does this require in terms of like thinking about the channel at the end of the day. And we may in the future also connect to different channels where like, you know, we're sort of pulling together what we think of as like communications data and allowing people to get access to that data,

to automate workflows with it. And, you know, the question at the end of the day is like, is email calendar and contacts enough or are there other channels out there that we can sort of plug into our data engine and allow people to get the same kinds of benefits where like maybe some pieces of the picture are missing right now? Yeah, I bet you're, I would assume you're probably

getting those kind of requests from customers all the time of like, hey, can you like, can we roll this thing in there underneath this unified API? Yeah, it's always a prioritization challenge to be like, you know, what is our focus and like, what do we do? What do we not do? Um, but I think any startup that matures tends to try to give people more end to end solutions for things that they're trying to accomplish. And so it's a pretty natural step for us to understand better what is the actual sort of business outcome people are trying to drive and then see, like, are there ways that we can, you know, expand what we're doing a little bit in order to make it so that people aren't combining three different vendors to accomplish what they're trying to do at the end of the day. Yeah. Well, I think we could keep going for a long time, but I want to be conscious.

Yeah. I did a lot of work with email at a prior startup, but that would be an entire conversation. But let's do, we have some quick fire questions to wrap up though. So if you can master one skill that you don't have right now, what would it be? Speaking different languages easily. Yeah. What, what wastes the most time of the day for you? Sleeping. Cause I can't function without it. Yeah. What tool or technology could you not live without? I want to say flush toilets. That's what my grandma told me when I asked her what was the best thing that happened in her 85 years of life.

That's a great answer. Which person influenced you the most in your career? That's another great question. The person who encouraged me to go to MIT, her name is Hannah. Okay. And the last one, five years from now, are we going to have more people writing code day to day or do you think we'll have less? Definitely more, but it might be a higher level code than what people write today. Yeah. Higher level of extraction. Awesome. Well, Christine, thanks so much for being here. I think we barely scratched the surface of what we could chat about, but this was awesome. Thank you so much. Yeah, it's been fun to be here. Anytime. Cheers. Thank you.