How a Bug Got Me to Vercel Ship
Earlier this year, I attended Vercel Ship 2025 in New York City and it redefined everything I think about the web. It wasn’t just about frameworks or features, but the community behind them. That experience eventually led me to my first open-source contribution (and it was on the AI-SDK).
There’s actually a funny story on how I ended up there…
Back in May or June, I remember seeing all the hype for Ship and thinking, “I love Next.js, I’m local to NYC, and it’d be amazing to meet the builders behind the tools I use every day… but $600 for a tech conference?” I went back and forth on it for days. One night, while revisiting the registration site, I ran into a bug that somehow confirmed I was already registered. I tested it six more times just to be sure — and, after a good laugh (and a tweet), I found myself holding a free ticket.
Immersing in the Vercel Community
My newfound passion for developer relations and community truly began at Ship 2025. It wasn’t until that event that I really understood that “Everyone Can Cook”. Seriously — one of the biggest takeaways was seeing how literally everyone at Vercel ships. The PMs, the recruiters, the sales team — everyone was building something.
I got to see that firsthand during the workshops. In one called “Elevating Your E-Commerce” led by their Sales and Solutions Engineering team, I caught my first glimpse of the AI-first web in action — and it completely reshaped how I thought about what’s possible on the modern web.
That class completely changed what I thought made a website cool. Before Ship, I was obsessed with animations, 3D effects, and immersive visuals — anything that pushed the front-end to its limits. But the idea of an AI-first web reframed everything for me. The future wasn’t just about how a site looked; it was about how it responded.
What inspired me most was the idea that websites could now tell custom stories for every visitor. Generating tailored content, automating user journeys, and adapting workflows in real time were all examples of how AI could make the web feel personal, not just interactive.
I left Ship wanting to build with AI and my first stop was v0. It was the perfect playground to experiment with all my new ideas. I started sharing what I built in the Vercel Community, posting demos, writing tips, and helping other members troubleshoot their own projects. The more I built, the more I valued the power of community and collaboration.
A few weeks later, one of the AI-SDK maintainers opened an issue related to testing. It was the perfect opportunity to give back to the tools that inspire me. That PR became my first open-source contribution, and the start of a new journey that changed how I approach building for the web.
From Inspiration to Contribution
When I first saw the issue, it seemed straightforward. The team wanted to refactor the AI-SDK’s test suites, which were relying on global imports for Vitest and Chai. The goal was to externalize those dependencies across multiple files while keeping type safety intact.
The issue itself was well documented with helpful context from the maintainers, but getting all the tests to run properly took some digging. Addressing the imports alone wasn’t enough since the compiler targets also needed to be updated. That was tricky because changing them globally would have introduced a breaking change. One of the maintainers suggested exploring whether we could bump the targets only for the test builds, which turned out to be a subtle but meaningful distinction.
I started by externalizing Chai but quickly ran into a dependency resolution issue because Vitest was still bundled and couldn’t resolve Chai. The final solution was to externalize both, which ended up being a surprisingly elegant fix.
Separating the test builds didn’t just solve the issue; it also improved the developer experience. By decoupling test configurations from the main build, contributors could run and debug tests faster without interfering with production code. It made the SDK more maintainable, predictable, and welcoming for future contributors—exactly what great open source software should be.
Lessons Learned
Working on this PR taught me that open source is as much about collaboration as it is about code. What started as a small maintenance issue turned into a deep dive into testing, build configurations, and communication. I learned to slow down, ask questions, and understand the broader impact of a change before submitting a fix.
From a technical standpoint, I gained a better understanding of how testing environments can be isolated to improve reliability and developer experience. Separating the test builds wasn’t just a neat solution; it showed how thoughtful architecture choices can make it easier for others to contribute confidently.
More importantly, I saw how open source connects individual effort to collective progress. Every discussion, suggestion, and review helped shape the outcome. That sense of shared ownership reminded me why I fell in love with building in the first place.
Liked this article? Share it with a friend on Bluesky or X. Have a question, feedback or simply wish to contact me privately? Shoot me a DM and I'll do my best to get back to you.