Catching up with Danny Sheridan from Fern

Hello, and welcome back to APIs you won't hate. My name is Mike Biko one of your APIs you won't hate. Co-hosts, co-founders, whatever you wanna call me. Today I'm sitting down to chat with my good friend Danny Sheridan from Fern. Danny's been on the show before about six months ago. We talked in March of 2023, shortly after I believe Danny, you had just finished going through Y Combinator's Winter Batch for this year. And it's great to have you back.

I am ecstatic today. I think that as we talked last, like you said, six months ago. My team was just coming out of the Y Combinator program. We were able to use that acceleration that they provide to go raise the seed round of fundraising. And at this point, we've been growing the business by increasing the number of customers that we work with, which we can talk about today, as well as expanding the functionality that Fern provides for companies that have public rest APIs.

Love that. Yeah, I'm, I'm super interested to get into it. As you know you know, we're, we're big API fans around here, so nerding out on this stuff is definitely in the wheelhouse. Before we do that, let's take a step back and why don't you tell me the audience listeners about Fern from a 1 0 1 0 1 level, what is Fern? What is it for, and who would be interested in it?

Yeah, I think the best way to start there is to talk about the inspiration from Fern, which is that I was at AWS as a product manager before Co-founding Fern, and my co-founder, whose name is Deep, was at Palantir Technologies as an engineer. And one of the things that both of us got to experience was that Palantir and AWS. Both design APIs, starting with the API specification or the API contract, they don't start by writing backend server code. They don't start by writing API documentation.

Yeah. I think if you've browsed it once or twice, it's probably apparent that either someone from a different universe made some of them, or they're, they're not necessarily human generated. Yeah.

It was really inspiring to me, though, to see an example. a human is not responsible for updating the docs anytime that the API changes because at Amazon we had that concept of good intentions, which is that good intentions. Mike, when someone says, anytime we change the API, we will remember to update the docs. Good intentions fail because people are busy

That's

and instead Exactly. And instead, what we should be doing is having tooling. That supports us in accomplishing our goals. And so Fern is a way where companies with public rest APIs use Fern to offer SDKs in popular programming languages and API documentation that documents those rest APIs.

I think our listeners will identify with this quite a bit. I think we're in an interesting, like. Point in history, this sort of inflection point where maybe even between now and the last time you and I chatted I think something has happened sort of in like the, the general public mindset that people suddenly trust machines to do more intelligent things.

let's talk about the biggest objections that I hear when I talk to customers or prospects specifically about Fern. One of the objections that is common is I don't trust a machine to generate my SDK. My developer experience is important to my business. It increases our revenue if we can acquire new customers, and I don't wanna trust that to something that. eVery time I run the code generator could have a different output. Right. And what I tell people is, Fern does not use LLMs to generate code.

Hmm.

We have bitten, we have built a rule-based system and if we're getting more specific, we built a compiler that takes in an open API spec and generates TypeScript or Python or Java files.

Yeah.

And so one of the important things to folks right now is determinism. I run the fern generator more than one time, will I get the same SDK output? If, if the SDK would change every time because of determinism, that, that would be a, a major blocker to adoption. And so right now, the most popular way is to generate SDKs are all, there is no L-L-M-S-D-K generation tooling that has become popular. Not to say it can't happen one day.

Yeah, that's an important point too. And I'll make sure we have notes on a link to fern's GitHub in our show notes so our listeners can go and kind of browse that and, you know, also contribute if if they're so inclined. Yeah, I think, I think that's. A valuable point to make that like deterministic LLMs are not a thing in, in the current state of the art.

aNd Mike, I'm thinking about one of our customers. The company is called Cohere. They're an AI platform for enterprises that is growing in popularity. They are LLM experts and they have chosen fern and do not wanna use LLMs to produce their SDKs because their main source of revenue is their API

Yeah,

and a problem in their SDK would literally impact their ability to generate income. And so they, they, they were almost willing to put an engineer against it when they saw that they could, instead of having to build. SDKs by hand. They could buy an SDK generation tool. They opted to buy and not build. And I think you're right.

Yeah, definitely. Definitely.

do this by hand. This is a, a ticket in our engineering queue. And I think that there's been a shift in the last 18 months where more engineering leaders, this typically is happening at the CTO or an engineering manager, platform engineer who says there are now tools like Fern where I can pass in an open API specification. I can get out high quality idiomatic SDKs that I'm comfortable putting in front of my customers.

Sure. Yeah. I think also worth pointing out that even the discussion you and I had six months ago has changed pretty dramatically in as much as back then at least, I don't think we talked too much about documentation either. But I feel like that's maybe part of like the, the holistic picture of providing great developer experience to people consuming your client libraries, whether they're internal or external to your company.

