How Twilio’s developer-led business model enabled a shift to enterprise sales

It’s 2016. You’re driving through San Francisco. You cross the Bay Bridge, and what do you see on the horizon? A bold red billboard that says, simply, “ASK YOUR DEVELOPER.”

This isn’t a billboard for you. This, quite literally, is a billboard for everyone but you. And Twilio—the company that paid for the advertisement—wants everyone to ask you about Twilio. They trust you have an answer ready because, at this point, many developers are already using Twilio behind the scenes.

Twilio was one of the first, one of the biggest, and one of the most prominent developer-focused companies. When you talk about the land-and-expand model, the business model whereby companies sell to developers and then upsell to the enterprise, you can be sure Twilio will come up.

Twilio made a product that was intrinsically useful and easy to use. They marketed it to developers who started using it and deploying it, all of which gave the product sales momentum when Twilio eventually went to close enterprise-level deals. From there, they expanded usage and earned bigger and bigger contracts.

This story of a developer-led company using what’s known as a “bottom up” sales motion is well known. What’s less known is the story of the work behind the scenes — the features Twilio developers worked on to make this sales motion possible. But without that work, Twilio wouldn’t have grown the way it did.

“By developers for developers”: A Brief History of Twilio

A phone call changed the Twilio trajectory, but not in the way you think. It was 2008, when Jeff Lawson, founder and CEO of Twilio, sat across from venture capitalist Fred Wilson, from whom Lawson was asking for an investment. Lawson’s claim? That he had “taken the entire messy and complex world of telephony and reduced it to five API calls.”

Wilson doubted him, so Lawson whipped out a laptop, turned on an editor, and coded an app — live — in front of Wilson. Moments later Wilson’s phone was ringing. Lawson had used those five APIs to call Wilson from his computer in front of him. Wilson went on to call it the “best seed pitch ever."

This tale demonstrates Twilio’s developer-centricity, a focus that extends up and down the company — from the developers on the ground to the developer-CEO. Lawson is the kind of CEO who, years into running the business, still codes live on stage.

This focus on developers has always driven Twilio’s growth. Twilio’s mission is to modernize communications, and it does so by virtualizing the infrastructure behind telecommunications and making all that power available via a flexible web API. Essentially, Twilio enables developers to build programmatic communication features, such as sending and receiving phone calls, text messages, and videos, through a web API.

Twilio is not the first company, nor the last, to have promised a “digital transformation” for telephony. The protocols for making calls and sending text messages are over 30 years old. If you’ve used the vestigial feature on your smartphone that makes calls, you’ve likely recognized the need for something better. Twilio stood out from the field by focusing on the developers using the tool they created.

From the early days of the company, Lawson has been careful to prioritize what the product can do and to show developers how they can use it. Lawson attributes the company’s success to this utility, not some sales pitch or marketing copy. In his words, “Twilio made new things possible.” That’s what developers — makers, in other words — like to see.

This developer focus paid off. In 2010, Twilio’s API could perform 5,000 simultaneous calls. On average, customers today “send nearly 100 million messages a day, including 13,000 per second at peak.” In 2010, Twilio employed 16 people; in 2020, it employs nearly 3,000.

Ed Sim, a partner at Bold Start VC, dove into Twilio’s investor presentation deck to pull out some more numbers worth looking at: In the last four years, Twilio has gone from “900k devs in 2016 to 2 million devs in 2017 to 10 million in 2020.” That growth results in incredible profits, as shown in the graph below, which depicts the land-and-expand model in action via an anonymous customer.

Meanwhile, Twilio has maintained a heavy-hitting string of features, launching SMS in 2010, picture messaging in 2013, MMS in 2014, video in 2015, programmable wireless in 2016, and declarative APIs in 2017. On the back of that growth, Twilio has also been able to make major acquisitions, such as the $3.2 billion acquisition of Segment in 2020. Essentially, if you want to build a feature that involves cellular communication, Twilio is what you turn to.

This feature development highlights a utility-first philosophy Twilio has always taken. Lawson has said, “Every company starts with you trying to figure out the utility you provide to your customer, which usually it’s not about, say, security and compliance and things like that.”

Focusing on “things like that” though –– security and compliance –– is exactly what moved Twilio into the big leagues.

“You don’t need sales”: 5 types of features Twilio built to move upmarket

The untold story behind Twilio’s success is the feature development that didn’t break headlines, the work behind the often boring features that made the company “Enterprise Ready.” We’re talking things like security, authentication, and compliance — features that don’t tend to get developers out of bed in the morning but do tend to get signatures on enterprise deals.

Twilio’s enterprise strategy has been built on the bedrock of its developers, not on its sales team. Lawson has gone so far as to say, “You don’t need sales.” Instead, Twilio created a “tailwind” by encouraging developers to build with Twilio and pitch their products to executives. In many cases, Lawson says, the executives might just say, “Hey, the thing’s already built. . . . Let’s get it shipped.”

