Developer Platform & API
An API developers actually want to integrate
An infrastructure SaaS client
A B2B infrastructure company had a great UI product and a market that was trying to integrate it programmatically. They had hand-written PHP-shaped REST endpoints, no SDKs, and documentation that was a static page from 2019. I designed an API-first surface from scratch with OpenAPI as the single source of truth, generated SDKs in three languages from that spec, and shipped a docs site with runnable examples and a sandbox tenant. The API became the top acquisition channel within six months.
This is a representative architecture study based on real project patterns. Specific metrics and client details have been generalized to protect confidentiality.
Results
What changed, in numbers
The metrics the engagement is measured by.
70%
API Adoption
of new customers use API first
2 hours
Time to Integrate
average time to first call
-60%
Support Tickets
reduction in integration tickets
72
Developer NPS
developer satisfaction score
Challenge
What was broken
The product had escaped from its UI. Customers wanted to embed it in their workflows but were copy-pasting reverse-engineered HTTP calls. Every integration generated support tickets. There was no contract: endpoints changed shape between releases, and there was no way to deprecate gracefully. The company couldn't sell into the platform-engineering buyer because there was no platform.
Solution
The shape of the fix
A complete developer platform with REST and GraphQL APIs from a single OpenAPI spec, three idiomatic SDKs, an interactive docs site with a live sandbox, and the telemetry to actually measure developer experience.
Approach
How I tackled it
The concrete moves that took the project from broken to shipped.
Ran a discovery sprint with 20 prospective integrators to map the workflows they actually wanted to automate
Designed the API surface in OpenAPI before a single endpoint shipped, and reviewed it with developer-experience expertise
Generated TypeScript, Python, and Go SDKs from the spec, with idiomatic patterns rather than auto-generated stubs
Built the docs site on Next.js with runnable code samples that hit a live sandbox tenant
Added a versioning and deprecation policy with telemetry so removals could be data-driven
Instrumented every endpoint and every SDK call so PM could see funnel metrics from signup to first successful API call
Outcomes
What shipped, and what it changed
Measured results from the engagement, told as a story rather than a scoreboard.
70% of new customers integrated via the API before touching the UI within six months of launch
Reduced average time-to-first-successful-API-call from days to ~2 hours
Cut integration-related support tickets by 60% on a per-customer basis
Developer NPS measured at 72 on a population of 800 integrators
Enabled three new partnership deals that required programmatic access as a precondition
Stack
Technologies used
Linked entries open the technology page with related studies, playbooks, and notes.
Services
How I helped
The specific services involved in this engagement. Each links to a deeper breakdown.
Lessons
What I would tell the next team
The takeaways I carry into every similar engagement.
Spec-first is the only way. If your spec and your code disagree, your customers will find out before you do
Auto-generated SDKs are not idiomatic SDKs. The wrapper layer is where developer experience lives
Time-to-first-call is the only DX metric that matters in the first week
Related
Other studies you might recognize
Engagements with overlapping problem shapes, industries, or stacks.
Have a similar challenge?
If any of this looks like the project on your desk, the conversation is the cheapest part. You can also browse other developer tools work or the full service list.