Catching up with Danny Sheridan from Fern

[00:00:00] Mike Bifulco: 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

[00:00:08] Mike Bifulco: 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.

[00:00:23] And it's great to have you back. I'm really excited to, to hear what's happened since then. And what's going on with you? How are you doing today?

[00:00:28] Danny Sheridan: 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.

[00:00:59] Mike Bifulco: Love that. Yeah, [00:01:00] 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?

[00:01:15] What is it for, and who would be interested in it?

[00:01:17] Danny Sheridan: 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. Instead, they start in A-A-J-S-O-N or a YAML file describing the [00:02:00] endpoints, the data models. And the errors that can be thrown by those endpoints.

[00:02:06] And so that was a big inspiration. I wanna give, we stand on the shoulders of giants here at Fern and specifically we do that with Amazon's Smithy, which is an open source project they created. And Palantir's Conjure and Mike, we'll include those in the show notes for folks that wanna check 'em out. Both, both of them are, are in-house built tools. AWS and Palantir that really showed us the power of going API first, they allow a front end and backend engineer, maybe even a product manager to collaborate on designing the API. And then once the API contract is established, you run it through code generation technology and those code generators produce a couple of different artifacts. They can produce server boilerplate code. that looks like maybe you're using the Java springing [00:03:00] framework or the TypeScript Express, or even Python's fast, API. And you wanna take my API contract and make sure that I create all of those routes and I'm implementing them.

[00:03:13] The second thing that those tools created were client libraries.

[00:03:16] So these are the SDKs. It's nice to have a typed client that you get auto complete in your ID of whichever you're using. Typically, we see VS code as the most popular. But when I like hit, when I'm using the SDK, it'll show me all of the resources that are available and the operations that I can perform on those resources.

[00:03:35] And so that might be like payment create. And that's a really nice developer experience because they don't have to leave. Their IDE while they're coding to go check what the documentation says. It's part of the SDK and they, they've kind of got docs on hover where they can see details about each, each of those resources or operations, uh, how they behave. And the third [00:04:00] thing, Mike, is in addition to some server code and SDKs, is that these tools, these conjure and SMITHY tools from the companies that I mentioned, produced a version of API documentation. In AWS's case, it was literally the A-W-S-A-P-I docs. I don't think it'll be a surprise to folks and Mike, tell me if I'm wrong, that AWS does not hand write all of their API documentation and their API reference.

[00:04:25] Mike Bifulco: 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.

[00:04:34] Danny Sheridan: 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

[00:04:50] is that good intentions. Mike, when someone says, anytime we change the API, we will remember to update the docs. Good

[00:04:57] intentions fail because people [00:05:00] are busy

[00:05:00] Mike Bifulco: That's

[00:05:00] Danny Sheridan: 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.

[00:05:23] Mike Bifulco: 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.

[00:05:42] And by that I mean like the, the zeitgeist of AI tools, AI wrappers for everything has made people a lot more lenient to let the the, the . Software, write things for them, create things for them, do creative work, do work. That was prior quite manual tasks. And I think Fern is happening at a really interesting [00:06:00] time in that inflection where suddenly it's like, oh, actually maybe I can run my, my open API spec through something and it can generate client libraries and also maybe generate meaningful documentation where I think if you asked me that two years ago, I would've been like, not a chance.

[00:06:14] I'm gonna hire an army of technical writers and they're gonna do a great job for me on this. I'm curious to hear your sort of feelings on that and, and also your feelings on like the, the world of working with people who are generating code as opposed to writing code manually too.

[00:06:28] Danny Sheridan: let's talk about the biggest objections that I hear

[00:06:31] 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 [00:07:00] is, Fern does not use LLMs to generate code.

[00:07:04] Mike Bifulco: Hmm.

[00:07:05] Danny Sheridan: 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.

[00:07:18] Mike Bifulco: Yeah.

[00:07:19] Danny Sheridan: 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.

[00:07:48] Not to say it can't happen one day. I think folks want determinism and then they also wanna see why, like why did the code generator output a specific line of code? [00:08:00] And they really like being able to poke into the open source source code. And so Fern is open source because our customers are developers and they like to see how the magic happens.

[00:08:09] Mike Bifulco: 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.

[00:08:28] They may one day be, I don't know if that's even possible based on, you know, what an LLM technically is, but you want your generated libraries to be predictable and the same and by that nature also testable. And I feel like that's something that probably comes out of people using Fern is you can generate a library and if you can generate it the same every time, you can test it and be certain that what you're getting is something that at least passes the tests that, that you've provided.

[00:08:50] Danny Sheridan: 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. [00:09:00] 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

