Considering Platform Plays

Over the last couple of months, I have noticed several prominent software companies announcing new platform offerings. This goes beyond a marketing tactic, as most are backing the move with substantial new capabilities and tooling to add “programmability”. These extensions are meant to appeal to solution builders, in addition to their existing product users. While the companies will still offer packaged products, they are opening up their underlying software services for outside developers to build their own custom applications. The rationalization is an expectation that this will drive incremental revenue from usage fees, as developers launch brand new businesses or internal teams at enterprises tackle adjacent use cases. Also, some leading SaaS companies haven’t rolled out full platform offerings, but might benefit from it. In this post, I will examine what makes for a productive platform play, several recent examples of this trend and how it might apply to other point solution providers. The platform potential of a software company is an important consideration for investors. If executed successfully, it can substantially magnify the long term growth opportunity for a company’s stock.

What is a Platform?

The notion of providing a “platform” for developers to build applications upon is not new. Technology companies have been doing this for years. Techopedia provides a generic definition of a platform: “A platform is a group of technologies that are used as a base upon which other applications, processes or technologies are developed.” In the strictest sense, a platform for software applications would provide all the building blocks necessary to code and execute the program in one place. An example is the Windows operating system running on a desktop. This allows a developer to build a game or spreadsheet application to run on that system. Before the internet, there was no way to connect to an external system to access a software building block. Every software component needed to be on that system. This made building platforms very intensive, only reserved for the largest technology companies.

However, in modern internet-based applications, many software building blocks can be distributed services accessed over some standard network protocol. This may be on a nearby server instance in the same network subnet, or outside the data center and across the internet. This distribution of services allows developers to build applications by writing the core processing code locally and assembling a set of third-party services to handle common functions, like processing a payment (Stripe) or sending an email (Twilio Sendgrid). The main considerations are whether the latency in calling an outside service is acceptable and if the overhead in connecting to a third-party is worth the effort.

Given this paradigm, third-party providers can focus on delivering a highly scalable, secure and functional service for each of these common use cases, allowing the developer to focus on the parts of the application that generate true differentiation and incremental value. The developer can select each service that they need a la carte and integrate it into their application.

The first to the table with platform services were the major cloud providers (AWS, Azure, GCP, etc.) and even their predecessors, like Rackspace or Slicehost. The cloud providers started by leasing basic infrastructure (compute, storage, network) and rapidly moved up the software stack to selling services for developers to consume as they built applications (data storage, message queues, monitoring, machine learning, etc.).

Around this ecosystem, SaaS companies emerged and thrived by offering best-of-breed services that competed with the capabilities of those offered by the cloud providers. They argued that their solutions had the advantage of being cloud provider agnostic. Examples are MongoDB Atlas for non-relational storage, Fastly for edge computing and Splunk for log analysis. There has been a constant arms race between these service providers and the cloud hosting companies around features and ease of use. Leading service providers have been able to keep ahead of the cloud providers, as digital transformation initiatives rapidly up the ante for custom application development. It is difficult for the cloud providers to maintain enough product development resources in each niche service to compete across the board.

Business Considerations

Some independent service providers were born as platforms. They began with the intent to only provide independent services for developers to consume in building applications. Initially, they didn’t develop full application solutions to be marketed to non-developer end users. Interestingly, many platform providers eventually offered packaged solutions as well, that are meant to address a cluster of use cases and be sold to enterprises as SaaS applications for common business functions. A example is how Twilio launched a call center product (Flex) that combines several of its services with pre-built code. In this case, Flex provides a working call center solution for enterprises to adopt, but is also programmable, so that the enterprise’s developers can customize it.

Coming from the other end, many SaaS companies initially built fully working applications delivered over the internet. These addressed large swaths of enterprise functions in salesforce automation, customer service, HR management, accounting, payroll, etc. Some SaaS product providers later expanded into offering a platform for developers to build customized solutions (Salesforce). In these cases, the SaaS providers continue to expand and sell their point solutions, but also monetize the use of the platform by developers to build custom applications.