Mike, you said kind of who is the gold standard, who is the ideal right now for developer experience, and I think that over the last at least three years, the answer has not changed. The company with the best developer experience in the world is Stripe.

yeah, sure. sure.

think that folks would find that agreeable, but Mike disagree on the why. Mike, you have to reason through it together.

Let's do it. And before we get into that, this is probably where I should mention. I'm a former Stripe employee. No bad blood between me and Stripe, or me and Danny as far as I know, at least but you know, a reasonable call out here too. Yeah. Let's reason through it. Walk me through it.

Let's talk about this as if we're making a, a recipe and the outcome is the Stripe developer experience. I think the question, Mike, is what are the inputs.

Cool. Yeah.

And I usually like to speak in threes, but in this case, I've got five things on my mind that make the Stripe developer experience exceptional.

Yeah, hit me.

The first is consistent design, whichever endpoints you're using within Stripe's, vast API, you can expect similar behavior and patterns, like you'll learn it once and you learned it across the whole API and any endpoint you use.

Yeah.

To do, especially as a company grows over. I mean, Mike, they're well over a decade old, right?

Sure. Yeah, absolutely. Yeah, pat patterns are huge. And you know, much like you'd imagine in some places there are teams of developers maintaining client libraries. And at AWS there are teams of people starting with that API spec. The discussion on consistency is massive at Stripe. Making sure that things make sense from one to the other so that end users can learn one pattern and apply it everywhere is super, super valuable.

The second is documentation. Developers expect that they, it's easy to find what they're looking for and that the information is up to date. It's very frustrating when you go and check out what the JSON looks like for an API response, and it's wrong because some developer changed it and forgot to update the docs. And so Stripe has done a phenomenal job of. Automating their documentation and they have a whole team responsible for it.

Yeah. Yeah, definitely. If you are reasonably good at Googling, you can find a, a talk I did on Stripe's internal documentation tools on YouTube somewhere.

The third thing are SDKs in popular languages, whether you are a Java, a Python, or a Ruby developer, you get a client library that's got auto complete. Immediately, and you get that when you're starting your project. SDKs tend to make integrations happen in 50% less time, and Stripe understands that by my last count, they supported seven different languages or frameworks that they provide SDKs for.

Yeah, that sounds about right. Yeah. And then to, to that point too, idiomatic SDKs are important, right? Like, it feels like python, it feels like ruby, when you're writing in that language. And that's, that's a hard thing to to accomplish just as well.

All right. The fourth thing of five errors. When you run into an error in the stripe, API, the message that's output to the developer, it's actually helpful. It typically links you to a place in their documentation. So it's like documentation aware. It'll give you AURL where you can go to read more and it might even recommend a fix as part of the error message. And that's just, um, Mike, it might be craft, that's the word on my mind.

Yeah, sure. sure. I think so. And, and that was a revelation too, right? Like this was not a common thing. In a world before stripes developer SDKs existed, like oftentimes as a API consumer. Your job was to set debuggers run console logs and pull your hair out until you figured out what, what comma was missing or what type you had incorrect, or you know, what you had done wrong. And at best you maybe got a 500 back. Something like that. Yeah.

And the fifth thing, Mike, that's on my mind is around versioning. When you start, when you open your Stripe account, your pin to a version of the API, and from that day on you are, they expect that you'll be using that API version, and you have to choose to take an upgrade. And so Stripe does a phenomenal job of having backwards compatibility. They've actually built tooling that they call gating that we can talk more about in another episode if you'd like to in.

Sure.

They've, to date, they've never broken their API. And I think that's a really expensive decision because it, you learn a lot after 10 plus years of doing business. And I'm sure there are moments that they would've loved to break the API, but to date they have not.

Yeah, yeah. The, those, so let me let me see if I can kind of sum that up then. So, versioning error messaging, client, libraries, docs and the fifth one is escaping me. A design right. Consistency are are definitely adding up for that the magic. That's, that's the experience I want my engineering team to have. That's also the experience I want from every client library I consume from a third party service as well.

Yeah, but Mike, how many employees does Stripe have?

Engineers. We have four right now.

Sorry. At Stripe.

Oh, it's Stripe. Oh, sorry. Yeah, yeah, yeah. Stripe. Gosh, rounding out a few thousand easily, I think probably close to five or 6,000.

Yeah. So let's compare craft work to stripe's engineering ability, maybe I'll call it four to a thousand, something like that ratio. It's really, it's not feasible for companies to hire engineers to go build this developer experience infrastructure. For their company. And so that is why the market is turning to buy a solution that's available for you. And Fern is filling that place in the market. And so the, the idea of Fern is that we will bring a stripe like developer experience to your API.