Getting it shipped, however, depended on more than the excitement of a developer and an executive. In Lawson’s own words, after both product and excitement are built, “we’re just trying to check the boxes that need to be checked in order to get something out the door.” Twilio’s developer focus informed where it invested its feature development. Twilio knew that developers, as well as admins, product managers, and CTOs, need features that make the product Enterprise Ready. A lesser company may have relied entirely on a sales pitch; Twilio developed the features that made enterprise adoption possible.

1. Developer and admin tools

Enterprises are fickle, and they have the size and buying power to demand customers bow to their fickleness. The key isn’t to cow to every demand but to build tools for developers and admins within enterprises that enable those teams to use your product as they see fit.

From 2013 on, Twilio developed numerous developer and admin tools that made the core product more customizable and more usable by enterprises.

Application Monitor and Request Inspector
In 2013, they introduced Application Monitor and Request Inspector. Application Monitor enabled developers and admins to monitor errors from Twilio applications in real time. This meant that the product became more enticing to enterprises considering running business-critical functions on Twilio. Enterprise developers could now identify issues within the app and have error analytics at their fingertips for diagnosis and resolution. Key too, is that Application Monitor introduced email alerts and webhooks that developers could use to automatically notify them as errors happened.

Alongside Application Monitor, Twilio debuted Request Inspector. Requestor Inspector is a little simpler, but important nonetheless. Twilio referred to it is a “debugger for phone calls.” It gave developers an HTTP inspector they could use to identify all the requests happening between an application and Twilio during a call.  

Advanced Monitoring
In 2015, Twilio introduced advanced monitoring. Monitoring features are especially important for enterprise IT admins, who are often charged with the operational side of onboarding and maintaining new applications. Twilio Monitor, as it was called, was in place previously, but the 2015 improvements were vast. Users could now see into “every operational detail” across all their Twilio accounts. This promised to help DevOps teams, especially, as they tried to “actively prevent security holes, audit for compliance and investigate application issues caused by human error and application behavior.” For enterprises worried about security and compliance — which is to say, all of them — this is compelling.

Add-ons and Notification orchestration
2016 saw two more improvements worth noting: Add-ons and Notification orchestration.

Add-ons enabled developers to use preintegrated partner technologies via the Twilio API, meaning they could customize Twilio to their needs with technologies from companies like IBM Watson, Marchex, and Whitepages.

Notification orchestration via what Twilio called Twilio Notify enabled developers to notify users across SMS, push notifications, and messaging applications without having to separately configure each channel.

2. Security

Security, according to Lawson, is “a never ending journey.” What took Lawson time to realize, however, was that enterprise stakeholders weren’t looking just for security — they were also looking for the right answers to specific questions about security. Twilio needed a checklist with every box ticked.

Account security settings
In 2013, Twilio added account security settings. You can almost always presume that enterprises want more control over the accounts they’re using, and this was one of Twilio’s first steps toward that.

These settings enabled developers to disable and enable certain features. Request Inspector, for instance, could log “sensitive personal information” in server responses. For enterprises with strict data security requirements, this feature allowed them to easily toggle that setting off and continue using Twilio. Similarly, enterprises could enable the enforcement of HTTP authentication for accessing media. This creates another level of security, something enterprises always crave.

Public key client validation
In 2016, Twilio launched its enterprise plan. The enterprise plan came with a load of features relevant to enterprises, unsurprisingly. In particular, however, it included public key client validation, which enabled developers to upload public keys to Twilio. Customers on the enterprise plan could then validate that each REST API request came from an approved business application. Enterprises could be more confident that there wouldn’t be “fraudulent activity” or “service disruption.”

Proxy
In 2017, Twilio announced Proxy, an API that enabled developers to provide private text and voice conversations between customers and workers. This was especially important for enterprises employing mobile workforces, such as a cable company with servicers traveling from home to home.

The code was simple, using a declarative API that made it easy to implement:

Proxy ensured those mobile workers could use their own devices to connect to customers without sacrificing privacy or security between them.

3. Compliance

It doesn’t matter how good your product is. Even if a customer’s developers are salivating to try it out, they can’t without compliance. As Twilio moved upmarket, it added compliance to make it tenable to more enterprises.

Twilio Interconnect
In 2016, Twilio Interconnect arrived. Twilio Interconnect allowed developers to use private connections between Twilio and their on-premises infrastructure. That meant enterprises could now “meet the most stringent network requirements for controlling quality and security.” Enterprises were now able to connect to Twilio via the following:

• Cross-Connect
• Multiprotocol Layer Switching (MPLS)
• Amazon Web Services on-net
• Virtual Private Network (VPN)

SOC II and ISO 27001
In 2017, Twilio earned SOC II compliance and an ISO 27001 certification. SOC II compliance pertained specifically to Authy, Twilio’s two-factor authentication service.

ISO 27001 was broader, certifying that Twilio had undergone validation by an independent security firm that proved Twilio protected company and customer data. Certifications like these calm the nerves of enterprises who want to be able to trust that the applications they use comply with recognized security best practices.

4. Enterprise-level infrastructure

The one thing enterprises all have in common with each other is size. That means companies selling into the enterprise need to be able to scale. If your company can’t provide the scale an enterprise needs, no other feature will make it good enough.