[00:09:10] Mike Bifulco: Yeah,

[00:09:11] Danny Sheridan: and a problem in their SDK would literally impact their ability to generate income.

[00:09:17] 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

[00:09:30] opted to buy and not build.

[00:09:31] And I think you're right. You mentioned things are changing around the API developer experience market, should we call it that

[00:09:39] the developer experience market um, things

[00:09:41] around SDKs, API documentation. We are seeing a shift where in the past companies would've said, and we've been working on FERN for 18 months now. 18 months ago, my folks would've said. We, the only option to provide great SDKs is to put an engineer against it.

[00:09:58] Mike Bifulco: Yeah, definitely. [00:10:00] Definitely.

[00:10:00] Danny Sheridan: do this by hand. This is a, a ticket in our engineering queue.

[00:10:04] 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.

[00:10:29] Mike Bifulco: 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.

[00:10:49] GEtting both a functioning client library and then the documentation to build it is the story. That's, that's the story. You need to have both of those things for your thing to be valuable. And, and I think there's probably like, I [00:11:00] don't know. I would imagine you've probably seen patterns in your customers that they're probably all looking for like a platonic ideal that they want to have, you know, great developer experience and great documentation to go with it.

[00:11:09] What, what does that like lifecycle look like for maybe finding, acquiring and, and delivering solutions to your customers?

[00:11:17] Danny Sheridan: Mike, you said kind of who is the gold standard, who is the ideal

[00:11:21] 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.

[00:11:33] Mike Bifulco: yeah, sure.

[00:11:34] sure.

[00:11:35] Danny Sheridan: think

[00:11:35] that folks would find that agreeable, but Mike disagree on the why. Mike, you have to

[00:11:41] reason through it together.

[00:11:43] Mike Bifulco: 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.

[00:11:56] Danny Sheridan: Let's talk about this as if we're making [00:12:00] a, a recipe and the outcome is the Stripe developer experience. I think the question, Mike, is what are the inputs.

[00:12:06] Mike Bifulco: Cool. Yeah.

[00:12:08] Danny Sheridan: 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.

[00:12:16] Mike Bifulco: Yeah, hit me.

[00:12:18] Danny Sheridan: 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.

[00:12:35] Mike Bifulco: Yeah.

[00:12:36] Danny Sheridan: To do, especially as a company grows over. I mean, Mike, they're well over a decade old, right?

[00:12:42] Mike Bifulco: 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 [00:13:00] end users can learn one pattern and apply it everywhere is super, super valuable.

[00:13:06] Danny Sheridan: 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

[00:13:23] 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.

[00:13:35] Mike Bifulco: 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.

[00:13:45] Danny Sheridan: 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. [00:14:00] 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.

[00:14:17] Mike Bifulco: 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.

[00:14:31] Danny Sheridan: 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, [00:15:00] Mike, it might be craft, that's the word on my mind.

[00:15:04] Mike Bifulco: 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.

[00:15:27] And at best you maybe got a 500 back. Something like that. Yeah.

[00:15:32] Danny Sheridan: 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.[00:16:00]

[00:16:00] Mike Bifulco: Sure.

[00:16:01] Danny Sheridan: 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.

[00:16:16] Mike Bifulco: 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.

[00:16:35] That's also the experience I want from every client library I consume from a third party service as well.

[00:16:40] Danny Sheridan: Yeah, but Mike, how many employees does Stripe have?

[00:16:43] Mike Bifulco: Engineers. We have four right now.

[00:16:45] Danny Sheridan: Sorry. At Stripe.

[00:16:46] Mike Bifulco: 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.

[00:16:52] Danny Sheridan: Yeah. So

[00:16:53] let's compare craft work to stripe's

[00:16:55] engineering ability, maybe I'll call it four to a thousand, something like that ratio.[00:17:00]

[00:17:00] It's really,

[00:17:01] it's not feasible for companies to hire engineers to go build this developer experience infrastructure.

[00:17:10] 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. We will do that over. That's, that's the vision that we are working toward. And today we will deliver two things for our customers SDKs in multiple languages that are idiomatic. We take care of publishing them to NPM and Maven Central and So we take care of getting 'em to the package managers and publishing the source code to GitHub. And the second product that we offer is API documentation. Everyone wants the Stripe like Docs website that fits your, it matches your brand.

[00:17:52] You've got the infinite scrolling page. You can see the SDKs documented in the API reference. That's a [00:18:00] really nice feature, Mike. And Stripe does in a way where it's auto-populated.

[00:18:04] So human does not have to go and update the code snippets in all seven SDK languages for every endpoint. Whenever the API changes,