Beyond sales and marketing considerations, a move to a platform offering requires internal software architecture design decisions. Most significantly, the SaaS provider’s engineering team would need to embrace a service-oriented design philosophy, often referred now to using microservices. Designing the underlying software architecture around microservices makes it possible to expose those services externally to other developers through secure APIs. This is a recent software engineering best practice, and we can’t assume that every legacy SaaS provider has broken their monolithic application architecture into a set of services. If they haven’t, this would require additional work. If they have, then they are in a good position to expose these services to the outside world.

Benefits

Why would a rapidly expanding, sticky software solution provider want to open up underlying services for developers to consume? This is a fair question, especially if they already have highly competitive point solutions and lots of traction in their addressable market. I think there are several business benefits from a platform play:

• Incremental revenue. There are likely a smaller set of use cases or new businesses that customers want to address, which aren’t large enough to warrant building a solution around. The platform offering can generate incremental revenue by allowing use of services on a metered basis, without the R&D and sales costs of building and marketing a full-fledged packaged solution.
• Forces service-oriented architecture design. As mentioned, in order to expose a service to the outside world, the underlying code and infrastructure should already be separated into an independent software service internally. This architectural approach is generally considered a best practice today, as it allows the software engineering organization to operate more efficiently. They can minimize code conflicts, automate the CI/CD pipeline and segment into smaller agile teams.
• Extra care around quality, scale and security. While internal development teams will try to maintain high levels of quality, scale and security in the point solutions that they build, oversights or shortcuts in the underlying software infrastructure can be masked by the UI of the application. We can’t expect non-developer business users to be as rigorous in their testing or security review. However, in marketing a software service to outside developers, a company can expect an order of magnitude more scrutiny around quality. This will help the service provider tidy up their own engineering practices, as outside developers surface bugs, security holes and performance issues.
• Customer activity informs future solution opportunities. Once a company exposes its core services to outside developers, they get to observe what those developers create. This unleashes a whole new source of creativity, which can generate ideas for additional packaged software solutions. The product management organization can use these signals to drive the solution product roadmap and see in real-time what product ideas might get traction. This feedback motion was the genesis for the Twilio Flex product, as Twilio observed customers using Twilio’s programmable voice APIs to build their own call center solutions.
• More visibility. Developers increasingly have influence over IT purchase decisions. Obviously, where their own tooling is involved, developers have strong control. But, they can also influence software consideration sets outside of their sphere, like enterprise collaboration, communication or planning tools. If a solution provider also evangelizes their core services to developers, then these individuals will be able to weigh in on enterprise software solution considerations, at minimum along the dimensions of security and scale.
• Lock-in. Some Saas products have low switching costs, like project management tools. However, if the development team has invested cycles building a unique solution or extending a packaged one through platform services and programmability features, then the switching costs are higher.
• Partner Engagement. Programmability creates business opportunity for the partner channel. The global system integrators (SI’s) can build a practice around a software provider’s platform. They can sell consulting and implementation services to enterprises. This incentivizes them to promote the company’s platform as a solution to their enterprise customers.

Limitations

While there are business benefits in opening up services to developers as part of a platform play, this might not be a fit for all software solution providers.

• Cost. There is incremental cost associated with offering stand-alone services for developers. I will detail the requirements below, but at minimum, developer evangelism requires outreach just like sales and marketing. The services need to be documented, with code examples. Technical support and billing requires additional staffing. The company should sponsor developer meet-ups and organize conferences. All of this represents a cost, that should be considered as part of an ROI calculation.
• Limited market. The market opportunity for platform services in a company’s business segment may be small or uninteresting to developers. While offering stand-alone services for payments, messaging, email and other common software building blocks have wide swaths of application, other services might not have a real market. Or, the consumers of those services would just prefer the end solution and exposing building blocks offers little incremental value. An example might be with accounting software. The end users may prefer to just have the full accounting package (preferably run as a SaaS), rather than giving their developers access to programmatic services for creating a customized income statement.
• Inherently complex. A good service must be inherently difficult for a developer to reproduce on their own. There is always overhead involved in connecting to an outside service, versus just plugging in open source code from one’s own development environment. This usually means the service has complexity or nuances that an open source solution won’t take into account. Examples are integration with other third party services, where those interfaces are constantly changing. Or, where difficult security and abuse edge cases are important, like fraud detection and spamming. While it might be possible for a developer to just plug-in an SDK to call out to a payment gateway directly, many developers prefer to use Stripe because they also handle fraud detection, which is much more complicated. A similar argument applies to bulk email sending and ensuring high inbox delivery rates.

