API Product

For a long time, building a product meant building a screen. If there was nothing for a person to open and click, it didn't get called a product.

Some capabilities are worse off with a screen, though. Sending a text message. Authorizing a card payment. Turning a street address into coordinates on a map. Whoever needs those things is already building a product of their own, and wants the work to happen quietly inside it. Sending users off to another site to log in and come back breaks the flow they were in.

Pagedeck ran into this directly. It added electronic signatures to documents by popping open the signature vendor's site, and the share of people who made it all the way to a signed document fell by half. A second vendor had no screen at all. Send a request, a signature request gets created, a result comes back, and the screen the user sees is one Pagedeck drew itself. Drop-off went back to where it had been.

So selling the pipe without the screen settled in as one shape a product can take. In engineering terms, an application programming interface (API) is the agreed-on window two programs use to pass things to each other. An API product is that window put on sale with a price attached.

Four things, concretely.

1. Nothing breaks the flow. The customer's users finish the job inside the customer's own screens. For a payment or a signature, our name never appearing in the interface is a selling point rather than a loss.
2. Customers buy what they would otherwise have to build. Handling a card payment yourself drags in bank integrations, settlement, and regulatory work, and an API product turns the whole pile into one call. A team of five can spend a quarter on that and still not be ready for an audit.
3. It prices cleanly. Every call is already a record, which fits usage-based pricing — charging for what the customer actually consumed. Something like $2 per 1,000 requests lets a customer work out in advance what growth will cost.
4. It sticks once adopted. Our window is written into the customer's own source code, so switching means they have to edit it, test it, and ship again. At that point leaving isn't a purchasing decision, it's a release with a test plan attached, which is why a customer who is merely annoyed tends to stay.

Selling works differently too. No amount of advertising changes the fact that a developer opens the documentation first, copies the sample code, and leaves on the spot if ten minutes pass without one successful response. In this shape the docs are the landing page. A standard like OpenAPI — a machine-readable file listing every available call along with the values it takes and returns — earns its keep here, because one file produces both the documentation site and the client code customers paste into their own projects.

This isn't the only shell the same capability can ship in.

1. Web app — a screen a person works in through a browser. If the customer isn't a developer, a pipe with no screen reaches nobody. Selling to companies that have no engineers means at least one interface has to exist.
2. SDK — a software development kit, a bundle of code packaged to be embedded inside someone else's application. When part of the job has to happen on the device itself, which is common in mobile apps, a remote call isn't enough on its own.
3. Platform — opening your product so other people's features can run on top of it. The direction is reversed. An API product pushes our capability into someone else's product, while a platform pulls their capability into ours.
4. No-code integrations — wiring two services together by picking conditions on a screen instead of writing code. The pipe underneath is the same one, but a connector somebody else built sits in the middle, which brings the capability within reach of customers who have no developers.

Two questions decide it. Does the person paying write code, and where in their product does the capability have to sit? Work that can happen on a server is fine as a call. Work that has to happen on the user's own device needs something embedded.

"Let's ship this as an API product instead of building a screen. Customers want it inside their own interface."

A proposal to finish the job inside the customer's product rather than pulling their users over to ours.

"The docs are the landing page. Start by fixing the sample code."

The first screen a developer meets is documentation, so that's where the work goes.

"This outage didn't just stop us. Twelve services built on top of us went down with it."

One interruption reached all the way through to our customers' customers.

Pagedeck met this shape for the first time when it opened a way for other tools to pull content out of documents. What Mia spent the longest on wasn't the capability but the promises around it. Move a button on a screen and users find it again; rename one field in a public interface and the code at every company attached to it stops working that afternoon.

So three things got settled before anything went out. How much notice a specification change gets, how long the old shape keeps being accepted alongside the new one, and where an outage gets announced. Deciding those three took longer than building the capability did.

The most common mistake is treating an exposed interface as an API product on its own. It looks like less work than building a screen, which makes the assumption easy to fall into. But four things have to be bolted onto the interface before it's a product: documentation someone can read and follow, a published price, somewhere to ask when they get stuck, and a stated policy on when and how the specification can change. Publish a URL without those and the companies that connected to it eventually stop working because a response format changed quietly, and they don't come back.

Nearly as common is the idea that developers as customers means marketing doesn't matter, since good capability and good performance should win on the merits. What has actually happened is that the place where the choice gets made has moved. It's whether the sample code runs as pasted, whether a test environment opens without a signup, whether an error message says what went wrong. Put nobody on that work and a competitor with weaker capability and friendlier documentation takes the deal.