[00:18:12] they have automation for that. And that's something that Fern has now rolled out for our customers is you can get what we call code snippets for every endpoint showing how to use your SDK in any of the languages that you generated for an SDK for.

[00:18:26] Mike Bifulco: 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

[00:18:38] Danny Sheridan: They provide, they provide an open API spec.

[00:18:41] Mike Bifulco: Hmm. I.

[00:18:42] Danny Sheridan: 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

Marker

[00:18:57] Danny Sheridan: potency.

[00:18:58] Those are some of the examples that we tend to see [00:19:00] 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. They just go better when they're together. You can have 'em separately, but

[00:19:20] it's really nice when your SDKs, yeah, when the SDKs are documented next to the API reference, it feels most natural as a developer that wants to go figure out, how do I integrate with this company's API.

[00:19:32] Mike Bifulco: Sure. Yeah. So are you able to share any stories about customers that you've had who are using Fern?

[00:19:39] Danny Sheridan: Absolutely. How about we talk about, I mentioned cohere already, so I'll pick another one. hOw about merge Dev to

[00:19:46] give a little? Are you familiar with that,

[00:19:48] Mike?

[00:19:49] Mike Bifulco: 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.

[00:19:54] Danny Sheridan: Oh, was that my hunch was probably either Shei or Gale, the CTO.

[00:19:59] Mike Bifulco: It was Gil. Yeah. We [00:20:00] chatted with Gil on, on APIs, you and hate. Yeah.

[00:20:02] Danny Sheridan: Fantastic.

[00:20:03] Mike Bifulco: In case someone hasn't listened though, what's the 1, 1 0 1 on merge? What do they do? I.

[00:20:07] Danny Sheridan: 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. And so Merge is the, is a unified API platform and is the difference between building one integration with Just Merge or building 10 with multiple different SaaS tools that have changing APIs.

[00:20:50] Mike Bifulco: 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 [00:21:00] chatted, it was like dozens upon dozens, and I'm sure it's grown since then. It's, it's definitely a big product.

[00:21:05] Danny Sheridan: 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,

[00:21:17] Mike Bifulco: Right.

[00:21:17] Danny Sheridan: instead of having to deal with those

[00:21:19] Mike Bifulco: place.

[00:21:20] Danny Sheridan: 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. Was a four week time period, so really impressive at the speed that they've been able to move.

[00:21:54] Mike Bifulco: Yeah,

[00:21:54] my God.

[00:21:56] Danny Sheridan: at this point they've now released a node, Python, [00:22:00] 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.

[00:22:12] Mike Bifulco: 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?

[00:22:20] Danny Sheridan: We have

[00:22:20] 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.

[00:22:31] Mike Bifulco: That's probably fair. Yeah.

[00:22:32] Danny Sheridan: but I could see us using a good chunk of 2024 to get there to that top eight or 10.

[00:22:37] Mike Bifulco: 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.

[00:22:54] The footer of their page shows how many APIs they integrate with. And it is . Like conservatively [00:23:00] a hundred different, different APIs they pull into merge, which must mean that Fern is generating like mountains of API client library and documentation for them as well.

[00:23:08] Danny Sheridan: Yeah, we generate hundreds of endpoints for them every time that they generate code with us.

[00:23:12] 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.

[00:23:33] You need a C-level goal, such as the CTO or CIO setting a goal that gets everyone on the same North Star of like getting to the cloud. And in this case, we see the same trend happening with SDKs. It's really hard to go bottoms up. It's really easy when a leader like Gil from Merge says, Hey, everyone. We are using Fern, we're going all in on offering every SDK language. They, [00:24:00] they provide and puts an engineer. Actually in our case, there was an engineer and an engineering manager that we got to work with to go live with each of their SDKs. And I think that's just the right approach as a leader to identify like a single threaded leader who's gonna be responsible for this SDK project going from first meeting to completion.

[00:24:20] Mike Bifulco: 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.

[00:24:36] 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?

[00:24:44] Danny Sheridan: 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 [00:25:00] about five minutes to get started. Pretty often what our customers figure out is that their open API spec is of pretty poor quality. I

[00:25:11] mean that this is like a trend that you've talked about on this show a lot

[00:25:15] and that you've written about of their, having an open API spec is not the same as having a high quality open API spec for your organization.

[00:25:23] Mike Bifulco: 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.

[00:25:36] Danny Sheridan: I'll give two examples of where I think open API specs that I've seen fall short just to, to make it tangible

[00:25:40] 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.

[00:25:52] And I don't know your API as well as, you know, your API, and so I need some help.