What does it Take?

In order to provide a service for developers to consume, providers need to address a set of infrastructure and engagement requirements. On the infrastructure side, they must address ways to provision the service, make it programmable through discrete API calls, secure access, etc. For engagement, they need to attract developers and facilitate on-boarding – through evangelism, conferences, documentation, technical support, training videos and sample open source code.

I think the following requirements should be met in order to offer a “platform” of services to developers. These are based on examining the offerings of existing platform plays.

Infrastructure Requirements

In order to expand from a solutions provider to a platform play, the following infrastructure capabilities are necessary.

• APIs. Services need to be structured as discrete APIs for developers to consume. Usually, these are REST-based and accessible over HTTP. The request and response payloads need to be formalized and represented in a data structure standard, like JSON. This infrastructure may already be in place if services are consumed internally for existing solutions. If not, this will require engineering work.
• Sign-up and provisioning. Developers need a way to register to use the services. This should be as automated as possible, so that they could get access on a whim at 2am. If payment is required, ideally, that is done through a credit card, at least for low volume usage. Additionally, a “free” usage tier or time period tends to work well, to lower the barrier of experimentation. While the provider doesn’t get to vet users before granting access, they should consider the benefit of getting a new developer to “try out” a solution. Once developers invest time, they will naturally form an affinity for the service. Having any barriers in place blocks this discovery process and impedes curiosity.
• Security. Access controls need to be put in place to separate accounts. Multi-tenancy should be designed into the service, to lower the risk of data leakage. The provider needs to have a secure method to handle authentication and issuing API access tokens. Also, they should design in authorization controls, which determine levels of API access based on account.
• Usage metering. The provider will need to have a system for measuring the usage of the services and APIs by customers. This usage is often the determinant of cost. Additionally, a system of rate limiting will need to be built to ensure that customers don’t abuse the service (explicitly or accidentally) and to manage service tiers.
• Proximity. The provider will need to determine where their services should to run. For use cases that require low latency, then the service would need to be hosted in the same data center as the application. An example is database access, like MongoDB Atlas, where the user has to select the cloud provider (AWS) and region (No. Virginia) for their application. For other services, where some latency is acceptable, the service entry points don’t need to be located in each data center. Examples are Stripe and Twilio SendGrid.
• Developer framework support. If the service involves providing a runtime for the developer’s custom code, then the provider would need to consider what development languages to support. An example of this is Fastly’s edge compute platform, which currently supports VCL and Rust. Because the custom solution has to run on Fastly’s servers, they have to consider how to allow the developers to create the application logic using a common programming language. The service provider also needs to provide tools for packaging, configuring and deploying the application.
• Sandbox or test environments. When the developer is ready to test their custom application, they won’t want test transactions sent into the production environment. For example, a credit card payment test shouldn’t require the developer to use their own credit card for testing. Therefore, the provider should provision a test environment for developers to use.
• Pricing and accounting. The platform provider should consider how to charge for service or API usage. Ideally, this is on some sort of metered basis, where costs scale to usage. They will need to add the infrastructure for this metering. Then, at whatever frequency the pricing model dictates, they will need to summarize usage by developer account and send that data to the billing system to generate an invoice. For SaaS companies used to charging a fixed fee on a monthly or annual basis, this introduces new billing, accounting and revenue recognition practices.

Developer Engagement Requirements

In order to get traction with the developer community, a provider needs to consider all the requirements that enable the developer to discover and consume their services in the lowest touch way possible.

• Documentation. Developers expect all programmatic interfaces to be thoroughly documented. Documentation should be organized by functional group and each API endpoint. It should detail expected inputs, responses and allowed field values. Ideally, sample code is provided for popular development languages. Twilio provides a great example of a well documented API for sending messages.

