Projects
Why
The existing Bitvavo documentation was a Redocly free-tier site that had very basic API reference information.
REST and WebSocket content shared a single-scroll page with no clear protocol separation,
missing or incorrect code samples, and ambiguous authentication guidance. For a crypto exchange
competing on developer trust, this was a critical gap with no owner to address it.
What
There was no established docs tooling, no publishing pipeline, and little institutional knowledge
to build on. The platform needed to support REST, WebSocket, and later FIX protocols — each with
distinct structural and UX requirements — while integrating into company infrastructure
built on Terraform, Kubernetes, and Cloudflare.
How
After evaluating multiple SSGs and API documentation tools, I selected Docusaurus with
docusaurus-openapi-docs plugin and rewrote the full API reference, splitting REST and WebSocket
into distinct, purpose-built sections. WebSocket posed a specific challenge: AsyncAPI
was not mature enough in early 2025, so I adapted the OpenAPI YAML structure to represent
WebSocket channels and swizzled Docusaurus components to render them correctly for that
protocol's logic hiding the REST API testing panel and adding dedicate
I built the publishing pipeline using Terraform, Kubernetes, and Cloudflare, with separate
staging and production environments, and a PR preview workflow that generates a GitHub Pages
preview per labelled pull request — updating on every commit and deleting automatically on merge.
I implemented Algolia search with extensive crawler tuning, added a PushFeedback widget
with a dedicated docs@bitvavo.com address for direct user communication, and certified
Bitvavo's Postman collections — earning the Postman Verified checkmark and remaining
the sole maintainer.
Result
The platform now covers multiple REST, WebSocket, and FIX APIs across trading, market data,
and institutional domains. The site grew from fewer than 100 to over 60,000 users,
adding more than 6,000 new monthly users.
Why
With multiple API-producing teams and no established documentation processes,
there was a real risk of inconsistent API design, fragmented content, and a
site that would become harder to maintain as the product portfolio grew.
What
As the sole technical writer, I needed to build the documentation function from
the ground up — not only producing content, but acting simultaneously as SME,
project manager, and platform owner across all public and internal documentation.
How
I restructured the site's information architecture twice. The first iteration
improved content hierarchy and navigation. The second rebuilt the site with a
new homepage using custom Docusaurus components — clickable tiles, a mini-TOC,
and skip-to-content — and reorganized the top navigation into a Docs section
for guides and an API section categorized by Trading, Market Data, and
Institutional APIs.
I introduced release management with versioning and sneak previews to give users
a predictable release schedule. I established ticket templates, contribution
workflows, and review processes across API teams. I also led an API governance
initiative with staff engineers, producing a living document covering naming
conventions, authentication, rate limits, error handling, and
backward-compatible change management.
Result
The documentation function now operates with clear standards and repeatable
processes across all teams. I serve as the de facto product manager and SME
for docs.bitvavo.com, independently researching, planning, and delivering
all documentation without external direction.
Why
The Terminal API is foundational to in-person payments, but its legacy structure made it difficult to understand,
maintain, and integrate with modern developer tooling. Improving its accessibility was critical for long-term
platform scalability and developer trust.
What
The Terminal API is based on the
nexo retailer protocol,
not REST. For years, its only reference lived on a single page assembled from many HTML files, making it hard to
navigate and incompatible with our OpenAPI-based API Explorer.
How
I mapped the full API structure by reconciling the official nexo PDF specification, existing documentation, and
the OpenAPI requirements of our API Explorer tooling. I coordinated work between the team owning the Terminal API
implementation in C and the platform team responsible for API reference pipelines.
We created a Python script to generate OpenAPI specs our tooling could consume and introduced a new page type in
the API Explorer to present the API structure by request type.
Result
The migration brought a critical legacy API into the standard developer experience without altering its
underlying protocol. It reduced long-term maintenance risk, improved discoverability, and increased confidence
in a globally used payments API.
Why
NFC integrations are prone to failure due to subtle differences between card types, terminal hardware, and
operating systems. Clear guidance here directly reduces integration errors and support load.
What
Developers must construct four different request types (identify, read, write, or session), each with
card-specific data structures. In addition, Adyen terminals run two operating systems that do not always offer
feature parity.
How
I structured the documentation around user intent rather than API shape, organizing the page so developers
could quickly identify the correct combination of card type, terminal type, and request type using existing CMS
components.
Result
The resulting documentation reduced cognitive load in a complex integration flow and improved task completion
for a feature area with a high potential for implementation errors.
Logistics API reference: internal docs with no public footprint
Why
The Logistics API enabled Adyen’s supply chain to automate delivery workflows and replace an aging messaging
system under a fixed deadline, while remaining inaccessible to the public.
What
The API needed to be documented and usable by partners without appearing in official API reference tooling.
Additionally, the API was still under development when documentation work began.
How
I authored the API reference directly from Stoplight mockups and designed an information architecture that made
the API discoverable only to intended users through navigation and structure rather than tooling.
I also identified inconsistencies across endpoints and led efforts to simplify request and response schemas to
improve integrability.
Result
The documentation enabled partners to migrate off the legacy system before the planned deadline and influenced
API design decisions that made integrations easier and more reliable.
Why
Navigation friction was preventing users from finding critical in-person payments content despite high overall
traffic, negatively affecting usability and confidence.
What
The left-side navigation contained 67 items under 10 labels, creating cognitive overload and making it difficult
for users to locate relevant information.
How
With a writer colleague, I conducted interviews with internal stakeholders and direct clients to understand how
users consume content. We validated findings against Google Analytics data and rebuilt the information
architecture around clearer conceptual groupings.
Result
The new structure reduced navigation items from 67 to 47 under 7 labels. One year after launch, analytics showed
a substantial decrease in negative feedback, increased traffic to previously underused areas, and an overall
traffic increase of approximately 25% across the IPP section.
Why
ProGlove’s products were scaling faster than its documentation infrastructure, creating risk for onboarding,
support, and partner integrations.
What
When I joined, documentation consisted of minimal content on a static MkDocs site. As the sole writer, I was
responsible for tooling, content creation, structure, reviews, and delivery across hardware, software, and
APIs.
How
I introduced Paligo to enable scalable authoring and faster review cycles, migrated all existing content using
Pandoc and custom scripts, designed a new information architecture for the full product portfolio, and
implemented OpenAPI references for public APIs.
I also customized HTML and CSS to align the documentation portal with the company’s visual identity.
Result
Within a year, ProGlove had a professional, multi-product documentation portal with versioning, release notes,
media, and automatically updated API references, supported by sustainable documentation practices.
