Platforms, Journeys, and APIs

A platform is a business model that creates value by facilitating interactions between two or more participant groups, rather than by producing goods or services directly. Platforms provide the infrastructure, rules, and matching mechanisms that make those interactions possible.

Airbnb does not own hotels. Uber does not own vehicles. Amazon Marketplace does not own inventory. Each facilitates a transaction between supply (hosts, drivers, sellers) and demand (guests, riders, buyers). The platform captures a share of the value created by that facilitation.

Network effects are the mechanism by which platforms compound in value. Each additional participant makes the platform more valuable to all existing participants. Direct network effects (same-side): more drivers reduce wait times for all riders. Indirect network effects (cross-side): more buyers attract more sellers to Amazon Marketplace, making the selection better for all buyers.

Public sector platforms follow the same model. The NHS App is a platform connecting patients to services (GP booking, vaccination history, organ donation preferences, prescriptions). HMRC is a platform providing tax filing, VAT, PAYE, and self-assessment services through a single authenticated gateway. GOV.UK One Login is an identity platform. Each creates value by connecting participants, not by delivering a product.

A customer journey map is a visual representation of the steps a person takes to accomplish a goal, spanning every touchpoint with an organisation or service. A well-constructed map documents actions, emotional state, pain points, and the systems involved at each step.

Journey mapping should precede technology selection. Understanding the current journey reveals whether the problem requires a new application, an API integration, a process change, or no new technology at all. The DVLA vehicle tax renewal service illustrates this. Before its 2014 digital redesign, renewing vehicle tax required visiting a Post Office with a paper V5C reminder. The journey took an average of 25 minutes. Mapping the full journey revealed that the Post Office visit was a system constraint, not a user need. The digital service, built on the GOV.UK design system, reduced the journey to under three minutes. By 2021, over 98% of renewals were completed digitally.

GOV.UK Service Standard, Point 1 of 14, requires digital teams to "understand users and their needs" before designing a service. This is journey mapping institutionalised as a quality gate.

API-first design means designing the API contract before writing any implementation. The API is the primary product. The user interface, if one exists, is a consumer of that API rather than the source of its design.

API-last design produces the opposite: an application is built first and an API is bolted on afterwards as an integration mechanism. API-last APIs reflect the application's internal structure rather than the needs of API consumers. They use inconsistent naming, break with application releases, and generate integration friction from the first external consumer onward.

The GDS API technical standards require central government APIs to follow API-first principles: publish an OpenAPI 3.1 description, version using semver (Semantic Versioning, format MAJOR.MINOR.PATCH), and communicate breaking changes with deprecation notice periods of at least 12 months. These requirements apply to all APIs listed on api.gov.uk.

A webhook is a push-based notification mechanism: when an event occurs in a system, that system calls a URL registered by the consuming application. Stripe uses webhooks to notify merchants when a payment succeeds, fails, or is disputed. The merchant registers a callback URL; Stripe posts the event JSON payload to that URL when the event fires.

The alternative is polling: the consuming application repeatedly requests the producing system to check whether anything has changed. Polling introduces latency (missing events between poll intervals), generates unnecessary load on the producing system during quiet periods, and scales poorly as consumer count grows. For a fraud detection system that needs to act on a payment event within milliseconds, polling at 60-second intervals is not viable.

GitHub webhooks deliver build triggers, code review events, and deployment notifications to CI/CD pipelines. A push to a repository fires a webhook that triggers a build in GitHub Actions, Buildkite, or Jenkins. The push event is delivered within seconds; a polling approach would add latency proportional to the polling interval.

An API gateway sits between API consumers and backend services. It handles cross-cutting concerns that would otherwise be duplicated across every service: authentication and authorisation, rate limiting, request routing, protocol transformation, and logging.

Without a gateway, every backend service must implement its own authentication, rate limiting, and observability. In a microservices estate of 50 services, that is 50 independent authentication implementations that may be inconsistently maintained. A gateway implements these concerns once and applies them consistently to all traffic.

Kong (open-source, released 2015), AWS API Gateway (managed service), and Azure API Management are the most widely deployed solutions. The FCA's Open Banking directory required each of the nine CMA banks to deploy an Open Banking-compliant API gateway capable of handling third-party provider (TPP) authentication and consent management. That regulatory requirement standardised gateway patterns across UK retail banking.