Two Approaches to Monetizing External Developer Platforms

Many large companies today are investing in a digital platform that provides shared digital components for internal development teams to use in building digital solutions. Rather than recreating existing functionality, developers reuse components to shorten development time and lower cost. Seeking additional value, some companies open their digital platforms by exposing platform data and functionality (via APIs[foot]An application programming interfaces (API) is a mechanism allowing one application to exchange data with or trigger actions in another application.[/foot]) to external developers, extending the platforms into external developer platforms, which we call ExDPs. For example, Philips offers external access to its HealthSuite Digital Platform via the developer portal HSDP.io, while Caterpillar provides access to the functionality and data of the company’s Helios platform through the Cat Digital Marketplace.[foot]HealthSuite Digital Platform, Philips, https://www.hsdp.io/; and Cat Digital Marketplace, Caterpillar, https://digital.cat.com/. Both accessed June 9, 2025.[/foot] Yet many companies implementing ExDPs have not succeeded in monetizing them.

Our research has found that companies take two distinct approaches to monetize their ExDPs, each with unique value-generation mechanisms and requirements. In the first approach, which we call build-on, external developers build applications on top of the company’s platform. One company taking this approach is Salesforce, which allows partners to build apps and services on its platform and connects developers with customers through the company’s AppExchange marketplace.[foot]M. Mocker and I. M. Sebastian, “How Salesforce Built Its Platform Business,” MIT CISR Working Paper No. 462, April 2024, https://cisr.mit.edu/publication/MIT_CISRwp462_SalesforcePlatformBusiness_MockerSebastian.[/foot]

The second approach is what we call build-in. In this approach, the company enables external developers to integrate its platform’s capabilities into the developers’ own applications. Schneider Electric, for example, allows customers to embed data and functionality from its EcoStruxure platform directly into their own applications using APIs provided via Schneider’s Exchange portal.[foot]M. Mocker and I. M. Sebastian, “The Journey of Schneider Electric Exchange, the Developer Portal for the EcoStruxure Platform,” MIT CISR Working Paper No. 466, June 2024, https://cisr.mit.edu/publication/MIT_CISRwp466_SchneiderElectricExchange_MockerSebastian.[/foot]

This briefing compares these two approaches to help companies determine the best strategy to monetize their ExDPs.

The Appeal—and Challenge—of a Build-On Approach

With a build-on ExDP, a company enables its partners to create complementary solutions that enhance and expand the features of the company’s core offerings. For example, DocuSign built its app that facilitates electronically signing agreements directly within Salesforce’s CRM on Salesforce Platform in order to offer the app in Salesforce’s AppExchange marketplace. This approach benefits all parties: Partners such as DocuSign gain access to Salesforce’s more than 150,000 customers. Salesforce customers benefit from added functionality. And Salesforce captures value from network effects (i.e., when more partner offerings drive greater value for customers and vice versa) that create increased revenue through a 10 to 25 percent commission on partner app sales. Plus, Salesforce customers using partner apps are more likely to continue their CRM subscription. By 2023, 91 percent of Salesforce customers used AppExchange apps.

To realize the benefits of a build-on ExDP, companies such as Salesforce invest in multifaceted capabilities—such as a viable business model and a robust technology platform to which partners can add functionality, mechanisms for partners to seamlessly deploy their apps to customers, approaches for growing a vibrant developer community, and effective marketing and sales of the platform.[foot]Mocker and Sebastian, “How Salesforce Built Its Platform Business.”[/foot] Potential partners may hesitate to invest limited resources across multiple competing ecosystems, though, leading early-stage build-on platforms to struggle to gain traction; one reason the Blackberry and the Windows Phone platforms failed was their lack of third-party apps.[foot]Sascha Segan, “BlackBerry, Windows Phone Still Lack Popular Apps,” PCMag, March 14, 2013, accessed June 30, 2025, https://uk.pcmag.com/mobile-phones/16783/blackberry-windows-phone-still-lack-popular-apps.[/foot] Even if a critical mass of partners buys in, the ExDP owner must balance its internal priorities with the external interests of customers and partners and ensure the quality of partner offerings.[foot]M. Mocker and I. M. Sebastian, “Building a Platform Business Requires Balance: Lessons from Salesforce,” MIT CISR Research Briefing, Vol. XXIV, No. 6, June 2024, https://cisr.mit.edu/publication/2024_0601_SalesforcePlatformBusiness_MockerSebastian.[/foot]

Schneider Electric’s ExDP Monetization Journey

Schneider Electric’s EcoStruxure platform leverages Internet of Things (IoT) technologies embedded in Schneider products to deliver energy efficiency as a service to customers. In 2019, Schneider launched its Exchange portal based on EcoStruxure, positioning the portal as “the world’s first cross-industry open ecosystem dedicated to solving real-world sustainability and efficiency challenges.”[foot]“Schneider Electric Launches New Digital Ecosystem to Drive Worldwide Economies of Scale for IoT Solutions,” PR Newswire, April 1, 2019, https://www.prnewswire.com/news-releases/schneider-electric-launches-new-digital-ecosystem-to-drive-worldwide-economies-of-scale-for-iot-solutions-300821811.html.[/foot] The idea was to bring together “experts and innovators from across industry, software, and startups ... to develop, share, and sell digital and IoT innovations.”[foot]Ibid.[/foot]

