I previously worked at Square for four and a half years, starting on the public-facing GraphQL API platform for external developers. Over time, I moved into the SDK pipeline, which is how I started working with Fern.
Before I started working on SDKs, the team made the call to switch from APIMatic to Fern SDKs. Cost was a factor, but so was SDK quality: the patterns and language idioms in APIMatic's output didn't match what we wanted. By the time I got involved, the team had already moved the Java, TypeScript, and Python SDKs over to Fern. I helped bring over Ruby and PHP, both new Fern offerings at the time. I also refined how Square's release automation integrated with the Fern CLI—reviewing and approving Fern's PRs into Square's SDK repos, coordinating around Square's existing release schedule, and eventually using Fern to build new APIs from scratch, not just migrate existing ones.
From customer to contributor
After leaving Square, I connected with Danny about contributing to Fern. I'd always been interested in working at a smaller company, and getting to contribute to a product I already knew well made it an easy yes.
A few things hit differently once you're actually working at a startup. The first is speed. When a task comes up, the Fern team pivots fast—there's no long discussion phase before someone starts prototyping. You go from "this is a problem" to "here's something that works" much quicker than I was used to. Decisions move fast because priorities are clear and customer-driven.
I ran into this myself early on: when I started profiling the performance of our SDK generators, I found myself re-running the same profiling a few days later because I hadn't written the results down. The natural next step was obvious: I kicked off a push to emit performance metrics and review them weekly, so we can spot regressions and measure improvements over time. At a bigger company, that might have gone into a backlog. Here, that observation just became my next project.
The second is ownership. When something breaks, there's no question of which team owns it. There's one team. Whoever knows the most about the problem swarms on it, fixes it, and moves on. It also shows up in releases: people coordinate quickly in-channel, sanity check risk, and move. Coming from a large company where ownership boundaries were clearly drawn—useful for accountability, but often slow in practice—that was a real shift, even though I expected it in theory.
What I'm working on today
I'm currently profiling the performance of Fern's SDK generators and setting us up to track improvements over time. When you're generating across multiple languages on every release, speed compounds—shaving a minute off one generator saves five or six minutes per cycle.
My other project right now is SDK previews. When a customer changes their API definition, they should be able to generate the SDK, inspect the output, and verify it's what they intended—before it ships to end users. The generated preview publishes to Fern's registry, so instead of sending files around, you can share an install link with a teammate and let them try it without publishing anything to a public registry.
Right now that loop is clunkier than it should be, and for teams shipping SDKs across five or six languages, every release multiplies the blast radius. Next, Fern will bring this into the GitHub Actions flow so that when someone opens a PR that changes their API spec, the preview generates automatically and shows up as a PR comment.
If building SDK tooling at scale sounds like your kind of problem, we're hiring.