• Blog with service updates. As the API endpoints evolve or change, it is useful to have some sort of communication medium that captures these. A blog for developers works well – it can include announcements, updates, example usage, etc.
• Developer Evangelism. A service provider will need a way to tell developers about their services and encourage them to use them. This often takes the form of hosting developer meet-ups, conferences or live training sessions. Typically, this involves creating a “community” team.
• Sample code in open source. Having bootstrap or starter code available for typical use cases makes it easier for developers to wrap their heads around an API. Also, it can provide them with a way to kick-start their development. This code should be available in a public Github repository with a liberal usage license.
• On site consulting for big customers. For large enterprise customers, I have seen platform providers run internal hackathons. These engage development teams within enterprises in structured sessions to pursue creative ideas that might generate incremental business for the company. Of course, these are shepherded towards use cases that utilize the provider’s services.
• Technical Support. The provider needs to set up and staff channels for developers to request support, ask questions and submit bugs. This can be a ticketing system, web chat, Slack, email or even phone.

Recent Examples

With this baseline, let’s take a look at some companies that launched new platform offerings recently. These companies started with complete point software solutions and are now extending platform services for developers to use.

Okta (OKTA)

The most recent announcement of a platform offering came from Okta on April 1st. At their Oktane Live conference, they announced Okta Platform Services, which will consist of six core identity technologies available through APIs and SDKs. These are meant to be consumed by customers and developers to build new identity based applications and tailored customer experiences.

We are making the foundational, service-oriented technologies at the heart of the Okta Identity Cloud available to you, our customers and partners, through our out-of-the-box products, APIs, and SDKs.

Okta Platform Services are foundational components of the Okta Identity Cloud that power Okta products and features. These Platform Services enable anyone who uses Okta to leverage Okta’s underlying technologies in a range of ways, empowering our customers, our partners, and Okta engineers to rapidly innovate as identity evolves.

Okta Blog Post

The six initial platform services will be:

• Okta Identity Engine: Delivers customized user authentication, authorization, and registration flows.
• Okta Directories: Surfaces logic for managing a hierarchical directory structure to control access to resources, like files or applications.
• Okta Integrations: Provides frameworks, templates, and tooling to publish pre-built integrations to the Okta Integration Network.
• Okta Insights: Aggregates, analyzes, and disseminates Okta data to generate useful insights, like offering personalized recommendations for security policies or providing end users with suspicious activity alerts.
• Okta Workflows: Allows for automation of complex identity-centric business processes.
• Okta Devices: Collects device-specific data to manage identity profiles and control access.

Okta’s platform services offering is well supported for developers. The developer site is appealing and intuitive. Documentation is thorough. SDK’s have extensive coverage of most popular mobile, front-end and back-end languages. Each includes links to Okta’s Github repo with working code under the permissive Apache 2.0 license. Developer sign-up is easy with minimal information required. Use of services is free for up to 1,000 monthly active users. Once an account crosses the threshold for the free tier, pricing scales proportionally to monthly users up to 50k from $50 to $1,000 a month. Beyond 50k, an account transitions from the Developer edition to One App or Enterprise. These tiers offer more users, support for multiple applications and dedicated support.

My perspective on Okta’s approach:

• Large Market Opportunity. Authentication and authorization functionality is core to any application that requires user access. Most developers will approach the basics of this by writing their own simple user registration function or leveraging an open source solution. Most popular developer frameworks also include plug-ins to handle this like the Devise Ruby on Rails gem or PHP Laravel authentication library. However, as authentication requirements become much more rigorous (device fingerprinting, multi-factor auth, etc.), these open source libraries will not meet all use cases and don’t benefit from broad data collection. Being able to “plug-in” a sophisticated identity service that addresses all edge cases will be a very powerful tool for both developers within enterprises and independents working on a new idea.
• Balance between custom solutions and platform offering. It appears that Okta was already using these services internally for delivering their packaged product offerings, so exposing them externally makes sense. This will allow Okta to continue a powerful feedback loop – platform services usage will improve product offerings and product offerings will drive the need for new platform services. Quality and usability will be ingrained into the core platform.
• Developer Friendly. Pricing is usage based, with a free period. Sign-up and account provisioning are automated without the need to talk to sales. Documentation is extensive with broad language support. The Github repo is active – there are 56 individual projects and over half had updates within the last month.

New Relic (NEWR)

In September 2019, New Relic announced new capabilities for their New Relic One Platform. As part of the release, New Relic also achieved a comprehensive observability platform, which now processes the “Big 3 of Observability” – logs, traces and metrics. They also layered AIOps features on top. These offerings bring New Relic to observability parity with other providers, like Datadog (DDOG) and Splunk (SPLK).