Yeah. That's, that's incredible. That's, that's quite an offering and, and a bold statement to make. And I think what I wanna know from you is like, what, what are your consumers need to provide? How do they, how do they get that? What's

They provide, they provide an open API spec.

Hmm. I.

We generate SDKs and we generate the API docs. Additionally, if they want to, they can provide markdown files, which will be the pages in their documentation if they'd like to do things like how to get started. How to authenticate with our API. Maybe they have item potency. Those are some of the examples that we tend to see how pagination works. So they can add custom pages in addition to their API reference. And in my mind, Mike SDKs and API docs are like peanut butter and jelly.

Sure. Yeah. So are you able to share any stories about customers that you've had who are using Fern?

Absolutely. How about we talk about, I mentioned cohere already, so I'll pick another one. hOw about merge Dev to give a little? Are you familiar with that, Mike?

Past guests of APIs you and hate. We have, we recorded an episode with them maybe a year and a half ago at this point.

Oh, was that my hunch was probably either Shei or Gale, the CTO.

It was Gil. Yeah. We chatted with Gil on, on APIs, you and hate. Yeah.

Fantastic.

In case someone hasn't listened though, what's the 1, 1 0 1 on merge? What do they do? I.

Yeah, merge is a fast growing company that developed a unified API that simplifies integration development. So there are a lot of popular SaaS products out there that you might want to integrate with. And I'll just give an example. If I wanna add ACRM integration to my app, I might want to connect with Salesforce data, or HubSpot data, or Pipedrive data. And so for me to go build integrations with each of those three is pretty burdensome on my engineering team. And instead I can go use Merge.

Yeah, from, from what I remember, talking to GI Merge, they have a astonishing number of third parties that they unify into one place to call, at, at the time when we chatted, it was like dozens upon dozens, and I'm sure it's grown since then. It's, it's definitely a big product.

WE can talk about the, the problem that merge came to us with, a merge customer uses the merge SDK and not a Salesforce or a HubSpot, SDK,

Right.

instead of having to deal with those

place.

Exactly. You call 'em all from one place. Well, that means that merge needs, I'm gonna call it a kick ass SDK. They need to have an extremely developer friendly, well document consistent across all languages experience. But they are API experts. They're not necessarily SDK experts, and so they teamed up with the firm team and they move really quickly. Merge is a fast moving company from first initial call with us to learn about what we do to actually going live with.

Yeah, my God.

at this point they've now released a node, Python, Java, go, SDK, using Fern, and we're together collaborating on C Sharp and Ruby as the next languages that'll come out. It's pretty nice when you have a customer who pushes you to increase selection.

Yeah, definitely. Right. So, so with that then, it sounds like you've probably expanded the languages that Fern has delivered on since March as well, right?

We have since we last talked, we've added Python and go and we will continue adding languages. It feels like after the top eight to 10 programming languages, there's a pretty big drop off.

That's probably fair. Yeah.

but I could see us using a good chunk of 2024 to get there to that top eight or 10.

Cool. Okay, so, so Merge is a a fern user and they've, they've then delivered their SDKs in, in four weeks. Is is honestly a staggering turnaround for something like that. Like if you're listening to the show, you should hop over to merge.dev and like browse, scroll to the bottom of the page. The footer of their page shows how many APIs they integrate with.

Yeah, we generate hundreds of endpoints for them every time that they generate code with us. And one of the things that I want to call out is at, I was at AWS before this, as I mentioned, at AWS Andy Jassy used to talk to the team that the most successful implementations of AWS happened when it was top down. It's just too hard for cloud infrastructure to go bottom up.

Yeah, that's the right rights kind of investment and clearly shows you know, a pattern for success too, and that it worked and, and that merges now user of Fern. That's, that's really exciting. So you, you now have a client library product and a Docs product. I. For people listening to the show. We also mentioned before that you to, to get started with Fern, you need an open API spec. What does it look like to get started? How long does that take?

Yeah it, you install an NPM package, which is the Fern CLI command line interface. then you run a command called Fern Generate and that takes your open API spec and starts generating a list of generators that you specify. So it takes about five minutes to get started. Pretty often what our customers figure out is that their open API spec is of pretty poor quality.

For sure. Yeah, it's aspirational. Definitely intentional, you know, a lot of, a lot of companies want to do it, and in practice it's tricky. It's a bit like starting with test driven development, like it's, it sounds like a great idea, but it's hard to get people to commit to it.

