API parity is the new mobile-first

Every five years or so the customer-facing bar moves, and the move tends to be obvious in hindsight and contentious at the time. The shape of "what your product needs to expose" has shifted three times in twenty years, and we're now well into the fourth shift. Most teams haven't noticed yet, which is the good news if you're paying attention.

In the early 2000s the answer was a website with a decent UI. Get the buttons in roughly the right places, don't make Internet Explorer do anything unreasonable, and you were ahead of most of your competition. The mid-2010s pulled the rug out from under that. Mobile traffic crossed desktop, Google started ranking mobile-first, and a site that looked fine on a 24-inch monitor and unusable on a 5-inch screen quietly dropped out of consideration for half its market. The teams that resisted "this mobile thing" found themselves rebuilding their checkout under acquisition pressure two years later than the ones who'd just got on with it.

The next move was native apps, and for a long stretch a B2B API as a side project. Banks, marketplaces, and SaaS companies all worked out that if their customer was a business, the customer's actual user was a developer trying to integrate, and the polished UI they'd spent eight months on was at best a demo for the procurement call. So the API got built, usually grudgingly, usually as a thin slice of the real product, with rate limits set by people who'd never used an API in anger and documentation that lagged the UI by six months. Most of those APIs still cover maybe sixty percent of what the UI does, somebody forgets to add the new field to the create endpoint after a pricing change, and a customer's nightly batch job silently breaks. The pattern's familiar enough that nobody's surprised any more.

That was 2018-ish, and that's roughly where most companies still are.

Where the bar actually sits now

The bar in 2026 is different in two ways at once, and the second one is the one most people are missing.

The first shift is that "ninety percent API parity" is no longer good enough. If your customers are increasingly automating against you (and they are, because their staff are doing it whether you've sanctioned it or not), then the missing ten percent is the part that matters. It's always the obscure flag, the bulk operation, the thing one specific customer needs once a quarter and absolutely cannot do without. Full UI-to-API parity, where every action a user can take in your app has an equivalent endpoint with the same authorisation rules and the same rate limits, used to be a luxury the API-first companies had to themselves. It's now the floor.

The second shift is agentic access. Your customers are increasingly not humans clicking buttons, nor scripts hitting endpoints, but agents acting on a human's behalf. The agent might be Claude in their terminal, an Operator session running overnight, or a custom thing their internal platform team wired up six months ago and quietly forgot about. Either way, the agent doesn't want to read your API docs, parse your OpenAPI spec, and figure out the auth dance from cold. It wants to discover your capabilities, read structured descriptions of what each one does, and call them safely with the right scopes. That's what MCP and Agent Skills are for, and that's the surface buyers are starting to ask about by name.

Procurement questions in 2026 increasingly include "do you have an MCP server?", and they tend to come before the pricing conversation. Two years ago the equivalent was "do you have a Zapier integration?". Five years before that it was "do you have an API?". The shape of the question keeps moving up the abstraction stack, and the company with the answer ready wins the deal.

What "agentic access" actually looks like

For a working approximation, your product wants three projections of the same underlying domain logic:

• A UI for humans, where the affordances are visual and the trust model is "this person has logged in".
• A REST or GraphQL API with full parity to that UI, where every action is reachable, scoped to fine-grained permissions, and documented well enough that an LLM can read the spec and write a working client without help.
• An MCP server (or an equivalent skill manifest) that exposes the same operations as discoverable tools, with rich descriptions, sensible defaults, and explicit guards on the destructive ones.

The mistake most teams make is treating these as three products. They aren't. They're three projections of the same product, and any drift between them eventually surfaces as a bug, a security gap, or a customer asking why the API can't do something they can do in the UI. The discipline is to build the domain layer once, expose it three ways, and make the parity tests fail loudly when somebody adds a feature to one surface and forgets the other two.

The eighteen-month window

If you're shipping a product to paying customers right now, this isn't a "nice to have, plan for it next year" problem. The buyers asking about MCP support today are the same kind of buyers who asked about mobile in 2014 and asked about REST APIs in 2009, and the lag between "first customer asks" and "a third of pipeline asks" tends to be around eighteen months, same as it was for those.

The order matters: build the API parity first because it's the foundation, and the agentic layer becomes nearly free once the underlying surface is uniform. Skip the parity, bolt an MCP server on as a marketing exercise, and you'll spend the next two years apologising for the seventeen things the agent can't actually do.

If you're sitting on a product that's currently UI-first with a partial API, we should talk. We've been building exactly this surface for our own products, and the pattern transfers.