Beyond additional functionality for their product solution set, New Relic introduced “programmability” into the New Relic One Platform. In what they are calling an industry first, programmability allows “customers and partners the ability to build entirely new applications on top of New Relic One.”

Today, we’re giving you the same tools our own engineers use, so you can build applications—custom user interfaces deployed in New Relic One—that connect your observability data, gathered from myriad sources—including third-party open-source data—all in one place. And we’ve made it so easy that a developer can have an application up and running in an hour. We’ve even built a set of open-source applications you can deploy and use immediately!

New Relic ONe Platform Blog post

Similar to Okta’s approach, New Relic is not changing their packaged monitoring products with the launch of programmability. They are exposing the underlying data services and development frameworks used by New Relic’s own engineering team to outside developers to use. They also extended their data model to accommodate generic data collection concepts, like the “entity” which is anything that has data to be monitored.

Applications built on top of the New Relic platform consist of React components, which is a Javascript based library used to build user interfaces for web or mobile apps. Those components are backed by New Relic’s APIs and a GraphQL definition, which puts a developer friendly facade on top of the APIs. These open standard frameworks will be familiar to developers.

As part of the offering, New Relic provides a lot of tooling needed to support the packaging, configuration and deployment of the applications built. The New Relic application code and configuration is stored in a “Nerdpack“, which is the package that gets deployed to the hosting environment. For New Relic’s offering, the applications run within New Relic’s software infrastructure. They are accessed through the customer’s existing New Relic account and display as another view within the main navigation page.

To make the development process as easy as possible, New Relic provides a CLI tool (Command Line Interface) that can be used to generate the Nerdpack files, configure the app and deploy it locally or to the New Relic One platform. They provide a set of packaged React components that render the UI, manage data and interface to APIs. They also provide a convenient NerdStorage capability, which can be used to store custom application attributes, like user preferences.

The documentation set for developers is extensive. They have open sourced a number of sample applications, from which developers can borrow code or just get familiar with the framework. These are oriented towards contextual use cases, like customer journey dashboards. All code is available for use from New Relic’s Github repo. They also provide a community portal with common questions and feedback.

For New Relic’s programmability offering, access is available through the existing subscription model at no additional cost to customers (Pro subscription level). This is an interesting move, as it doesn’t directly generate incremental revenue. However, it could be viewed as a competitive differentiator and therefore indirectly drive more revenue through new sales.

My perspective on New Relic’s offering:

• Deep Integration. I like how the solution is built into New Relic’s hosting environment and that new apps are displayed within the customer’s existing New Relic account home page. This reinforces the value of the point solutions, but also provides customers with their own programmability capabilities.
• Monetization. Since this is being offered for free to existing customers, we can’t expect a big near term bump in revenue. I think New Relic is doing this as a competitive move, to differentiate their product offering in the crowded observability market.
• Customer Need. It’s hard to assess how much this will resonate with customers. While I can see the benefits in being able to create custom monitoring apps, I don’t know how many DevOps teams will really do this. They may be happy with the packaged solutions for observability, which arguably address most of the use cases. Customers then fall back to comparing competitive offerings based on the quality of the packaged solutions. This is where Datadog may continue to excel. Regardless, it is an interesting move by New Relic, which at least provides another capability to dangle in front of customers.

Zendesk (ZEN)

Zendesk has been a leader in providing SaaS customer service solutions for years. In late 2018, they announced their Sunshine Platform in Early Access mode for existing customers to trial. In March of this year, they made it broadly available and began monetizing the service.

Sunshine is described as an open and flexible CRM platform. It provides developers with tools to build custom customer experience applications. Customer data can be imported from any source into a flexible and generic data model. The data model supports three primary concepts:

• Custom Objects. The Sunshine Custom Objects API allows for the creation of new object types in Zendesk and then to populate those objects with customer data. A custom object can be just about anything – the schema is totally flexible. Examples include service contracts, catalog items or customer households. Once the object types are defined, the Custom Object API allows the user to create, read, update, or delete the objects.
• User Events. The Sunshine API provides the ability to create events triggered by customers as they interact with an enterprise’s digital footprint. Events can reflect any programmatic action generated by an app, like purchases, sign-ups, visits or customer service interactions. Each event is associated with the customer who triggered the event. Processes can then listen for event creation by type and kick-off other actions. Examples might be triggering a follow-up communication after a certain customer action or to personalize a response.
• Profiles. The Sunshine profile API allows users to manage customer data across different systems. A profile consists of an identifier for a customer in each external system plus any custom attributes to describe them. These profiles can then all be associated with a single customer identity. This would allow the developer to connect customer data across multiple systems and pull that into a single view for their app built on top of Sunshine.