Elastic SIP Trunking
In 2015, Twilio made Elastic Session Initiation Protocol (SIP) Trunking, along with an associated 99.5% SLA, globally available. With Elastic SIP Trunking, enterprises could replicate the logic of their on-premises interactive voice-response applications in the cloud. If an outage occurred — a scary prospect for any company — Twilio could then route calls to the cloud.

SIP Trunking, even at the time, wasn’t new. But according to Twilio, 80% of enterprises used physical PRI connections (something Twilio decried as “legacy”) to provide public switched telephone network (PSTN) connectivity to on-premises infrastructure. SIP Trunking instead sends voice (as well as other communications) over the internet using an IP-enabled private branch exchange, or PBX.

At the time, most SIP Trunking offerings were onerous to implement and failed to live up to their promised potential. But this feature meant that with Twilio, enterprises could “deploy SIP trunking in minutes and at a fraction of the cost previously possible.” Most important to many developers was that it came with self-service provisioning and an easy-to-understand pricing model. For enterprises, it meant native support for call recording, SMS, and disaster recovery as well as access to private connections via multi-protocol label switching (MPLS), encrypted media and signaling via Secure Real-time Transport Protocol/Transport Layer Security (SRTP/TLS), and no capacity limits via Twilio’s global cloud architecture.

‍Twilio Functions
In 2017, Twilio launched Twilio Functions, which they billed as a serverless environment developers could use to build communications apps. The goal was to reduce the infrastructure overhead typically necessary when building apps, including the setup, the configuration, the management, and the scaling. Instead, Twilio Functions handles all that, letting developers focus on building while Functions takes care of the compute resources.

Without Functions, developers were stuck doing the dirty work of managing web servers — or the dirty work of convincing an IT admin to help them. With Functions, developers can give Twilio the code for handling things like incoming phone calls or SMS messages, and Twilio will automatically provision the web infrastructure necessary.

For developers at enterprises, this meant Twilio was becoming even more attractive to use. Its accessibility and its scalability meant developers could focus on what they love: developing. That empowerment is the foundation of Twilio’s business model, to the land-and-expand strategy that earned them developer love and enterprise sales.

5. Authentication and RBAC

Controlling who has access to what while people use your app is an essential feature for enterprises. Twilio made an important acquisition to beef up its authentication tech and included new authentication features in its eventual enterprise plan.

Authy acquisition
In 2015, Twilio acquired Authy. Lawson had noticed an “increased demand from Twilio customers for easy-to-implement, strong authentication options for mobile and Web apps.” So they bought a company that could help them fulfill that demand. The Authy acquisition gave them a “cloud-based API to seamlessly embed two-factor authentication (2FA) and phone verification into any application.”

Authy automates policy management and builds security best practices into apps that adopt it, making authentication implementation easy and effective. Companies like Box, Intuit, and DocuSign were already using Twilio for 2FA, but with Authy, they could manage their policies even more effectively. The Authy acquisition made Twilio a stickier product for current enterprise customers and an even more compelling one for future enterprise customers.

SSO and RBAC
In 2016, Twilio launched its enterprise plan. This plan included a whole host of features, such as public key client validation mentioned above. But also, relevant here, it added single sign-on (SSO) and role-based access control (RBAC).

Twilio based its SSO on SAML, promising, as many SSO-providing companies do, greater security and access. Every company promises the same benefits from SSO, but that repetition doesn’t make it any less enticing to enterprises: employees only need to sign in once, and IT admins can control access via an existing identity management system.

Locking SSO behind a paywall did, however, earn Twilio a spot on the SSO Wall of Shame.

RBAC, similar to SSO, is an unexciting feature that most enterprises nonetheless need. With RBAC, Twilio enabled developers and admins to create roles and permissions that tailored access according to a company’s needs. Twilio also provided a directory service integration that let admins synchronize users and privileges via existing permission management tools.

All this adds up to an offering that enterprises can fine-tune with permissions that make the entire product more secure and more integrated with an enterprise’s existing environment.

“Page Twilio”: Developers built Twilio, but Enterprise Readiness took it to the next level

Twilio always prized what it deemed a “developer first approach.” Lawson described it as “putting a new tool in the toolkit of the world’s developers,” with the eventual result being that when developers encounter a problem, they have a response: “‘Aha! I know how to do that. Page Twilio.’”

As developers paged Twilio again and again, Twilio gained a stronger grip in developers’ minds. This grip wasn’t the result of good marketing or good sales, but rather, as Lawson says, the ability to “build a prototype in an afternoon.” Twilio effectively short-circuits what’s typically a long, laborious enterprise sales cycle. Landing in the enterprise via developers is “faster, way faster than you can often get an enterprise sales rep on the phone. You actually ship the product before you could even start that enterprise sales process.”

The pitch is the product. But the product isn’t enough to close. Enterprise Readiness, via developer and admin tools; security; compliance; enterprise-level infrastructure; and authentication and RBAC are what close the deal.

Do you want to close enterprise deals? Then your product needs to be Enterprise Ready. Try WorkOS today.