Process
01 — Discovery & competitor benchmarking
Started with a deep competitor analysis — how third-party API providers structured onboarding flows, authentication patterns, code samples across languages, error response conventions, and the boundary between developer-facing and business-facing content. Given the short delivery timeline, I went wide and fast on the internal side too: interviews with Inpay's six development teams, plus pain points and client concerns funnelled through KAMs, Support, and the Onboarding team.
02 — Terminology overhaul & information architecture
With a dedicated external tech writer brought in to support the project — a first for Inpay's API documentation — I initiated a terminology overhaul.
A decade of vocabulary inherited from the company's developer-driven startup era no longer matched the current product portfolio or business voice. Endpoint names themselves stayed put — renaming them across a live payment ecosystem would have been a solid but unnecessary engineering exercise, with real risk to existing partner integrations and version management. But the user-facing language had to move. I got stakeholders on board to migrate the partner-facing surface: 'disbursement' became 'payout', 'collection' became 'payin' — aligning with the words partners actually use and the way Marketing already talks about the products externally.
Not a one-day workshop, but a strategy-level decision: to make future product launches faster, and to keep the documentation legible to more than just the developers who originally wrote it. A partner now hears the same word in the marketing site, the dashboard, the API reference, and the support thread — even when the underlying endpoint in the request payload still reflects the older convention.
Rebuilt the information architecture around clear onboarding paths, a structured API reference, and a sandbox environment so the new vocabulary landed inside a system that made it easy to find.
03 — Daily build with engineering, onboarding & KAMs
Shipped on a daily cadence with engineering — dynamic code samples, X.509 certificate authentication, a self-serve sandbox environment, and a live API reference with inline request/response samples. Equally close collaboration with the Onboarding team and Key Account Managers, who absorbed every documentation gap as a support ticket.
That collaboration produced one of the most concrete wins of the project. After careful negotiation with the Onboarding team, I initiated a Support content page inside the developer portal — collecting the most-asked FAQs and making them externally accessible. Previously, a developer hitting a wall had to email or schedule a call with a Support manager, get authenticated access to the Customer app, and dig through Zendesk guides to find an answer. Moving that knowledge into the open portal closed the loop — partners self-served, and the Onboarding team focused on the cases that actually needed a human.
Trade-offs were made transparently: where bespoke was worth building, where standard patterns sufficed, and where developer experience needed to override visual consistency.
04 — Marketing alignment & stakeholder management
Negotiated with the Marketing team to add a non-technical "APIs for business stakeholders" page on inpay.com — explaining what the APIs unlock commercially, and why a self-serve developer portal matters in a fast-paced payments market where adoption scales through developer experience. Throughout the project, navigated a leadership team change mid-stream and managed stakeholders across product, engineering, compliance, marketing, and sales — keeping the work moving without losing the original problem.
