Walter Chen
Background
Isaac Nassimi is the SVP of Product at communications API company Nylas. We talked to Isaac to learn more about differentiation in the developer middleware market, how companies think about build vs. buy with APIs, and the rise of no/low-code platforms enabling teams to build their own features out of the box.
Questions
- What's the problem you're solving at Nylas? Tell us about your core customer profile and the core value proposition.
- Can you share concrete use cases of developers saving time by integrating with Nylas instead of Google's API or any number of other services?
- What are the core use cases for when an application developer might need to integrate with Google, Outlook and IMAP beyond the obvious—when they might be building a CRM or email client?
- There’s Twilio for sending messages over telephony and Mailgun which has APIs for sending and parsing email. There are also developer APIs of application layer companies like your Calendly or Front. There’s also a slightly emerging category of universal APIs like merge.dev and Vessel, the universal API for CRM. How would you position Nylas with respect to these?
- Nylas started off being focused on email. Now, the focus is on communication—bringing in data, ingesting information from the outside world. Tell us about the initial wedge and Nylas' product market fit. Also, how do you think about expansion of the product line into different adjacent services?
- There are neural APIs, APIs around ML, and NLP. There’s the calendar, which is not necessarily a communication channel, but has very useful contextual data or metadata about communication. Can you talk about some of these adjacent APIs that aren't directly communications channels? How do you think about them and how do you choose which ones to build?
- Tell us about your typical customer—How many APIs and services do they use? How do you think about cross-sell of additional products to existing customers?
- What’s the customer mindset around build versus buy? What are the misconceptions? When is it actually right to build your own integrations versus working with Nylas?
- With regard to Nylas and, in general, what makes a company world class in building developer tools? How do you maintain and enhance that quality as you scale across product lines? What is the core value you leverage?
- Developer experience seems to be a big trend. What does it mean to you in 2022? How do companies actually differentiate based on developer experience?
- How do you position Nylas against enterprise low-code and no-code platforms like Instabase, Unqork, Podium, and OutSystems?
- Can you share how Nylas makes it easy to integrate email and different communication channels into your app? The same way you have embedded fintech for fintech companies, is embedded productivity a meaningful tailwind for Nylas?
- As Sendbird, Daily.co, and MagicBell expand, they add different products. In the context of developer empowerment, do you see these adjacent companies eventually starting to butt-up against each other? How do you define the trend and what the bigger opportunity is for them?
- In general, is it mostly all trending towards uniformity and direct competition or are there pockets where that's not the case?
- If everything goes right for Nylas in the next five years, what does it become?
Interview
What's the problem you're solving at Nylas? Tell us about your core customer profile and the core value proposition.
Today, one programmer can do what it took a large team of programmers to do 20 years ago. Something as simple as setting up a web server used to be a Herculean lift. Now, table stakes have got a lot higher for every application, so a one week MVP isn't going to cut it anymore. You see a lot more complexity in applications.
Something every true application needs at some level, whether it's direct to the users or not, is payments and communication. Payments are well figured out and there are lots of companies doing it right. Communications, not so much.
Your application cannot be the only means of communication, because it's not meeting the users where they are. It's not touching the outside world at all and it's not necessarily solving the problems that you need to solve.
If you want to bring these communications in, you've got a slew of channels to choose from. Each of those integrations is extremely different, so it will take your individual developers and you as a company a lot of time to implement. During this whole time, you are not focusing on your core competencies and building the magic in your application—the juice.
What Nylas does is make it really easy to implement all these communication channels in one blow. And when I say implement these communications channels, these aren’t just APIs.
If you want to get Gmail in your application, you're not just implementing with their APIs or their SDKs. There's a lot of things you have to do. You have to build all these layers to handle incoming webhooks or pub/sub requests, build these sync layers, build a ton of opinionated decisions into your database, track thread management, user management, all of this stuff.
Nylas abstracts all these into one integration that takes care of all of that hard work and actually makes it feel like a single API or SDK, even though under the hood, it's technically not. This scales well far outside of email and turns things like SMS and other channels into just a unified interface that's extremely opinionated and solves the user's problems.
Additionally, something we offer out of the box is a calendar integration. If you think about it, a calendar's really important. It's essentially a contract for communication escalation. It’s a system to be able to plan communication with others in the future.
We provide that kind of prefabricated out of the box functionality for calendar APIs along with the frontend components if you want to add scheduling as a drop into your application and do it in a day instead of a year.
Can you share concrete use cases of developers saving time by integrating with Nylas instead of Google's API or any number of other services?
I've actually got a pretty good one. Before I joined Nylas, I was at a company called Cience. I actually went the build route and ran the engineering and product department. For an application we were building, I championed us building these connectors ourselves to Gmail, Microsoft, and IMAP.
A year later, with a lot of intellectual fire power put into the application, it still wasn't there. Every time we'd look at it or breathe on it, it would break. It was one of those things that began to feel intractable. We weren't here to build connectors to Gmail. That's not what we set out to do, yet it was making up 30% of our total engineering time.
When we rebooted the project, I actually bought Nylas. That was my first interaction with Nylas and it ended up not even being in any of our sprints. We integrated it once and forgot about it, and I mean that in the best way.
We were able to reduce development overhead by 30%, but probably stress by somewhere around 80%, because when these things broke, this wasn't just like, "Our email’s out." These were “P0” fixes that we'd have to wake up in the middle of the night to do.
What are the core use cases for when an application developer might need to integrate with Google, Outlook and IMAP beyond the obvious—when they might be building a CRM or email client?
Absolutely. There are the default ones, like CRMs and applicant tracking systems. But Nylas can really be useful anywhere you need to passively consume information from a user.
Let's say, for instance, that you want to process returns. Being able to passively scan for those emails as they're coming in is a superpower for your application that you probably didn't even conceive of because it was such a lift to build.
Even on the calendaring side, having this passive consumption and seeing new events come in as they're created, the moment they're created, and creating that cross channel consistency is absolutely game changing. We'll set you apart from your competitors in a way you never thought before.
Let’s take running note-taking as an example. If I was Notion, then, having the ability to take in notes—even if the user takes an email and drops it into their own folder or organizes around them a certain way—and prompt those as note creations or, schedule follow ups individually with team members through the note-taking app itself, means that your application transcends the medium of the internet or the website that they're using.
The first time you use Twilio, you get that spark of joy when you push a button, for instance, and your phone rings. The outside world has been affected by your application. We give that same kind of experience in a lot of different vectors with Nylas.
There’s Twilio for sending messages over telephony and Mailgun which has APIs for sending and parsing email. There are also developer APIs of application layer companies like your Calendly or Front. There’s also a slightly emerging category of universal APIs like merge.dev and Vessel, the universal API for CRM. How would you position Nylas with respect to these?
It's a cool description of the ecosystem. I’d say that OAuth is a fundamental piece of where Nylas stands out because receiving an email or a text message, sending these, or even receiving a calendar event is pretty cool when you can do that using some throwaway MX record that you created on your domain.
Being able to do it at the user's email address or on their calendar is completely different. That's that realm of connection where your application isn't something the user interfaces with and has to keep as a point of record or an additional point of record. It weaves its way into their lives. That's truly special and OAuth is a big piece of that.
That's also something that Twilio doesn't seem to be tackling. There are these very open ended struts and communication devices with a lot of one connector systems which they haven't really figured out how to solve because they haven't necessarily chosen what they're going to do. They'll say, "We're going to connect everything," which is great, but communication is very special. There's a reason it needs to sit in its own bucket.
Take a company like Fusebit. They're doing this one stop integration shop and had to make a lot of interesting and really cool product decisions to make that work. One of these is you need to write the connectors yourself in their cloud while they handle OAuth and token management for you. Point is, you still need to write and create all those opinions. You don't set out to create a feature like this because you want to learn about these things. I'm going to keep using Twilio because when you send a text message on Twilio, you don't have to learn about carrier networks.
It’s the same thing here. If somebody wants to add email to their platform or calendaring, I want them to have to know nothing about it. They can keep creating the important business logic in their application.
Nylas started off being focused on email. Now, the focus is on communication—bringing in data, ingesting information from the outside world. Tell us about the initial wedge and Nylas' product market fit. Also, how do you think about expansion of the product line into different adjacent services?
Nylas is focused on not just expansion, but meaningful expansion. Adding in another communication channel just for the sake of doing it is nice, but we want to add new communication capabilities to our platform that exponentially increase the value of the previous ones.
Email is a great wedge and it's always going to be one of the best places, because email is the most unkind environment. With a text message, at least you know what's going to be in it, but an email could literally have anything. It can be a notification from Nextdoor about what your neighbors are saying. It could be a receipt, an email from an old friend, or even one of those same form sales emails you get every single day.
At Nylas, what we’re really doing is not just creating the ability to receive those, but actually creating the ability to extract meaning from them. Is this a bounced email? What's the sentiment of this message? Was this sent by a human or a machine? These are currently pretty hard to figure out, for example. These are very complex things, and in order to turn on those features, you'd have to basically create three new departments in your company. Now it's just a skill you have out of the box.
There are neural APIs, APIs around ML, and NLP. There’s the calendar, which is not necessarily a communication channel, but has very useful contextual data or metadata about communication. Can you talk about some of these adjacent APIs that aren't directly communications channels? How do you think about them and how do you choose which ones to build?
A lot of it is just looking at what our customers are trying to do, trying to preempt those needs, and extracting what's going to create the most lift. What can we do that's actually going to require our customers to learn the fewest amount of things? Essentially, we want communication to be a no-brainer, not that thing that you keep kicking down to the bottom of the backlog every three months for three years. We talk about these and say, "These are AI, these are ML, etc.” but to the customer it doesn't matter. They need value. They need to be able to tell what this is.
A great example is signature extraction. If I give you just the HTML of an email, and you try to get something meaningful out of the signature or even identify where the signature is, you’ll see it’s really hard. Maybe the first thing you're going to reach for is some crazy regex or something like that. But that's not going to cut it. To be able to even tell you who was sent an email based off of the information they included there, is for most people a huge task. Normally, all you have in the email is just that initial sender header with the name and email address.
We can tell you that person's phone number, company name, company website, and more. Everything that they're actually giving you that you're storing in your database is just a big string should you decide to store it.
It's the same thing with regard to what we call Clean Conversation, which takes an email and removes all the junk, the HTML and markdown weirdness, the signature, the whole thread, and things like that. If you have to make that yourself, it's quite a pain and you're probably not going to get it right.
When you get there, it’s the ability to look at all communication channels in a unified way. You can say, "I received a message on WhatsApp and email. Either way, all I want to know is what's in it." You can disregard all of the other useless stuff. That's a superpower.
If you look at applications like Front, for example, they’re doing this more on the customer facing side and less on the developer empowerment side. They’re creating a unified experience for users or at least having it on the menu. That’s something that wasn't available five years ago but is going to be table stakes tomorrow.
Tell us about your typical customer—How many APIs and services do they use? How do you think about cross-sell of additional products to existing customers?
A lot of customers have additional products or additional product usage somewhere on their roadmap. What's cool or just incredible to see is that the customers who use one product realize that it was pretty straightforward for them to use.
You took something that was probably a big worry for them and made those worries rather unfounded. You seemed to escalate that in the roadmap which made it meaningful. That's value. That means you're affecting end developers, individual contributors, and end users, which is incredible.
With regard to product usage, you can look at individual email providers for example and individual endpoints use. Those actually seem to be really disparate but there's a lot of variance there depending on the use case.
Another great example is if I'm passively scanning a mailbox to look for a refund request then, that’s going to be a very different endpoint consumption than if I'm using an applicant tracking system where you're, very often, focusing on sends.
Now, endpoint usage and things like that are really all over the place, so, we'd like to look at the product holistically and say, "Okay, email. Email, send. Email, read." Are we solving problems here? Are we seeing our users grow their usage? Are we seeing our users onboard quickly? Then, it's about talking to them, "What’s in your plan with regard to the calendar?"
The way this works is that most customers have both in their plans. It's about seeing what's really a business priority if development was easy and seeing those things rise to the top.
What’s the customer mindset around build versus buy? What are the misconceptions? When is it actually right to build your own integrations versus working with Nylas?
The build versus buy debate is more about ownership. When I say ownership, I'm thinking that if I want to add a new feature, do I have the capability to do that? If I disagree with an opinion the company's made, then build versus buy seems more a question of ‘What is the dollar value of my skepticism or of you not being a member of my company?”
As we’ve got our product and messaging more dialed-in and got better at conveying the value that Nylas can provide very quickly, we've seen the build versus buy slowly evaporate. It's still there, but what's really interesting is that in a perfect information world, where everyone really understands the build versus buy debate, just about nobody would choose to build if they actually knew what it undertook.
Unfortunately, this is one of those things that sounds pretty easy, especially if you're a non-technical decision maker. In my case, it's science, even if you are a technical decision maker. It really does sound pretty straightforward so, it's more about educating customers in terms of, "If you want to build it, here's a rough project plan for you and some of the things that you're going to have to undertake." That's a great way for them to start to see the light in terms of how this will affect their business.
Is this going to turn into one of those things that was slated to take three months and ended up taking one year or two years?
As we start offering features that provide meta value like insight over just action, for example, we find that build versus buy, isn’t really a question because we're providing a lot of things that customers can't build themselves now or do so reasonably and feasibly. In many cases, they actually couldn't build it themselves because there were a lot of industry hard hitters in the company that had been pounding away for years at this point to create something truly magical. When I say magical, I mean that in the Isaac Asimov way of technology where technology of significant complexity is indistinguishable from magic. That's one of the most overused quotes in the world, yet I love it.
We have a lot of customers who when they see Clean Conversation, they actually look into building it themselves and realize that we're providing a lot of things that are not just the base levels that they would build themselves. On Maslow's hierarchy of needs for tech, we're providing things even at the very top of the pyramid.
With regard to Nylas and, in general, what makes a company world class in building developer tools? How do you maintain and enhance that quality as you scale across product lines? What is the core value you leverage?
You’ve got to have good opinions that actually reflect the needs of the core customer. We're in the world of DevEx which is deceptively the most challenging, because you’re still tied to all of those value principles that you would be if you were developing a UI-driven SaaS application.
On top of that, you're also bound to a lot of software engineering rules, abstraction being the main one. In software engineering, assuming that the code you write is good and the things that you create actually work, your main challenges revolve around how to abstract this thing to be able to solve problems without losing the configurability or the fire power or making it unscalable.
It's a very hard line to walk when your code and SDKs, for example, are going to be running in your customer's code base so it needs to fit in with whatever code they might write and framework they might use. In terms of developing something world class, it really is walking that dual product line.
I'm biased towards creating that opinionated abstraction that serves our customers really well while still giving them the ability to pop the hood and make some tweaks at the end themselves if they want. By that I mean giving them access to maybe change some of those opinions on their own or develop some ancillary features that stack on top of our core features. What you get there is, instead of the build versus buy debate, you get the build versus buy versus buy and build a little bit on top of it, debate. I like that debate a little bit more. It seems a little bit balanced.
Developer experience seems to be a big trend. What does it mean to you in 2022? How do companies actually differentiate based on developer experience?
Here's developer experience in a nutshell. I really like this mental framework I've been building for some time, which is that your average developer has maybe three hours of this “white flame brain turned up to 10” chugging along at work a day. After that, you peter out so you're not going to be solving problems at the same level. Our goal is to not be a part of those three hours.
When you have your brain turned off, you should be able to utilize this code. What that comes down to is making solutions that are copy-pastable and intuitive, meaning based off of the code that you have to write yourself or the things that you're working with. You know what they're going to do before you actually use them. Also, as a tertiary or as something that runs parallel to that, there is being consistent. It’s something you have to learn once and use infinitely.
Consistency between your products is really hard in the DevEx world, because you're usually doing more than one thing, so a lot of that is just based around creating more abstraction. Building some magic into your SDKs that they would have to write themselves if they were using your API and servicing all levels of users and developers, because you want a fresh-out-of-bootcamp developer to be able to use your platform minus struggles makes it very obvious as to who the players are who've got that right. I think they've been rewarded very fairly for that in the market.
How do you position Nylas against enterprise low-code and no-code platforms like Instabase, Unqork, Podium, and OutSystems?
No code solutions are nothing new. We're actually seeing a reprisal now. You see it every decade in the market. For a long time, you've been able to write code using flow charts if required. You can find some examples of what that looks like though it’s not great for anything but the most simplistic solutions and it doesn't scale. The moment you want another piece of functionality or decision making into that flow, your complexity goes up exponentially. I would put that on the no code side.
On the low code side, there are two versions.
Having pseudo code in your platform is cool and interesting to me. It’s a little scary because you don't know what's happening between those pieces of low codes that you're writing.
Then, there’s less code. I always agree with less code because when I hear it, I hear optional code and some of that means having really, really, really intelligent defaults that give the user the power to turn on something incredible one day and fiddle with the knobs as they please to get it perfect. I'm actually pretty happy with that.
Another thing is that having all of these micro-value companies that empower these very small, tiny pieces of your application that you ideally stitch together into a sort of Frankenstein can create a lot of problems.
The first is that your code, instead of being “if this, then that”, becomes “if this, then that and then that and then that and then that.” To me, that doesn’t sound very performant. It sounds very brittle.
Giving the users and our customers the ability to solve that in one shot is pretty awesome. The ability to get your sentiment, your clean conversation and the actual email itself, and all of the headers that you would possibly want on that, analyzed in one request or one web hook notification is first class developer experience. That doesn't just make the stakeholders happy because the feature’s getting done, it also makes the developers happy because they're building something that they're not going to regret later.
Can you share how Nylas makes it easy to integrate email and different communication channels into your app? The same way you have embedded fintech for fintech companies, is embedded productivity a meaningful tailwind for Nylas?
One of my first programming jobs was at a point of sale lending company. It was cool that any shop, whether it was AMKO or something else, could offer loans in a one day turnkey system for their product which totally changed the experience.
It's funny that you bring up the embedded card because one of our engineering VPs worked at Marqeta, which is a company I always thought was awesome. This issuance of cards is normally a feature of a Fortune 500 company but to have those kinds of connections and make it available to any company is really compelling. You're starting to see that, in general, with everything.
I think that's a trend that the whole software world is moving towards of ungating these more complex features or these skills. You've been seeing that in the integration side for a while. You’ve heard, "If you use Asana, let's integrate these different applications into it so you can hook it up to your support system, ticketing system, and note taking system.” This means rather than try to displace the ecosystem or tell users “Don’t use that," or “Copy this into two places,” it’s all treated as one ecosystem that adapts to what the user uses.
From a productivity standpoint, you're going to see the same thing as well, which is less about saying, "Don't use email anymore. Use this instead."
With regard to communication too, it’s about, "You interacted with this platform. And this is now in all of the platforms you use." Or “You interacted with this platform and it's in all the other ones.”
That's really compelling because the amount of apps users are using—our applications or others that anyone's using on a daily basis—is not going down. In fact, it's going up especially at the workplace. It's quickly approaching infinity. I'd really love to see the curves there. As we progress in years, you need that interoperability between different platforms to exist in order to not have users move back to manual data entry.
As Sendbird, Daily.co, and MagicBell expand, they add different products. In the context of developer empowerment, do you see these adjacent companies eventually starting to butt-up against each other? How do you define the trend and what the bigger opportunity is for them?
Whether or not a company wants to admit it, they almost always have a boundary or some land that they've claimed. I've seen Dropbox go into the shopping center recently and while no one knows how that will actually turn out, I think that could turn out really well. Either way, it's a surprise to customers.
With regard to Appcues and Daily.co, if one acquired the other, I think everyone would be questioning what's happening there because an ecosystem isn't just one great line where you have different slots that things have to fit into. Different things are going to fit in different ways. The reason Appcues or Daily.co don't have a monopoly on these things is because they service different niches of customers, whether or not they explicitly realize this or it's implicit.
If you take these markets and any of these individual genres and fast forward five years, what does that market look like? For some of them, everything trends towards the exact same application. You have these different businesses which have either beaten each other up and claimed their different spots of land, or are essentially competing with each other just through pricing models or triggers.
There are companies that look very different when you fast forward five years. They've all taken a different route and are perfectly serving their own niche and segment of customers.
Drop in meeting systems like Daily.co will all look pretty similar in five years. Take the SDKs: Zoom just released one, and in public beta, you've got Daily.co, you’ve got Twilio programmable video. Those SDKs already look very close to each other. What will that look like in five years? It's trending towards uniformity.
In general, is it mostly all trending towards uniformity and direct competition or are there pockets where that's not the case?
There are pockets where that definitely isn't the case. You saw that on the fintech side, for example, where there were a lot of different ways to skin that cat.
Look at the difference between Stripe and Square. With regard to innovation and the innovation front, they both took a roughly similar look at what the market was and went in completely different directions. Both looked fantastic in their own ways to the extent that I wouldn't hold one up over the other, necessarily.
On that front, I’d say that email communication or asynchronous communication, in general, will have a really similar look where any company that says it is going to branch out will have to make some big decisions about how they want to innovate, because you can't innovate everywhere all the time. It's not possible.
If everything goes right for Nylas in the next five years, what does it become?
In the next five years, what you're going to see is Nylas will be the immediate tool that developers reach for, without question, when it's time for any sort of communication feature or functionality. Just the tool that developers reach for first.
We will have trivialized communication feature sets for end users. That's really cool.
Then the world changes in the way where not only do developer experiences get better, but user experiences also get better. As you see applications getting tightly coupled and being able to work with each other in different ways, they solve workplace productivity problems.
Where you have this trend towards infinite amounts of notification spanning different platforms, it solves problems for the elderly having to learn all of these different devices to be able to communicate with their children. This solves problems for just about everyone.
Disclaimers
This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.
Read more from
"Plaid for X" startups