[00:25:56] I need a human readable description. Age [00:26:00] means like is age in days and months and years. It's really helpful. You know, an integer for age isn't very clear to me as a developer what I should be put using there.

[00:26:07] And so one of the things that we see as a room for improvement is adding description fields across the entire API spec. The second area of improvement are adding examples. really helpful as a developer to see an example JS om response,

[00:26:23] Mike Bifulco: Yeah.

[00:26:24] Danny Sheridan: 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.

[00:26:52] And then improving things like description fields and examples.

[00:26:56] Mike Bifulco: Yeah, I'd imagine that's a bit of a cathartic experience too, because it's effectively like [00:27:00] 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.

[00:27:14] But that'll turn around if the tooling takes. Those things end. Multiplies the value of it for you. Right. And, and I think that's what Fern at least, is purporting to do here, and I think that's a really exciting offering.

[00:27:25] Danny Sheridan: 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.

[00:27:31] Mike Bifulco: 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.

[00:27:47] 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? And, and if your documentation is in order and your open API spec is well written, I think that's something that, that is not too far off in the future [00:28:00] for us.

[00:28:00] Danny Sheridan: You just touched on something that I think is just probably a billion dollar idea, so let's explore

[00:28:06] it for a minute together.

[00:28:07] Mike Bifulco: yeah. Far away.

[00:28:09] Danny Sheridan: Today API documentation is like an encyclopedia.

[00:28:13] Mike Bifulco: Yeah.

[00:28:14] Danny Sheridan: 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.

[00:28:30] Mike Bifulco: Yeah.

[00:28:31] Danny Sheridan: 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. And that text input allows you to ask a question like, I'm using Jango to call the [00:29:00] Stripe API as an example. Well, let's pick the merge dev API I'm using to call your API. I wanna migrate, I wanna use the HubSpot and Salesforce integration to go create new leads and it starts writing code for you, basically a sample app of how you would, and you get to share that, right?

[00:29:22] It's gonna use the Python, SDK 'cause it's, it knows you're in a Python framework

[00:29:26] and it's going to live, generate you code that you can start using that you would never find in their docs. It's actually combining some of the word description guides with the API reference with the SDKs that now like an LLM Power Docs understands all of those things to me.

[00:29:43] The day that we can go and, and like you said, have a conversation about what are you trying to accomplish here at Docs? Congrats. You've landed. What are you trying to do here? That is not an experience that I've ever seen.

[00:29:55] Have you?

[00:29:56] Mike Bifulco: No. And I think that the, those tend to be, for me at least, the most exciting [00:30:00] 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.

[00:30:12] Rome research and obsidian and, and being really good about documenting what you're seeing. But when the L LMS start putting that together for you and take the need to document yourself out of the picture and can become an educator for you, I think that's really interesting and really empowering.

[00:30:27] And, and I can see lots of different people getting into development as a result of that too, and I'm really excited by that.

[00:30:33] Danny Sheridan: I, I'll make a speculation here. 'cause it's fun to guess about the future, isn't it?

[00:30:38] Mike Bifulco: No, always. Yeah.

[00:30:40] Danny Sheridan: 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.

[00:30:49] Mike Bifulco: 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.

[00:30:59] Danny Sheridan: I,[00:31:00]

[00:31:00] Mike Bifulco: 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?

[00:31:06] Danny Sheridan: the best place to go is our website, which is build with fern.com.

[00:31:11] Mike Bifulco: 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?

[00:31:21] Danny Sheridan: 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.

[00:31:48] Mike Bifulco: Yeah. Very cool that that sounds like a great opportunity.

[00:31:52] Danny Sheridan: And, And,

[00:31:52] lastly, Mike, I'll,

[00:31:53] I'll share that

[00:31:54] the salary range that we're paying for that role we publish, which is 130 to [00:32:00] $160,000 a year, in addition to a half percent to 1% equity in a growing startup.

[00:32:06] Mike Bifulco: 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?

[00:32:18] 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. And Danny, where, where's the best place to get at you? If people want to shout at you about SDKs or documentation, where, where can you be found online?

[00:32:35] Danny Sheridan: The best place to talk to me is actually going to the build with fern.com website

[00:32:40] 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.

[00:32:54] Let's hop on.

[00:32:55] Mike Bifulco: Yeah. That is an opportunity not to be passed up friends, I think . Danny a, [00:33:00] 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.

[00:33:11] Thanks for joining so much. I appreciate having you here. And looking forward to talking again,

[00:33:15] Danny Sheridan: Let's build APIs that people will love.

[00:33:19] Mike Bifulco: add away into it. All right, Denny, take care.

[00:33:21] Danny Sheridan: Cheers.