An API marketplace designed for customers who might not be human

Telecoms grew up building a flow for every customer need. The API Marketplace was T-Mobile deciding to stop: open the systems themselves, let enterprise developers integrate directly — and design for a near future where the "user" placing a 10,000-line order might be a person, an AI agent, or both taking turns.

01Inverting the company

This wasn't a feature; it was the model turned inside out, touching effectively every part of the offering. The context that made it hard is the context that made it necessary: a marketing-first company running on roughly 200 codebases of legacy infrastructure, where every new customer need historically meant another bespoke build. A developer-first platform was the exit from that treadmill — and we could already see where MCP-style agent integration was heading: our future users would be a mix of human and AI.

02Decision: AI interprets, the interface confirms

The default path was the familiar one: forms. Enterprise admins manually keying employee and order data into UI screens, the way it had always worked. I argued we should stop designing for manual input at all — let customers hand us the data they already had, have frontier models interpret it, then show the interpretation back for confirmation and local edits.

The part I fought hardest for was where that confirmation lives. Chat alone couldn't carry it: a 5,000-line bulk change explained in a small conversational context window is a wall of words nobody can verify. I pushed for real-time UI as the confirmation surface — the model's interpretation rendered as live, editable, visual state, with conversation as an additional input channel rather than the only one. People confirm data they can see; they rubber-stamp data they can't.

03Decision: the data nobody wanted to touch

The slowest part of enterprise ordering was always the same: getting employee data into the system. The industry norm — ours included — was to avoid tying orders directly to user data at all; the security and compliance surface scared everyone. I pushed for an anonymized employee-data path: clients share what's needed for ordering without exposing identities, we integrate with their employee-data portals through the MCP layer, and the order builds itself around confirmed real needs.

That single change was the difference between an enterprise order taking 2–4 hours and taking 10–20 minutes. Early qualitative tests of the model-driven flow showed it resonating with exactly the users who had been burned by manual entry.

04Decision: making the economics and the lawyers say yes

Two objections could have killed it. Legal and compliance asked the right question — if our AI misinterprets an order, are we liable? And finance saw model token costs as an open-ended risk. The structure I argued for answered both at once: price the service, then waive the fee for the launch cohort in exchange for them stress-testing the system and accepting pilot terms. Partners got early access out of legacy systems their developers already wanted to leave; we got real-world error data under a controlled agreement, token-cost telemetry from real usage, and a value story — faster sales cycles, fewer botched orders to unwind — that could carry the future build-vs-open-source model decision.

05How it ended

Everything was built and ready to go. Then a reorganization and budget realignment cut the team — mine included — before launch. Whether it shipped after the handoff: unknown. I'm at peace with the work and not at peace with the timing, which is the lesson.

What I'd do differently: push harder and faster a year earlier. I treated organizational patience as a constant; it's a variable. If the pilot had launched before the reorg, the value would have been visible enough to defend itself. Speed isn't just a delivery concern — it's risk management against the org changing its mind.