I'll give two examples of where I think open API specs that I've seen fall short just to, to make it tangible for folks. The first is that they mention a bunch of different properties of an object and they don't add a description of what that property is. And I don't know your API as well as, you know, your API, and so I need some help. I need a human readable description. Age means like is age in days and months and years. It's really helpful.

Yeah.

like very high value. But in order for. Fe to know what a response looks like. We need companies in their open, API specs to include an example for each endpoint and the great, the great customers that we work with that really want the exceptional developer experience make that part of their, like their, they can't ship update API without improving, without updating their open API spec. And then improving things like description fields and examples.

Yeah, I'd imagine that's a bit of a cathartic experience too, because it's effectively like forcing people to invest in their own reduction of tech debt. You know, we, we all have this notion that we want to do a great job of these things, but frankly, like human readable descriptions that make sense and examples and things like that fall by the wayside pretty quickly when you're under the gun to get things done. But that'll turn around if the tooling takes. Those things end.

Mike, do you see a world where LLMs could be helpful here, where it's like, help me add some descriptions and help me add some examples.

Sure. Yeah, yeah, yeah. That, that's definitely a place where I think people would be excited to you know, to to, to add that sort of ai magic on top of things. And maybe an, an interesting application of that too. I could see maybe even something where you're, you're chatting with your code base, like, Hey, how would I. Do whatever it is, like take an ACH payment from someone in Japan. Right? Like, how do, how do I do that? What does that look like?

You just touched on something that I think is just probably a billion dollar idea, so let's explore it for a minute together.

yeah. Far away.

Today API documentation is like an encyclopedia.

Yeah.

It's got a bunch of informations and, and a bunch of pages, and it's your responsibility to go either look at the table of contents or look at the glossary, kinda like the search bar, and you have to go find what you're looking for, get to the right section, read it, and digest it.

Yeah.

I speculate that instead of an encyclopedia experience where you have to like go find the right page. You're gonna be able to ask a question to the encyclopedia. I mean, this is what SIR and Alexa wanted to be back then, right? I can just ask a question and it goes and finds the information and presents it to me. And I could see a future where you get to someone's API docs and there's a text input.

No. And I think that the, those tend to be, for me at least, the most exciting applications of this LLM technology is where, where it's a second brain that actually is a second brain, right? Like in the past few years people have talked a lot about note taking and self-organization and things like notion and. Rome research and obsidian and, and being really good about documenting what you're seeing.

I, I'll make a speculation here. 'cause it's fun to guess about the future, isn't it?

No, always. Yeah.

I think that the number one consumer of API documentation in the future, we'll call it three years from now, is going to be LLMs.

Hmm. That's really interesting. Wow. Well, I guess we're gonna have to put it on the calendar to have you back on the podcast in three years, but I'd, I'd love to have you back sooner if, if that's something you're interested in.

I,

Danny, let, let's do this. So tell me about if people are interested in jumping in and getting started with Fern, where's the best place to go?

the best place to go is our website, which is build with fern.com.

We will of course have that in the show notes along with all the other things we've mentioned here today. One other thing I, I like to ask guests on the show is is Fern growing? Are you hiring at the moment?

Fern is growing. We are looking for a founding backend engineer. This person would work with our team in New York City. It's an onsite role, and they would be responsible for helping us expand selection of our SDK generators. So we're looking for someone who's excited to be a polyglot that might jump within a week between Java, Python, and Ruby, and is excited about languages and has a high attention to detail.

Yeah. Very cool that that sounds like a great opportunity.

And, And, lastly, Mike, I'll, I'll share that the salary range that we're paying for that role we publish, which is 130 to $160,000 a year, in addition to a half percent to 1% equity in a growing startup.

Brilliant. How's that for Open? I'm, I'm, I deeply appreciate that. I think especially in a world where lots of people are squirming to find the right place for them getting to that discussion around like, what does compensation look like? Where do you want me to be and what am I gonna be doing? It's really hard to get to and, and I think a lot of companies. Can and should aspire to what you just did there. We'll drop a, a link in the show notes as well to the job opening here too.

The best place to talk to me is actually going to the build with fern.com website and scheduling a call. Would love to ch if folks listen to this and they're like, Hey, I'm ready. I'm ready to make my API developer experience more like stripes. That's, if that's the intention, that's the place. Best place to find me is just book a call. Let's hop on.

Yeah. That is an opportunity not to be passed up friends, I think Danny a, apart from being a, a very exciting person to chat with, I think you're also super knowledgeable and it's been great to have you hang out. I'm looking forward to six months from now seeing how you've shaped the, the planet of API developer experience in that marketplace too. Thanks for joining so much. I appreciate having you here. And looking forward to talking again,

Let's build APIs that people will love.

add away into it. All right, Denny, take care.

Cheers.