Existing Zendesk customer service and sales products are simply treated as external data services to be imported into the Sunshine CRM platform. The user can map relationships between Custom Objects and standard Zendesk objects. The Sunshine data layer is not shared with any Zendesk products, but developers can model relationships with native objects like tickets and users.

In this way, Zendesk’s platform is different from New Relic and Okta. The data isn’t shared with the core products, rather it is separate. This is by design, as Sunshine is meant to be used as a platform to build a centralized CRM application, with all other business applications, including customer service, represented as importable data sources. Essentially Zendesk launched a platform to address a brand new product space, versus exposing the underlying services that power its existing products.

Sunshine was created as a way to distinguish Zendesk from other CRM solutions, which they describe as “walled gardens”. By allowing Sunshine developers to pull in data from any source, Zendesk feels their platform solution is uniquely positioned in the marketplace.

Access to Sunshine is sold on a per agent per month basis, ranging from $0 to $59. There are three tiers, each with ranges on custom object and event counts. Currently, access requires the customer to also have a license for the enterprise level of the Support or Support Suite product.

My perspective on Zendesk’s offering:

• Incrementally monetizeable. The Sunshine Platform is sold separately from Zendesk’s other core products. Additionally, it addresses a market segment (CRM) that is essentially new for Zendesk. Therefore, any revenue from Sunshine would be incremental. Coming out of the Early Access period in 2019, Zendesk leadership mentioned that 2,000 existing customers had already started experimenting with it. In a March press release, they highlighted the experiences of clothing retailer Indochino and storage company Makespace.
• Not freely usable. Leveraging Sunshine requires an existing customer relationship with Zendesk. An independent developer can’t easily sign-up and just start using the platform at this point.
• Flexible design. Zendesk went to great lengths to make the data model and platform design as generic as possible. It doesn’t make assumptions about how customers would want to structure their data (the three main entities are called objects, profiles and events). Zendesk didn’t encumber the design with its own baggage of assumptions around data structure for a CRM application, allowing a lot of extensibility for customers.

Who Could Be Next?

This is the billion dollar question for investors, as a platform offering could result in incremental revenue streams and help the company realize other indirect benefits around quality, lock-in and partner channels. However, this might not make sense for all companies, particularly if we consider the overhead cost and market fit.

Based on the considerations for platform offerings, let’s take a look at a few software providers that are primarily focused on end user solutions. This exercise is meant to get investors thinking about the potential for these companies, and more importantly, to apply the platform framework to consider the opportunity or risks for their favorite SaaS provider.

Zoom (ZM)

Zoom is a popular video conferencing solution provider. I won’t try to present the investment thesis for Zoom’s existing end user solutions. It is outside my scope and is covered extensively elsewhere. They have an existing app marketplace and extensive, but low visibility, API and SDK offering. Most of the API integration handles admin functions outside the Zoom client, like creating a new meeting, adding users and viewing usage reports. Open source client SDK’s are available for mobile devices, Windows and Mac. These provide more granular control of the UI elements and features within the Zoom client.

The app marketplace includes the integrations you would expect for enterprise collaboration tools, like Slack, Teams and Google Calendar. Apps in this context are stand-alone applications that perform some other business function and provide the ability to launch a Zoom meeting or send a Zoom Chat message from within that application’s workspace. For a deeper integration, a developer could utilize the SDK’s to embed the Zoom video client into a stand-alone mobile app, web app or desktop program. The SDK has functions to control most features within the Zoom client, like muting a participant, setting meeting entry chimes and pinning video to a participant.

Even with these extensive capabilities around the API and SDK, it doesn’t appear that Zoom has pushed these offerings heavily. I found a couple of examples on their site showing use cases for healthcare and education. The link to Zoom for Developers goes to a landing page with the call to action “Elevate your SaaS offering by integrating Zoom’s Collaboration Services.” To sign up, a developer needs to email ISV Platform Sales. There is reference to API access on the Pro pricing plan. Given that this is bundled into the Pro plan, it isn’t meant to be used to build a stand-alone application.

