Twilio
Twilio Code Exchange: connecting working code to product adoption
Twilio · Developer experience, platform strategy, and self-service enablement
I led the revitalization of Twilio’s Code Exchange, a developer property scheduled for retirement, into a curated library of open-source applications developers could explore, deploy, and extend.
Outcome
41% month-over-month growth in organic views
The opportunity
Code Exchange served developers moving from understanding Twilio’s APIs to evaluating how they could use them in working applications.
Its role was middle-of-the-funnel enablement: help developers find a relevant implementation, deploy it, and build toward their own use case. That made it an important part of the path to product adoption and self-service revenue.
The property was set to be sunset. I saw an opportunity to renew its value by improving the applications, the browsing experience, and the connection to deployment.
What I owned
I set the direction for the revitalization and organized my team to evaluate the existing repository collection.
I decided to migrate the property from a custom Wagtail implementation to docs-as-code, collaborated with engineering teams in India on quick-deploy functionality, and worked with the Web Team on the new UI and subcontractor delivery.
The decisions behind the work
Establish repository quality before relaunch
I organized my team to audit approximately 200 existing repositories and determine which needed to be updated or deprecated before relaunch.
The application collection was central to the experience. A redesigned interface needed to lead developers to relevant, vetted implementations they could explore and extend.
Make the experience familiar to documentation users
Twilio’s core documentation site had recently migrated to docs-as-code. I chose the same approach for Code Exchange to align its user experience with the documentation developers already used.
Our hypothesis was that a familiar interface would create a more cohesive browsing experience as customers moved between documentation and working applications.
The platform decision supported that broader journey: learn about an API, explore an implementation, and move toward deployment.
Prioritize quick deploy as an adoption lever
Quick-deploy functionality was the primary product-adoption lever within Code Exchange. I collaborated with engineering teams in India to improve that experience as part of the redevelopment.
The objective was to help developers move from finding useful code to trying a working application with Twilio.
Coordinate delivery across teams
I worked with the Web Team to design the new UI and ensure the subcontractor adhered to a tight timeline.
The work required coordination across repository readiness, the publishing platform, the interface, and deployment functionality. Each contributed to the experience developers would encounter at relaunch.
The results
The revitalized catalog continued attracting developers after launch.
| Measure | Reported result |
|---|---|
| May 2026 organic views | Up 41% month over month |
| May 2026 organic views | Up 27% year over year |
| New repositories published in May | Zero |
| Week of May 10, 2026 | 8,811 organic views, up 29% week over week |
The May results demonstrated continued interest in the existing application collection, even during a month without new repository releases.
These figures measure discovery and engagement. They do not establish deployment completion or attributable revenue.
How the program evolved
After launch, we created Claude skills to help contributors generate the Markdown required for new repositories, extending our work into the contribution process.
We also continued investing in the existing collection. In May 2026, an agents.md skill was developed and 20 repositories queued for updates in June.
Measurement remained an area of development. We discussed tracking download intent and GitHub forks, and worked with engineering and analytics partners to clarify the relationship between Code Exchange usage, deployment, trial accounts, and self-service revenue.
Those discussions focused the program on what happened after discovery: whether developers used the applications and progressed toward meaningful product adoption.
What I learned
Design for the journey across properties
The decision to align Code Exchange with core documentation reflected a broader principle: developers experience the connections between properties, not just each property individually. Familiarity and continuity became explicit design goals alongside the needs of the repository catalog itself.
Treat the catalog as an ongoing product
The initial repository audit and subsequent maintenance plans made stewardship part of the program. Keeping existing applications useful deserves attention alongside adding new ones. The May results reinforced the importance of understanding the value already present in the catalog.
Match measurement to the program’s purpose
Traffic helped us understand discovery, but Code Exchange’s purpose extended into implementation and adoption.
Evaluating that purpose required clearer measurement of downloads, forks, deployments, and account progression. Our attribution discussions made those gaps visible and helped define the questions the program needed to answer next.