Bump.sh serves as the single source of truth in API ecosystems, synchronizing both people and tools. As developers navigate increasingly complex API ecosystems, collaboration becomes more challenging. Bump.sh's mission is to facilitate developer collaboration, creating superior API ecosystems through a comprehensive suite of API tools.
AI exploration
i led the company's first serious AI exploration: picking the use case, evaluating models, and prototyping the experience. the use case i converged on was helping technical writers draft accurate, complete API descriptions from raw spec data. high-friction work, well-defined output, and writers were already in the tool every day.
the design problem under it was less about generation and more about privacy and trust. a meaningful share of our customers exposed internal APIs that could not be sent to a public model. i evaluated Cohere, Claude, and Llama against that constraint and shaped a draft, review, ship loop that kept human in the loop where it mattered, while removing the parts that were busywork. that framing stuck. automate the typing, keep the thinking. it became how i thought about every AI surface i designed afterward.
API documentation
i designed the documentation experience alongside our engineering team and a product manager. the surface had to support every API spec format we accepted, at any size, and present complex technical information clearly enough for the human reading it on the other end of the spec.
the conceptual challenge was harder than the technical one. documentation that updates itself only feels intelligent if the structure of the page anticipates what the reader is looking for. most of the design time went into the navigation, the scan-pattern of the right hand examples column, and the dark/light hierarchy. the parts that look invisible when they work.
API changelog
i led the design and a chunk of the front-end implementation for the changelog product, in a team of nine. it was the most opinionated piece of work i did at Bump.
an API diff is information dense and easy to do wrong. the previous version showed every change as a flat list, which technically reflected the data but didn't reflect how engineers actually read a diff. by status first, by scope, then by detail. i redesigned the hierarchy from scratch. status order first, breaking, then non-breaking, then cosmetic. then a clearer visual treatment of additions, removals, and modifications. then progressive disclosure for the long tail of details. on mobile, the same hierarchy collapses into a stack rather than fanning out.
Change between versions
i led design and shipped front-end on the change between versions feature, in a team of three (myself plus a back-end and a front-end engineer). the goal was simple but underserved. let API consumers compare any two versions of a contract directly inside the documentation, without leaving the doc for a separate tool.
Onboarding
i directed the design and research on the new onboarding, working closely with our product manager. we built the redesign on top of a friction log of the existing journey: every step where a new user paused, scrolled looking for something, or asked a question in support.
the redesigned flow surfaces the moment of "ah, here's the value" sooner. for Bump that meant the first time a developer saw their own API documented automatically, and we restructured the funnel to get them there in fewer steps.
Branding
i led the in-house rebrand and shipped the marketing materials alongside it: web pages, ads, kakemonos, swag. most of it coded directly rather than handed off.