Opportunity. Zoom has the underpinnings for a platform offering, but hasn’t gone to the point of fully enabling developers to build stand-alone collaboration applications. Twilio offers this capability in their programmable video product. They highlight a recent customer example with Doctor on Demand, which used the programmable video service to power their telehealth app. Given Zoom’s extensive reach currently, reputation for high quality service and dominance in video, they might unlock a whole new set of use cases and incremental revenue opportunities by promoting a true platform offering around video collaboration.

Benefits. Beyond incremental revenue, Zoom would likely benefit from the other intangible aspects of moving to a platform offering.

• Opening up platform functionality further would help address concerns around security and information sharing. Developers and security experts could scour the APIs and open source code for bugs, security flaws or potential privacy issues and report them back to Zoom.
• Zoom could also examine the activities of the developers, as an input to future product offerings or extensions to the video conferencing solution. This might lead to new solutions they could monetize, like in gaming or media production.
• Video conferencing solutions have low switching costs. While Zoom has the leading solution now due to feature set and performance, that might not be maintainable over time. Having internal developers customize their enterprise’s video conferencing tools would lead to higher lock-in.

Effort. Zoom has extensive developer documentation, if you know where to look. It took me a while to locate all the developer resources. Documentation covers the APIs, SDKs and the basics of building an app. SDKs are open sourced and available in Github. They have a dedicated developer blog on Medium, with some activity. I counted 10 posts so far this year. Developers can get help on a forum, which is pretty active. Developer outreach is very limited at this point. I am not aware of developer meet-ups or Zoom sponsored conferences targeted at the developer community. Interestingly, I did find job postings for a couple of Developer Advocate roles, so this initiative may be in the works.

Take-away. I think Zoom would benefit significantly from a full platform offering. The market for video collaboration is large and we have likely just scratched the surface of potential use cases, particularly in this new social distancing environment. Additionally, the transparency associated with “opening up” the underlying infrastructure would go a long way towards inspiring confidence that Zoom is using best practices in building their popular end user solutions. Zoom already has most of the underlying mechanics in place to support a platform initiative and seems to be adding staff to further enhance outreach and developer evangelism. Investors will want to monitor Zoom closely for movement in this area. It could unlock a whole new revenue stream and provide further justification for ZM’s premium valuation.

Datadog (DDOG)

Datadog is a leading provider of observability solutions. I recently published a deep-dive on the company. They do not offer a programmability solution in the same way as New Relic, which allows a developer to create a custom monitoring app using their platform. I have a mixed perspective on the opportunity that a full platform offering would represent for Datadog.

Benefits. Similar to New Relic’s strategy, adding programmability to Datadog’s offering would make their solutions “stickier”, as DevOps teams could build custom views tailored to their unique monitoring requirements. This could also drive incremental revenue if surfaced as a completely stand-alone service. I can see an argument for the benefits of providing generic data pipelining, storage and visualization services, from which developers could build any kind of distributed monitoring device network (maybe healthcare devices or IoT). Investors should watch traction with the New Relic platform offering to gauge the potential competitive impact.

Effort. Datadog already has extensive and well documented APIs and SDKs available for customers. These are primarily geared towards enabling new monitoring system integrations and allowing for custom data types to be injected into the ingestion pipeline and correlated into a customer’s monitoring scheme. To enable full programmability, they would need to either provide a hosted environment, with a UI framework and packaging tools, like New Relic, or place a facade around their existing APIs for easy provisioning. Documentation, code samples and support are in place, but Datadog would need to conduct developer evangelism – outreach, meet-ups, community building, etc. They do have an engineering blog and extensive public Github presence already.

Take-away. I think the opportunity for Datadog to roll a platform offering is moderate. At least for 2020, they could continue to focus on delivering their best of breed solutions and extend into adjacent areas. Long term, I think the idea of powering “monitoring” capabilities outside of software infrastructure would be very interesting and could be a large opportunity.

Coupa (COUP)

Coupa is a leading SaaS provider of business spend management. Their products help companies manage the processes of purchasing supplies and services from vendors and then paying for them. The solution is delivered over web and mobile interfaces, modeling common workflows for corporate purchasing and accounts payable departments. The company is experiencing rapid growth as many large enterprises shift significant internal spend to the Coupa product suite. Their applications span core functions across vendor invoicing, expense submission, procurement and payments.

