Why
Multiple teams produced APIs, and documentation processes were not yet established. As the product portfolio grew, this created a risk of inconsistent API design, fragmented content, and a site that would get harder to maintain.What
As the sole technical writer, I built the documentation function from the ground up. I produced the content and acted as subject matter expert, project manager, and platform owner for all public and internal documentation.How
I restructured the information architecture twice. The first iteration improved content hierarchy and navigation. The second rebuilt the homepage with custom Docusaurus components: clickable tiles, a mini table of contents, and skip-to-content. I split the top navigation into a Docs section for guides and an API section grouped by Trading, Market Data, and Institutional APIs. I added use-case navigation, reusable shared topics, and date-based release notes with RSS. I introduced release management with versioning and previews, so users get a predictable release schedule. I set up ticket templates, contribution workflows, and review processes across API teams. I launched an API governance initiative with staff engineers. It produced a living document covering naming conventions, authentication, rate limits, error handling, and backward-compatible change management.Result
The documentation function runs on clear standards and repeatable processes across all teams. I act as the de facto product manager and subject matter expert for docs.bitvavo.com, and I research, plan, and deliver all documentation independently.© 2026 Strahinja Milošević | Author of all-maker.com, a part of the tech writing blog webring