A Build-On Approach to Launch Exchange

Schneider stood up Exchange using a build-on approach. Via Exchange, Schneider provided EcoStruxure APIs, private and public community access, and a digital marketplace. The company aimed to realize value both indirectly, by increasing the attractiveness of EcoStruxure-based products delivered through diverse partner offerings, and directly, through revenues generated by orchestrating the marketplace.

In 2022, Schneider realized that the initial vision for Exchange needed to be updated. For example, newly available easy-to-use payment solutions were making it straightforward for the company’s partners to sell and distribute their products via their own websites rather than on Exchange, reducing the value of Exchange as a marketplace. Also, Exchange was not agnostic to other providers’ IoT-connected products, forcing developers to commit to EcoStruxure products.

In 2023, Schneider acquired software company AVEVA Group Ltd. (AVEVA), which would ultimately address the agnosticism issue. The following year, AVEVA launched Connect, a platform designed to provide access to data and functionality from IoT-connected devices across many brands and serve as a marketplace for third-party industrial applications from partners.

The Shift to a Build-In Approach

In 2023, Schneider pivoted from its build-on approach to monetizing Exchange to a build-in approach, repositioning Exchange as EcoStruxure’s external developer portal. The portal would enable customers to access data or trigger functionality in their connected Schneider solutions via APIs.

A year before the pivot, Schneider had begun the transition to the new approach by developing a key capability: API productization. This process, in which technical APIs are transformed into commercial API products, involves defining an API’s operating model, monetization model, service-level agreements (SLAs), documentation, and support model:

• API operating model: specifies how customers gain access to API products, such as directly from Exchange or through regional sales teams
• Monetization model: defines the pricing of an API, such as by data volume, API call frequency, or the number of affected objects (such as buildings)
• SLAs: set expectations for API availability and performance, including execution speed
• Documentation: guides developers on proper use of the API, including parameters, return types of data, intended use cases, and sample code
• Support model: identifies who handles customer questions (e.g., Schneider’s central support team) and manages community forums for API users

Schneider created an Openness team to support API productization. Rather than centralizing accountability for API revenue, Schneider ensured that each business unit would be directly incentivized to monetize APIs relevant to their customers:

Schneider’s build-in approach for Exchange has primarily targeted indirect revenue from EcoStruxure customers who integrate data from their Schneider connected devices into their own applications via EcoStruxure APIs offered on Exchange. For example, a large retailer embeds EcoStruxure APIs into its proprietary software that remotely manages its Schneider devices (e.g., to adjust temperature). In fact, large customers have increasingly demanded that Schneider products include API-level access to data from the devices to use in company dashboards and integrate with data from other suppliers.

To also generate direct revenue, Schneider developed specialized APIs that offer clear monetizable value to customers. For example, one API enables customers to share building safety data with their insurance providers, which adjust the contract premium based on the reduced probability of a fire. By 2024, Schneider was monetizing fifteen APIs.

The Right Approach for Your Organization

Let us be clear: both build-on and build-in are valid approaches to monetizing ExDPs. Each approach provides very different opportunities, and each requires very different capabilities (see the table).

For many companies, providing customers with API access to product data is becoming a competitive necessity. Identifying opportunities to capture value by charging for APIs requires a deep understanding of customers’ needs and their willingness to pay. And don’t be fooled: A build-in approach involves far more than just publishing technical APIs on a website—it requires turning those APIs into productized commercial offerings. Many of your internal business colleagues may need to be convinced that monetizing APIs requires additional effort. Creating separate ExDP teams is common; when standing up its ExDP, Philips assigned a P&L-responsible general manager to the project early on.[foot]M. Mocker and J. W. Ross, “Transforming Royal Philips to Reinvent Healthcare in the Digital Age,” MIT CISR Working Paper No. 425, December 2017, https://cisr.mit.edu/publication/MIT_CISRwp425_PhilipsReinventingHealthcare_MockerRoss.[/foot] Maintaining a distinct team comes with the challenge of getting the rest of the company to see the value of and support your ExDP, though. Schneider addresses this challenge by accounting for ExDP revenue within the business units that provide the products for which the APIs were built.

A build-on ExDP promises network effects and the ability to capture value from partners. However, nurturing a committed ecosystem is an enormous effort, as Salesforce’s experience shows. And, as Schneider illustrates, partners might be hesitant to commit to a single-vendor platform.

For most companies not born as platform-providers, starting with a build-in approach will be prudent.

Table: A Comparison of Build-On and Build-In Approaches to Monetizing an External Developer Platform (ExPD)

© 2025 MIT Center for Information Systems Research, Mocker and Sebastian. MIT CISR Research Briefings are published monthly to update the center’s member organizations on current research projects.