Coupa’s applications are powered by their Business Spend Management platform. The platform is currently utilized internally, and presumably includes all business logic, data structure and services needed by Coupa engineering teams to build their applications for end users.

The Community offering is an interesting development by Coupa. This represents their efforts to leverage the relationships and data they collect by processing $1.7T in spend to generate new insights for customers. These include flagging suspicious activity, vendor fraud, pricing optimization, supplier continuity risks, new supplier discovery and peer savings. Also, they leverage this consolidated industry data to release their quarterly Coupa Business Spend Index, which shows trends in business spend activity.

Coupa offers integration capabilities through its CoupaLink program. This allows independent software providers to exchange data with the Coupa platform through a set of APIs. Technology partners can implement their integration and get CoupaLink certified. Then, Coupa customers can access the features associated with the integration through their licensed products. Third party enterprise applications that are candidates for integration include ERP systems, tax engines, invoicing, payments and T&E management tools. Examples include SAP, Avalera and Sabre. As part of their Inspire conference in June 2019, Coupa also announced an App program, which would enable Coupa customers to embed third-party applications into their licensed Coupa BSM products. These apps surface data within the Coupa BSM tools to help Coupa customers make more informed decisions. Examples include EcoVadis, which provides supplier sustainability ratings, Mastercard Track, which provides supplier risk data, and BitSight, which provides supplier cybersecurity ratings.

Benefits. Coupa has the beginnings of a platform play, providing APIs for adjacent enterprise application integration, and a nascent App program. The integration capabilities are expected, given the position of Coupa’s applications in the overall business finance and operations ecosystem. The App program seems to be gaining traction, but doesn’t have a clear revenue benefit. Given the nature of Coupa’s BSM solutions, these are probably sufficient extensions of platform capabilities for now.

However, the Community offerings may represent a larger opportunity for Coupa to extend platform services for independent developers to consume. While Coupa is leveraging their spend data to build point solutions, the outside developer community may conceive of entirely new applications for this data. That could lead to either new stand-alone products or drive a greater velocity of Apps built within the Coupa packaged software applications. This data could be licensed or fees charged for App placement, resulting in incremental revenue.

Effort. Coupa has some of the basic mechanics in place to expand their platform offering to enable a broad community of developers to begin building new stand-alone applications. The API documentation is available online and covers authentication, API methods, data inputs/outputs and format. Each API endpoint includes a list of actions and data elements, but I couldn’t find sample code. Similarly, I wasn’t able to find ready made SDK’s or open sourced starter code. Coupa does have a public Github repo. This consists mainly of projects used internally by the engineering team, many of which were forked from other projects. Their corporate blog includes an IT and Technology category with two posts in the last year. I also found a deprecated Tech blog from 2017.

Coupa has an integration partner program. To sign up, a partner needs to fill out an application form. The program is directed towards companies versus individual developers. For developer or partner evangelism, I wasn’t able to find open positions directly targeted at this function. They provide a few ways to get support for technical integration issues.

Take-away. I think there would be some benefit for Coupa in rolling out a full-fledged platform offering targeted at developers, particularly around acceleration of the Community offerings. To do that, Coupa would need to invest in extending their developer outreach and technical support capabilities to enable a self-service motion. For 2020, Coupa is still experiencing rapid growth in adoption and extension of their existing business spend management solutions. Focus should probably remain there. However, for 2021 and beyond, I think their nascent App program and a broader developer-focused platform offering might support expansion into other market segments and further cement their position as a forward-thinking software provider in BSM.

Investor Next Steps

The platform offering trend will likely continue. While platform services will generally benefit the provider, there are some instances in which the ROI will not be as significant as expected. Additionally, some companies that are currently point solution providers may have a much bigger opportunity to evolve towards a platform play and engage millions of developers in building new applications powered by the provider’s underlying service infrastructure.

In this post, I tried to provide investors with some examples of companies that have recently extended into a platform offering, and more importantly, a mental model for evaluating other software solution providers who might expand in this direction. Success in software investing is often determined by looking forward to anticipate future opportunities for a company and taking a position before the market catches on.