पाठशाला Pathshala · उत्पाद Utpād, The product · Lesson 22 · Scale
Platform and API strategy: when to let others build on you
An API, a marketplace or a layer of integrations can make customers stay and partners sell. It can also become a second product with no revenue line. Decide by the retention it buys against the upkeep it costs.
Pathshala, The Founder Library · 11 October 2026 · 7 min read
Every software company past its first few hundred customers is asked the same question by a customer, a partner or an investor: can others build on you? The flattering answer is yes, we are a platform. The useful answer depends on what the company would be opening, to whom, and whether the retention or distribution it buys is worth the engineering it will consume for years.
This lesson separates the three things founders mean by platform, sets out what each costs, gives a way to check whether an integration layer pays for itself, works an example from Indian payroll software, lists the signals that it is time to open an API, and closes with a quarterly review.
What a platform is, and what it usually is not
Ben Thompson’s The Bill Gates Line records the strictest definition, a line Chamath Palihapitiya attributes to Bill Gates: a platform is when the economic value of everybody that uses it exceeds the value of the company that creates it. Thompson contrasts platforms, which enable connections between outside suppliers and users, with aggregators, which intermediate and control them. Very few startups will ever meet it, and none needs to in order to benefit from letting others connect to its product.
What most companies actually need sits on a ladder of three rungs. Integrations you build: connections to the systems your customers already use, written and maintained by your team. A public API: documented endpoints that customers, agencies and partners use to build what you will not. A marketplace: a directory where third parties publish apps for your customers and, usually, sell them. Each rung multiplies both the potential and the upkeep, and each should be climbed only when the one below it is working.
The cost nobody budgets
An API is a promise. Once a customer’s system depends on an endpoint, changing it breaks their business, and they will hold you responsible. Stripe’s engineering team described in 2017 how it handles the promise: each account is pinned to the API version current at its first request, and every backwards-incompatible change is wrapped in a module that translates new responses back into old ones. Stripe said it had maintained compatibility with every version of its API since 2011, through almost a hundred backwards-incompatible upgrades in six years, and was candid about the price: every new version is more code to understand and maintain.
Integrations carry a second cost: the other side changes too. A partner deprecates an endpoint, changes its rate limits or alters a data format, and your support queue fills with tickets about a system you do not control. A marketplace adds a third: partner review, security checks on apps that touch your customers’ data, a payout system, and disputes when a partner’s app fails. Shopify’s revenue-share terms show how much of this a large platform absorbs to attract builders: from 1 January 2025, developers keep all of their first US$1 million of app revenue and pay 15 per cent above it. A startup cannot subsidise partners on that scale, which is one reason marketplaces come late.
Does the integration layer pay?
The case for integrations is almost always retention: a customer whose payroll, accounting and attendance are connected through your product has more to undo before leaving. That claim can be measured. Compare monthly churn for customers who use at least one integration with customers who use none, matched by size and by how long they have been customers, because engaged customers adopt integrations and would have stayed anyway. If the gap survives matching, the figure turns it into rupees and sets them against the engineering the integrations consume.
At the defaults, 2,000 customers at ₹8,000 a month with 30 per cent using integrations, the halved churn keeps about ₹48 lakh of revenue in the first year. Twelve integrations at two upkeep days a month, plus their build, cost about ₹58 lakh. The layer loses money in year one, though the monthly revenue it protects keeps rising. Cut the integrations to the five customers actually use and the same retention costs ₹24 lakh. The pattern is general: a few deep integrations that most customers use pay; a long tail of shallow ones that a handful use do not, and every one of them still breaks when the partner changes something.
Every endpoint you publish is a promise you will keep paying for. Open one only when the retention or distribution it buys is larger than the promise.
A worked example: payroll software in Pune
A Pune company sells payroll and compliance software to 1,800 manufacturing firms at an average of ₹9,000 a month. Its customers keep accounts in Tally, attendance in biometric devices from several makers, and bank with a dozen banks. For three years the team built integrations as customers asked; it now maintains 23, and two engineers spend most of their time on them.
The review finds that four integrations, Tally, the two most common biometric devices and bulk salary upload for the three largest banks treated as one, cover 85 per cent of integration usage. Customers using any of the four churn at 1.2 per cent a month against 2.6 per cent for matched customers using none. The other nineteen together serve 140 customers. The team keeps and deepens the four, gives notice on eleven of the rest with a CSV route as replacement, and publishes a small read-only API for the remaining cases, so that customers’ own IT staff and local implementation partners can build what the company will not. Two implementation partners in Pune and Nashik build connectors for regional attendance systems within a quarter.
The company did not become a platform in Gates’s sense. It freed one engineer, kept the retention that the integrations bought, and gave the long tail to people better placed to serve it. A marketplace stays off the roadmap until partners are earning enough from its customers to want one.
Signals that it is time to open the API
Four signals justify a public API. Customers are already building on you badly: scheduled exports, scraped screens, shared logins used by scripts. They have shown demand and are creating support load either way. Agencies or implementation partners ask because their clients want something you will not build. Enterprise deals stall on it: security and IT teams want a documented way to move data in and out. A specific partner will commit to building on it within a quarter. Without at least two of these, an API is a cost waiting for a user.
When you open one, start read-only, version it from the first day, publish a deprecation policy before anyone asks, and rate-limit by customer. Treat it as a product with an owner, a changelog and its own usage numbers. A marketplace waits until third parties are already making money on your customers and asking for distribution; then it is a way to formalise what is happening, rather than a hope that it will.
Two design choices decide whether an API becomes a support burden. Push before pull: most integration requests are really requests to know when something happened, a payslip generated, an invoice paid, a shipment delivered. Webhooks that announce those events cover a large share of use cases with far less surface than a full read and write API, and they keep partners from polling you every minute. A sandbox and real documentation: every question a partner cannot answer from the documentation becomes a ticket for your engineers. A test environment with sample data, examples in the two or three languages your partners use and an error message that says what to fix will save more engineering time than any other investment in the layer. Budget for both before launch, and name the person who owns the documentation as clearly as the person who owns the code.
The quarterly platform review
Once a quarter, list every integration and every API consumer with four numbers each: customers using it, engineer-days spent on it, support tickets it caused and the churn gap for its users against matched non-users. Rank by customers served per engineer-day. Retire the bottom of the list with notice and a replacement route. For the API, track active keys, calls, the share of enterprise deals that used it and the number of breaking changes shipped, which should be zero. Re-read the four signals and decide whether to climb a rung, stay or step down. Write the decision in one paragraph and keep it with the last quarter’s, so the company can see whether its platform is a growth engine or a habit.
The figure is a simplified model and the Pune company is illustrative. Shopify’s terms are as published, checked 10 October 2026.
Sources
- Ben Thompson, The Bill Gates Line, Stratechery, 23 May 2018
- Brandur Leach, APIs as infrastructure: future-proofing Stripe with versioning, Stripe blog, August 2017 — Compatibility kept with every version since 2011; almost a hundred backwards-incompatible upgrades in six years.
- Shopify, App Store revenue share (checked 10 October 2026) — 0 per cent on the first US$1 million of app revenue from 1 January 2025, 15 per cent above it.