Platform

Before this word was common, every feature inside a product had to be built by the company that made the product. The shape of the problem is always the same: 400 open requests and ten engineers. Half of those requests are integrations that one or two customers care about — connect it to our time-tracking tool, post notifications into our internal chat.

Build it and someone maintains that code for years. Skip it and that customer leaves for something else. So prioritization meetings stalled in the same place every time. Someone says this really isn't ours to build, everyone agrees, and the item slides back to the bottom of the list because there is nobody else to build it.

A platform moves that list outside the company. Instead of building the features, you publish the sockets and the rules and let whoever needs a feature build it. Ten people holding 400 items becomes 300 of those items spread across 300 pairs of hands outside the building.

The problem a platform solves is that the number of features a product needs always runs past the number of hands available to build them. It solves that by building the standard those features plug into rather than the features. The company that designed the wall socket didn't build the world's appliances.

There are usually four kinds of room to open.

1. A call path. A way for outside code to read and write data, and the form in which that path is itself the product is an API product. Another company's program can pull a list of documents or push a new one in.
2. Event notifications. When something happens in the product, it posts to an address the other side registered. An approval system at the customer has to hear the moment a document is signed off before it can start the next step.
3. Room inside the screen. If the product is a web app running in the browser, the panel next to a document can be handed to someone else's app, so the user books a meeting or collects a signature without leaving the page.
4. A directory and a review. The list where users find what's been built, the review an app passes before it goes live, and the consent screen asking the user which data that app may touch.

Without the first three nothing can attach. Without the fourth, what attaches causes incidents. An app that quietly reads every document in an account becomes a security incident someone reports to you, not to whoever wrote the app.

Once this room is open, the value of the product stops tracking the company's own build speed. With 20 apps in the directory, the odds that a new customer's existing tools are on the list are low. At 200, almost any team that arrives finds one or two already connected. And once that team has wired three tools into the product, moving to a competitor stops being an account migration and becomes three integrations to rebuild.

A platform isn't the only answer, and for a product with few users it's usually the wrong one. Three other approaches solve the same problem.

Building it yourself comes first. Pick the ten most-requested integrations and build those. There is no documentation to maintain, no review queue, and no developer questions to answer, which makes this the cheapest route as long as few outside developers would have shown up anyway.

Working through an integration partner comes second. Rather than opening the door to everyone, you sign with one company whose product yours should connect to, and each side builds half of it. The numbers stay small, so quality stays even, and your name appears in front of that partner's customers as well.

Shipping an SDK comes third, and it runs the other direction. Instead of other people building on top of you, you package your own features into a development kit that gets embedded inside someone else's product.

What decides the choice is whether developers exist who would build. A product with 300 paying customers is not worth building an app for, because the entire market for that app sits inside those 300 accounts. At 30,000 the developers start arriving on their own. So the usual path starts with in-house integrations, adds a few partners, and only opens up once the requests clearly outrun what the company itself can build.

"Let's open this up as a platform instead of building it ourselves."

The customers asking for it can build it, and the engineering time goes somewhere else.

"Do we have enough users for anyone to build on us?"

The cost of opening up is certain, and whether anything attaches is not.

"We blocked that app in review — it asked for read access to every document."

Not everything that shows up gets in, and the review process is genuinely running.

Pagedeck opened an app directory in its third year. Theo shipped the call path and event notifications first and published documentation with working examples next to them. Eight apps went live over six months, and Pagedeck built six of them. Two came from outside.

Mia read that split as the expected order rather than a failure. Once apps started failing review, though, she had the consent screen rebuilt and added an admin view showing which app reads which data. That work exists because someone else's code now runs on top of their product.

The most common mistake is using the word to upgrade how a product sounds. Sales decks and pitch decks have used it to mean more than a simple tool for long enough that the habit sticks. But the label isn't settled by size or feature count. It's settled by what other people have built on top. A product with 300 features and nothing attached to it is a product. When that distinction blurs, the positioning changes while the roadmap doesn't, and the call paths and the review process that would make the word true stay unowned.

The second is expecting that opening up is enough to attract builders. From the other side, what matters first is whether the documentation is readable, whether questions get answered within days, and whether an app can earn anything. That's why the directory in year one is mostly filled by the company itself. Open the paths without that groundwork and the review and permission costs start on day one while nothing attaches for about a year.