WEBVTT NOTE This file was generated by Descript 00:00:02.460 --> 00:00:05.010 Mike: Hello everyone and welcome back to APIs you won't hate. 00:00:05.010 --> 00:00:06.480 My name is Mike Fulco. 00:00:06.485 --> 00:00:09.957 Your APIs you won't hate guide on this mystery tour we're on. 00:00:09.957 --> 00:00:12.747 Today I have the distinct pleasure of sitting down and chatting 00:00:12.752 --> 00:00:14.547 with Danny Sheridan from Fern. 00:00:14.847 --> 00:00:15.627 Danny, it's nice to meet you. 00:00:15.627 --> 00:00:16.257 How are you doing today? 00:00:17.357 --> 00:00:18.720 Danny: I am jazzed Mike. 00:00:18.720 --> 00:00:24.750 I find myself about halfway through the Y Combinator Winter 2023 program, and 00:00:24.750 --> 00:00:27.990 I'm just full of energy right now, so I'm looking forward to the conversation ahead. 00:00:28.545 --> 00:00:29.265 Mike: Spot on. 00:00:29.265 --> 00:00:29.835 Yeah, that's great. 00:00:29.835 --> 00:00:32.685 You, you are in the winter of your full on contentment from the 00:00:32.685 --> 00:00:33.945 sounds of it, so that's super dope. 00:00:33.945 --> 00:00:35.589 I'm really interested in talking to you and hearing about 00:00:35.589 --> 00:00:36.519 what you're building at Fern. 00:00:36.544 --> 00:00:40.601 I am a fellow startup co-founder, and I have limitless questions 00:00:40.601 --> 00:00:43.071 for you about the startup world and especially why Combinator. 00:00:43.071 --> 00:00:44.265 But let's start here. 00:00:44.270 --> 00:00:45.245 Tell me a little bit about yourself. 00:00:45.245 --> 00:00:47.439 Tell me your working history before Fern. 00:00:47.439 --> 00:00:51.037 How you got to the fern part of life and any of the other interesting details 00:00:51.037 --> 00:00:52.819 that, that might have come along the way. 00:00:53.654 --> 00:00:54.344 Danny: Fantastic. 00:00:54.674 --> 00:00:56.204 So my name is Danny Sheridan. 00:00:56.204 --> 00:00:58.664 I am the co-founder and CEO of Fern. 00:01:00.014 --> 00:01:03.779 and my background started at the University of Michigan. 00:01:03.869 --> 00:01:07.725 Got to study undergraduate degree focused on business and technology and actually 00:01:07.725 --> 00:01:12.795 started a business during my university days selling products on Amazon. 00:01:12.796 --> 00:01:14.848 Got to grow that business and. 00:01:15.688 --> 00:01:18.688 Actually led me to be recruited by the Amazon Marketplace team. 00:01:18.838 --> 00:01:22.078 And so went over to work for them as a product manager. 00:01:22.078 --> 00:01:25.018 I really didn't know what that title meant when they said, great, how about you 00:01:25.018 --> 00:01:27.058 come in here and do product management? 00:01:27.628 --> 00:01:33.625 And over my couple of years working at the Amazon business, I moved over to a w s 00:01:33.630 --> 00:01:34.885 and that's where I spent most of my time. 00:01:35.485 --> 00:01:40.928 And in aws I got the privilege of seeing how software's built specifically. 00:01:42.218 --> 00:01:47.588 can build APIs at scale, lots of services operating, and a very consistent 00:01:47.648 --> 00:01:50.198 developer experience consuming those APIs. 00:01:50.468 --> 00:01:54.188 So that was pretty formative for me in my understanding about the API ecosystem. 00:01:54.743 --> 00:01:55.733 Mike: Yeah, I can imagine. 00:01:55.793 --> 00:01:58.043 And it's not your first defense building a business either. 00:01:58.102 --> 00:02:01.992 So I think you've probably had you know, a, a typical founder 00:02:01.992 --> 00:02:05.892 story, but maybe an atypical sort of dev story and builder's story. 00:02:05.923 --> 00:02:09.948 So working at AW, Obviously a giant company, mega corporation. 00:02:10.008 --> 00:02:12.298 Amazon might be the biggest company in the world, maybe. 00:02:12.305 --> 00:02:15.022 And now you are running a very small company. 00:02:15.095 --> 00:02:17.225 Comparatively I'm, I'm sure, unless there's a few hundred 00:02:17.225 --> 00:02:19.335 thousand people hiding out in the wings that I don't know about. 00:02:19.369 --> 00:02:20.419 So tell me about Fern. 00:02:20.479 --> 00:02:21.919 How did you get started with Fern? 00:02:23.714 --> 00:02:25.703 Danny: I'll start with talking about my team. 00:02:26.048 --> 00:02:31.148 Which is to me the most important part of Fern and one of my co-founders. 00:02:31.148 --> 00:02:35.078 I had the privilege of meeting during my first business that I ran. 00:02:35.078 --> 00:02:37.718 So we met at the University of Michigan while running this business. 00:02:38.048 --> 00:02:42.428 I brought him in as the computer scientist to help us move off of Google Sheets 00:02:42.428 --> 00:02:44.258 and get to a real relational database. 00:02:44.708 --> 00:02:47.167 And so it's always nice for folks that are thinking about 00:02:47.227 --> 00:02:48.847 how they find a co-founding team. 00:02:49.112 --> 00:02:51.512 To rely on someone you've already worked with and trust. 00:02:51.572 --> 00:02:54.632 That's definitely a trend that I've seen amongst the co-founding teams at 00:02:54.632 --> 00:02:59.402 Y Combinator in the current program, there are over 250 teams in this 00:02:59.407 --> 00:03:04.202 batch, and a very popular pattern is. 00:03:05.537 --> 00:03:08.557 Previous coworker relationships so that you've both seen them in a 00:03:08.557 --> 00:03:11.857 professional setting, probably in a social setting to some degree. 00:03:11.869 --> 00:03:15.359 And there are a few teams that are kind of going in blind with our co-founder. 00:03:15.599 --> 00:03:16.829 So that was really important to me. 00:03:16.859 --> 00:03:18.659 We had a chance to work together for years. 00:03:19.079 --> 00:03:24.089 And then I went to AWS and my co-founder deep went over to Palantir and worked 00:03:24.089 --> 00:03:28.379 on some US government focused projects there, building APIs and integrating data. 00:03:29.144 --> 00:03:32.307 And then after a couple years in the bigger corporate environments, we 00:03:32.307 --> 00:03:36.057 agreed that it was time to go work together again, starting something anew. 00:03:36.567 --> 00:03:40.437 And as he was telling his team goodbye at Palantir, one of his teammates 00:03:40.647 --> 00:03:45.327 pulled him aside and said, Hey, I really have enjoyed working together. 00:03:46.077 --> 00:03:48.057 Would you be open to a third co-founder on your team? 00:03:48.942 --> 00:03:50.832 Mike: Wow, that's really interesting. 00:03:51.162 --> 00:03:51.732 Tell me more about 00:03:51.897 --> 00:03:55.267 Danny: Mike, how Mike, how do you vet a third co-founder that you don't know? 00:03:55.722 --> 00:03:58.002 To me, that's a lot of risk from, from my seat. 00:03:58.002 --> 00:04:03.252 It's like, Hey, we both have a good mutual connection friend that we've 00:04:03.252 --> 00:04:04.842 had the opportunity to work with. 00:04:04.842 --> 00:04:08.322 They worked together for the last 12 months at Palantir before they decided 00:04:08.327 --> 00:04:10.102 to leave to co-found Fern with me. 00:04:10.102 --> 00:04:11.202 But there's a lot of risk there. 00:04:11.352 --> 00:04:15.222 I mean, not John just dilution, but like an early stage of a startup. 00:04:16.062 --> 00:04:18.852 The biggest risk is team and team cohesion. 00:04:19.242 --> 00:04:19.662 Mike: yeah, 00:04:19.692 --> 00:04:22.332 Danny: so Mike, we, we were trying to figure out how do we. 00:04:23.292 --> 00:04:24.702 De-risk this for ourselves. 00:04:24.792 --> 00:04:27.252 And our answer was, let's go to Montana. 00:04:28.242 --> 00:04:28.362 Mike: of 00:04:28.542 --> 00:04:30.042 Danny: of us are from Mon Montana , right? 00:04:30.042 --> 00:04:31.812 Of course none of us are from Montana. 00:04:32.052 --> 00:04:33.462 It was very neutral territory. 00:04:33.462 --> 00:04:37.362 And we said, let's go get a house in the woods for a week and share a 00:04:37.362 --> 00:04:40.842 bathroom and cook together and talk about the culture we wanna build. 00:04:40.992 --> 00:04:42.532 And we didn't even have the business idea. 00:04:42.560 --> 00:04:44.420 And that was a very effective approach for us. 00:04:44.420 --> 00:04:46.640 And at the end of the week, we said, great, we're all equal partners. 00:04:46.640 --> 00:04:47.480 Let's go start a business. 00:04:48.530 --> 00:04:48.920 Mike: Sure. 00:04:48.920 --> 00:04:49.130 Yeah. 00:04:49.130 --> 00:04:53.263 Almost like a, a co-founder peyote quest, you know, off into the, the desert and 00:04:53.263 --> 00:04:54.613 see what, what visions come to you. 00:04:54.793 --> 00:04:55.603 That's really interesting. 00:04:55.603 --> 00:04:58.603 So you spent a week together kind of getting to know each other and from the 00:04:58.603 --> 00:04:59.893 sounds of it, it probably worked out. 00:04:59.893 --> 00:05:01.546 Sounds like you jived pretty well with one another. 00:05:01.546 --> 00:05:04.276 Danny: We were intentional about speaking a lot about the 00:05:04.276 --> 00:05:05.686 company we intended to build. 00:05:06.166 --> 00:05:07.526 How big of a company do you wanna build? 00:05:08.266 --> 00:05:10.786 What type of people do you wanna work at that company and what 00:05:10.786 --> 00:05:11.806 do you want the culture to be? 00:05:11.806 --> 00:05:14.836 Of the people that describe it to their family and friends over Thanksgiving, 00:05:14.836 --> 00:05:16.018 that's kinda the framing we had. 00:05:16.038 --> 00:05:18.853 And so we were very intentional of working backwards from the 00:05:18.853 --> 00:05:20.203 company we wanted to build. 00:05:21.193 --> 00:05:24.523 And then now there, right now there are three of us who work at Fern, but we 00:05:24.523 --> 00:05:25.993 anticipate that growing later this year. 00:05:26.638 --> 00:05:27.058 Mike: Yeah. 00:05:27.118 --> 00:05:28.888 Wow, that's very interesting. 00:05:29.338 --> 00:05:32.459 I so I'm a startup founder myself, a repeat offender. 00:05:32.459 --> 00:05:34.349 I'm, I'm building my third company right now. 00:05:34.413 --> 00:05:37.041 And definitely all of the people who I've worked with building 00:05:37.041 --> 00:05:39.943 companies are people who I've known beforehand to a large extent, right. 00:05:39.943 --> 00:05:43.093 Some of the early employees and companies I've worked with and some of. 00:05:43.608 --> 00:05:47.063 Third ish co-founder sort of first seats have been people 00:05:47.063 --> 00:05:48.083 who I didn't know as well. 00:05:48.121 --> 00:05:49.851 And the chemistry thing is a big part of the picture there. 00:05:49.851 --> 00:05:52.852 And you know, I think for a lot of the folks who listen to this show building 00:05:52.857 --> 00:05:56.332 products with a team is definitely something that you can imagine. 00:05:57.242 --> 00:06:00.422 But if you haven't gotten into the shoes of starting a company from 00:06:00.422 --> 00:06:04.382 scratch, it's hard to imagine what it's like building a culture from scratch. 00:06:04.382 --> 00:06:07.652 Like starting with the culture, starting with the dream, starting with the journey, 00:06:07.922 --> 00:06:11.102 and creating something that you have a shared vision for, that you can then all, 00:06:11.162 --> 00:06:12.675 you know, drive in the right direction. 00:06:12.706 --> 00:06:13.216 With that being 00:06:13.276 --> 00:06:13.546 Danny: Mike. 00:06:14.236 --> 00:06:14.686 Mike: yeah, 00:06:14.836 --> 00:06:17.836 Danny: one of the things that's on my mind is actually about complimentary skills. 00:06:17.896 --> 00:06:20.506 Is that something that you spend time thinking about when picking 00:06:20.506 --> 00:06:22.246 your most recent team at K Craftwork? 00:06:22.403 --> 00:06:22.763 Mike: Yeah. 00:06:22.763 --> 00:06:25.470 Complimentary skills complimentary personality types 00:06:25.470 --> 00:06:26.520 is really interesting too. 00:06:26.563 --> 00:06:30.583 I'm, I am really interested in working with people who can challenge 00:06:30.583 --> 00:06:33.703 me and also have a, a breadth of background and experiences and for 00:06:33.703 --> 00:06:36.475 example, like deal with conflict differently than I do, right? 00:06:36.475 --> 00:06:39.824 In a way that is healthy, you know someone who can work through a problem openly 00:06:39.824 --> 00:06:43.582 and, and honestly is going to be much more useful for a startup team than it would 00:06:43.582 --> 00:06:47.040 be someone who you know, burs emotion, things like that or doesn't communicate. 00:06:47.080 --> 00:06:48.880 Skillset is, is massive, right? 00:06:48.880 --> 00:06:52.119 Like I'm, I'm really interested in hearing the way you've structured your founding 00:06:52.119 --> 00:06:55.599 team, but having a technical founder and someone who might be more business minded 00:06:55.599 --> 00:06:58.389 or more sales minded kind of depends on the sort of business you're building. 00:06:58.401 --> 00:07:01.371 But you need to complete the, the beginning parts of that puzzle to be 00:07:01.376 --> 00:07:03.171 able to, to start assembling a business. 00:07:03.171 --> 00:07:03.631 Certainly 00:07:03.632 --> 00:07:08.157 Danny: Mike, first time founders focus on product, repeat 00:07:08.157 --> 00:07:09.867 founders focus on distribution. 00:07:10.482 --> 00:07:13.422 And that's one of the things that we've done right at the beginning of Fern, 00:07:13.452 --> 00:07:17.742 is that I spend my entire time focusing on distribution and customer success. 00:07:18.102 --> 00:07:20.502 And it allows my co-founder, Zach and Deep to spend their 00:07:20.502 --> 00:07:21.942 time building great product. 00:07:22.452 --> 00:07:23.802 And that's been very effective for us. 00:07:24.492 --> 00:07:26.202 Mike: All right, so what's the product then? 00:07:26.202 --> 00:07:27.202 Gimme the pitch for Fern. 00:07:28.452 --> 00:07:29.172 Danny: I'd love to. 00:07:29.262 --> 00:07:34.272 So Fern helps engineering teams build APIs twice as. 00:07:35.907 --> 00:07:40.137 My team has spent a lot of time doing repetitive tedious tasks. 00:07:40.137 --> 00:07:45.957 When writing APIs specifically, we would write the types and the networking on 00:07:45.957 --> 00:07:49.362 the backend, and then we would do it again in type script on the front end. 00:07:50.517 --> 00:07:54.447 We'd do it again when writing our client libraries and a fourth time 00:07:54.447 --> 00:07:59.252 when updating our documentation and Postman collection writing code. 00:07:59.942 --> 00:08:04.952 The same code repeatedly and keeping it all in sync is time consuming, it's error 00:08:04.952 --> 00:08:10.022 prone, and it's just not fun engineering work that engineering teams want to do. 00:08:10.682 --> 00:08:14.132 So firm lets engineering teams build APIs twice as fast. 00:08:14.522 --> 00:08:18.812 You start by defining your API or importing your open API 00:08:18.812 --> 00:08:20.072 spec if you're a user of it. 00:08:20.582 --> 00:08:26.522 And then Fern generates server code, SDKs documentation, and a postman. 00:08:28.137 --> 00:08:28.497 Mike: Okay. 00:08:28.527 --> 00:08:29.697 Now you're speaking our language. 00:08:29.788 --> 00:08:33.104 Open API is something that, as you might imagine, comes up an awful lot when 00:08:33.104 --> 00:08:34.864 we're, we're talking about building APIs. 00:08:34.864 --> 00:08:38.893 So it sounds like then your target end users or the, maybe the companies, the 00:08:38.893 --> 00:08:43.303 people who are, will become users of Fern are ones who need to build APIs that 00:08:43.303 --> 00:08:45.283 are largely consumed by third parties. 00:08:45.283 --> 00:08:45.703 Is that right? 00:08:45.730 --> 00:08:48.485 Danny: That's what we thought initially, and one of the learnings for us is 00:08:48.485 --> 00:08:53.143 how many folks are coming to us saying actually we want paved roads or standards 00:08:53.143 --> 00:08:54.953 for how we build APIs internally. 00:08:55.002 --> 00:08:59.622 So some of the server frameworks that we have built integration with are, 00:09:00.402 --> 00:09:01.872 I'll just name some of the popular ones. 00:09:02.262 --> 00:09:08.052 Types, types, type script express, python, fast, api, Java, spring. 00:09:09.237 --> 00:09:12.567 We've had folks that say, I actually want to be Schema first 00:09:12.567 --> 00:09:14.427 in my API development process. 00:09:14.967 --> 00:09:19.167 But it's hard and they've found that Open API is not right for them because of the 00:09:19.167 --> 00:09:23.007 quality of the code generators, which we can get into some of the challenges 00:09:23.397 --> 00:09:25.972 with the open API generators project. 00:09:26.001 --> 00:09:29.961 But what they come to us is, is saying is that I would like idiomatic. 00:09:30.261 --> 00:09:30.801 Cogen, 00:09:31.431 --> 00:09:31.921 Mike: Yeah. 00:09:32.421 --> 00:09:35.041 Danny: I definitely want some clients and actually. 00:09:35.451 --> 00:09:39.891 The first client library that they want tends to be a TypeScript SDK that they 00:09:39.891 --> 00:09:42.411 can use for building their front end. 00:09:42.621 --> 00:09:46.011 So it's actually they want an internal TypeScript SDK as the very first step 00:09:46.011 --> 00:09:47.391 that we see most of our customers take. 00:09:48.276 --> 00:09:48.666 Mike: Sure. 00:09:48.756 --> 00:09:49.806 Yeah, that makes a lot of sense. 00:09:49.806 --> 00:09:54.019 I think the discourse over the past couple years has really shifted too from 00:09:54.019 --> 00:09:57.063 let's build an API that works and figure out how the standards work and make sure 00:09:57.063 --> 00:10:00.014 we're, you know, putting up the right H C T P verb and right to the right 00:10:00.014 --> 00:10:01.154 endpoint and designing these things at. 00:10:01.414 --> 00:10:04.234 Follow sort of like the, the standards that we're used to from rest and open 00:10:04.234 --> 00:10:07.984 API and people are suddenly upleveling that discussion and it's more about how 00:10:07.984 --> 00:10:11.344 do we provide type safety ferment and how do I make sure it's secure ferment 00:10:11.349 --> 00:10:13.808 and how can I idiomatic is a great term. 00:10:13.808 --> 00:10:16.568 How can I deploy this in a few languages so that the Java developers 00:10:16.573 --> 00:10:19.658 feel like they're writing Java code and not like interfacing with a 00:10:19.658 --> 00:10:21.648 completely foreign bit of tooling. 00:10:22.903 --> 00:10:24.163 Yeah, I think that's really interesting. 00:10:24.163 --> 00:10:27.253 And I think that Design First APIs is something that people are really 00:10:27.253 --> 00:10:29.563 like starting to embrace lately too. 00:10:29.672 --> 00:10:33.415 The cogen tooling maybe leaves a bit to be desired, but I, I've seen quite a bit 00:10:33.420 --> 00:10:37.428 of people talking about using open API tools like postman and Stoplight and all 00:10:37.428 --> 00:10:40.787 those to build out what their API looks like before they write a line of code. 00:10:40.787 --> 00:10:44.291 And that is wholly different from where we were, I don't know, 10 00:10:44.291 --> 00:10:45.594 years ago, maybe even less than that. 00:10:45.602 --> 00:10:48.543 Danny: The, the place where I would say I'm not sure that, that makes sense. 00:10:48.548 --> 00:10:53.473 Like the, the gap in that story for me is that postman is not schema aware. 00:10:54.733 --> 00:10:57.783 And so it's really not the first place to go to define the api. 00:10:57.783 --> 00:10:58.203 I get that. 00:10:58.208 --> 00:11:01.123 It makes examples and a collection is nice to have. 00:11:01.123 --> 00:11:04.253 But that's kind of gap in my mind of that's not why I would 00:11:04.253 --> 00:11:06.713 not use it as a API definition 00:11:06.898 --> 00:11:07.388 Mike: Yeah. 00:11:07.553 --> 00:11:08.573 Danny: to then build off of. 00:11:08.963 --> 00:11:11.297 And then stoplight is not as collaborative. 00:11:11.477 --> 00:11:14.987 There's, there's no like, concept of branching or suggesting a change. 00:11:15.437 --> 00:11:17.669 And so we run into companies that. 00:11:18.524 --> 00:11:20.474 Basically to generate an open API spec. 00:11:20.474 --> 00:11:24.284 So it's kinda like a front end UI to get them to open api and then they 00:11:24.284 --> 00:11:27.314 use that to feed into, I'm thinking of one company that fed that into 00:11:27.319 --> 00:11:29.534 the Rust server code generator. 00:11:30.039 --> 00:11:33.581 And that was their workflow and they're kind of just duct taping and using some 00:11:33.581 --> 00:11:35.630 bailing wire to get these tools together. 00:11:35.630 --> 00:11:38.912 And I look forward to a much more all-in-one experience, which I 00:11:38.912 --> 00:11:41.642 think is going to be the future of a API development as we look down. 00:11:42.962 --> 00:11:46.052 Mike: Yeah, I think the developer experience is starting to level up, right? 00:11:46.052 --> 00:11:48.692 It's the, the collaboration experience is much easier. 00:11:48.692 --> 00:11:53.027 And designing something that you can have confidence in is, is becoming something 00:11:53.032 --> 00:11:56.882 that doesn't require, 25 years of, of experience building things to do. 00:11:56.953 --> 00:11:59.083 I also think along with type safety, one of the things that comes up 00:11:59.083 --> 00:12:03.253 quite a bit for, I'd imagine internal teams, those who are using Fern, who 00:12:03.283 --> 00:12:06.313 their first project might be that type script thing to build their own site. 00:12:06.316 --> 00:12:08.287 Probably talking about mobile apps too, right? 00:12:08.287 --> 00:12:11.167 They, they also need to consume their API to build a mobile app, and that's 00:12:11.497 --> 00:12:14.767 kind of a different story than the web because caching is different and API 00:12:14.767 --> 00:12:16.207 keys are different and things like that. 00:12:16.207 --> 00:12:18.517 When you're downloading, you know, something that executes 00:12:18.517 --> 00:12:19.757 on a local device too. 00:12:19.757 --> 00:12:24.130 Danny: And that reminds me, Mike, of there are thin wrappers around an API 00:12:24.130 --> 00:12:27.140 for SDKs, and then there are smart SDKs. 00:12:27.595 --> 00:12:30.775 And I'll give one example of just talking to the team at Post Ho, who's 00:12:30.775 --> 00:12:34.465 a product an an open source self hostable product analytics solution. 00:12:34.795 --> 00:12:40.525 They have a very smart sdk and so while co-generation can get them maybe 10, 20% 00:12:40.530 --> 00:12:44.215 of the way, they have a lot of work to do when still building out their SDKs. 00:12:44.215 --> 00:12:47.075 And so I'm excited to see how much of that smart logic over 00:12:47.075 --> 00:12:49.085 time can be code genned today. 00:12:49.085 --> 00:12:49.475 It's about. 00:12:50.539 --> 00:12:52.734 Mike: I think the expectations there are getting higher too. 00:12:52.739 --> 00:12:56.004 As an API consumer, oftentimes I feel like people are getting used 00:12:56.009 --> 00:12:57.553 to seeing documentation that has. 00:12:57.553 --> 00:13:01.195 Generated examples right in your documentation Stripe maybe set the 00:13:01.261 --> 00:13:05.251 standard there for, for putting API keys in your docs that are functional 00:13:05.256 --> 00:13:06.481 for the user that's consuming it. 00:13:06.481 --> 00:13:09.830 So this is where I put in my disclaimer that I worked for Stripe in the past, but 00:13:09.830 --> 00:13:11.360 I'm no longer affiliated with that squad. 00:13:11.360 --> 00:13:14.104 But if you have a Stripe account and you go to Stripes you'll get code samples 00:13:14.104 --> 00:13:16.564 that you can copy and paste into your environment and they'll run because it 00:13:16.564 --> 00:13:18.154 uses your, your test keys, your api. 00:13:18.221 --> 00:13:21.179 Which is super cool and an expectation that's starting to level itself 00:13:21.179 --> 00:13:22.419 across the industry too, right? 00:13:22.419 --> 00:13:26.198 Danny: And Mike, we've asked companies who, who say that they intend to 00:13:26.198 --> 00:13:28.898 do that, how they plan to do it, and you know what their answer is. 00:13:29.448 --> 00:13:29.898 Mike: What's that? 00:13:31.328 --> 00:13:34.598 Danny: They say that the way that they're going to get copy and pastable 00:13:34.598 --> 00:13:36.468 code examples for every endpoint. 00:13:37.523 --> 00:13:42.623 Use the SDK is to hand write it and put it in markdown on their docs. 00:13:42.923 --> 00:13:44.123 That's the answer today. 00:13:44.483 --> 00:13:45.383 And that sucks. 00:13:45.443 --> 00:13:47.573 That will not be the world in five years from now. 00:13:47.963 --> 00:13:48.323 Mike: Yeah, 00:13:48.418 --> 00:13:52.403 Danny: exciting place where you really need someone to own the code generation 00:13:52.403 --> 00:13:57.893 of the SDKs and the docs experience, if you want that to be easy and seamless. 00:13:57.893 --> 00:14:00.293 And so I'll give two examples to you, Mike, of companies that have 00:14:00.383 --> 00:14:01.973 decided to own that experience. 00:14:02.663 --> 00:14:02.783 Mike: sure. 00:14:02.993 --> 00:14:04.703 Danny: One of them was my former employer at aw. 00:14:06.488 --> 00:14:10.148 And they did it by building a tool called Smithy that was 00:14:10.148 --> 00:14:11.768 initially an internal tool. 00:14:12.128 --> 00:14:14.888 It's a domain specific language for defining APIs. 00:14:16.448 --> 00:14:19.028 You would define your schema and then you'd click generate, and one 00:14:19.028 --> 00:14:20.288 of the things you'd get is docs. 00:14:20.618 --> 00:14:24.488 And because they would generate SDKs and docs, they would be 00:14:24.488 --> 00:14:25.988 able to put SDKs snippets. 00:14:26.528 --> 00:14:29.438 In the docs and they built all that themselves. 00:14:29.738 --> 00:14:30.948 They then open sourced it. 00:14:30.948 --> 00:14:34.209 But if you look at the community, it's, it's not very existent because there 00:14:34.209 --> 00:14:39.819 are a lot of like heavy dependencies on AWS packages and libraries that are not 00:14:39.819 --> 00:14:42.669 the things that I'd want my customers consuming if I was giving them an sdk. 00:14:43.989 --> 00:14:44.619 So that's one. 00:14:44.799 --> 00:14:45.399 AW Ws. 00:14:45.429 --> 00:14:48.519 They did this and they built it internally by funding a dev team. 00:14:49.059 --> 00:14:51.279 Not everyone can near, not every business can do that. 00:14:51.909 --> 00:14:52.479 Mike: Yeah. 00:14:52.569 --> 00:14:56.544 Danny: company is very near and dear to your past, which is, Stripe 00:14:56.544 --> 00:14:58.824 calls their internal tooling sorbet. 00:14:59.394 --> 00:15:03.354 And sorbet is a Ruby domain specific language, which allows 00:15:03.354 --> 00:15:05.274 you to define an API schema first. 00:15:05.274 --> 00:15:06.924 And this is how Stripe builds their APIs. 00:15:06.924 --> 00:15:08.784 They don't start with writing code on the backend. 00:15:09.114 --> 00:15:11.634 They start with their schema and then they go and generate. 00:15:11.964 --> 00:15:14.604 And one of the things they're able to do because they own their SDK 00:15:14.604 --> 00:15:19.464 generation and they own their docs generation, is they put example snippet. 00:15:20.259 --> 00:15:23.149 For each endpoint in their docs that are copy and pastable. 00:15:23.176 --> 00:15:26.236 And it's very clear to me that we are going to take inspiration 00:15:26.236 --> 00:15:29.026 for that at Fern with what we build over the next 12 months. 00:15:29.941 --> 00:15:30.241 Mike: Yeah. 00:15:30.241 --> 00:15:32.485 Well, you've, you've definitely done your homework if that's the case. 00:15:32.485 --> 00:15:34.330 And so, so let me spit it back at you then. 00:15:34.330 --> 00:15:36.730 It sounds like from what you're describing, at least some of the value 00:15:36.730 --> 00:15:40.870 proposition as a team that needs to build APIs of kind of any description, 00:15:40.870 --> 00:15:44.079 whether it's internal or external, is something that helps you define the shape 00:15:44.079 --> 00:15:47.468 of your API and the sort of requirements of the API itself co-generation from 00:15:47.468 --> 00:15:48.968 there to get you client libraries. 00:15:49.006 --> 00:15:50.611 Well actually I don't think we've talked about languages, 00:15:50.611 --> 00:15:53.264 but some amount of languages that you can, you can work through. 00:15:53.264 --> 00:15:56.842 And then theoretically the great documentation that should follow from 00:15:56.842 --> 00:16:00.800 that, that is human understandable and useful and has code snippets and things 00:16:00.800 --> 00:16:02.150 like that, that are useful as well. 00:16:02.201 --> 00:16:05.531 Is, is that a fair description of kind of what you're after with Fern? 00:16:06.531 --> 00:16:09.081 Danny: And we'll, we'll leave you with the Postman collection as well. 00:16:09.081 --> 00:16:13.351 Cause a lot of teams enjoy the postman being a destination of their api. 00:16:13.364 --> 00:16:14.744 That's exactly what we're after. 00:16:15.014 --> 00:16:20.654 We're going to enable engineering teams to design schema first, and we're gonna 00:16:20.654 --> 00:16:24.524 do the undifferentiated heavy lifting associated with con libraries and talks. 00:16:24.959 --> 00:16:25.319 Mike: Yeah. 00:16:25.379 --> 00:16:25.739 Okay. 00:16:25.744 --> 00:16:29.129 So that leaves me with the question of, I could imagine many engineering 00:16:29.129 --> 00:16:33.070 teams that are existent in the world today probably have some 00:16:33.070 --> 00:16:34.974 sort of api that exists right now. 00:16:35.004 --> 00:16:35.244 Right? 00:16:35.249 --> 00:16:39.452 So is there a process for adopting Fern as a tool to use or I don't know, 00:16:39.452 --> 00:16:42.632 backing into schema that that Fern can consume and then generate from? 00:16:43.652 --> 00:16:48.032 Danny: Yeah, so we, we have invented our own specification, and I think 00:16:48.032 --> 00:16:50.642 of the XKCD about another standard. 00:16:50.642 --> 00:16:51.902 You know, all the standards don't work. 00:16:51.902 --> 00:16:52.892 Let's invent another. 00:16:53.162 --> 00:16:55.952 We very much acknowledge that we're introducing another standard into the 00:16:55.952 --> 00:16:58.112 world, and so to ease that transit. 00:16:59.762 --> 00:17:03.722 You are able to bring in an open API spec and you can either import that 00:17:03.722 --> 00:17:07.292 and then continue building it out in Fern, or we actually have a mode where 00:17:07.292 --> 00:17:09.272 you can just use open API into Fern. 00:17:09.542 --> 00:17:12.722 And behind the scenes we turn it into this specification that we call the 00:17:12.722 --> 00:17:18.602 Fern definition, which is a yammel specification that is simpler to write 00:17:18.932 --> 00:17:21.662 than what I'll call verbose open api. 00:17:22.682 --> 00:17:25.112 and happy to talk more about that if you're interested in Mike. 00:17:25.562 --> 00:17:27.092 Mike: Yeah, sure, sure. 00:17:27.092 --> 00:17:28.571 I that, that's a bold undertaking. 00:17:28.571 --> 00:17:32.737 I know the scope of an API definition can be quite a bit to begin with, but then 00:17:32.737 --> 00:17:36.725 all the other things that Open API can, you know do and provide for co-generation, 00:17:36.725 --> 00:17:39.245 all those other things, there's a lot of surface area to cover there. 00:17:40.325 --> 00:17:44.955 Apart from my own disdain for Yammel which we can get into on another podcast. 00:17:44.955 --> 00:17:47.265 I, I suppose yeah, I think that's really interesting. 00:17:47.265 --> 00:17:48.537 I'm I'm curious maybe. 00:17:48.542 --> 00:17:50.005 So let's take a step back actually. 00:17:50.005 --> 00:17:52.706 So how long has Fern been in the world? 00:17:52.706 --> 00:17:54.306 How long has it been available to use? 00:17:54.306 --> 00:17:58.696 Danny: We've been working on Fern for 11 months now, and we are now 00:17:58.696 --> 00:18:00.196 in production with 10 customers. 00:18:00.676 --> 00:18:01.066 Mike: Cool. 00:18:01.071 --> 00:18:01.486 Right on. 00:18:01.516 --> 00:18:02.326 Oh, that's really exciting. 00:18:02.326 --> 00:18:06.328 So what is your, well, so 10 customers is a decent size sample set. 00:18:06.328 --> 00:18:10.059 Have you seen a pattern in the size of those companies or maybe the appetite 00:18:10.064 --> 00:18:13.232 for certain types of companies or engineering teams or whatever to jump into 00:18:13.232 --> 00:18:15.692 adopting a new standard or a new process? 00:18:16.247 --> 00:18:19.757 Danny: Yeah, I think it'd be best to speak about one company specifically, and so 00:18:19.757 --> 00:18:23.657 I'll pick one of our customers to talk about, which is the team at Flat File. 00:18:24.137 --> 00:18:26.537 They do CSV importing is their business. 00:18:26.807 --> 00:18:27.077 Mike: Oh yeah. 00:18:27.217 --> 00:18:27.577 Okay. 00:18:28.157 --> 00:18:28.997 Danny: are you familiar with them, Mike? 00:18:29.027 --> 00:18:29.387 Mike: I am. 00:18:29.387 --> 00:18:29.747 Yeah. 00:18:30.497 --> 00:18:30.947 Danny: All right. 00:18:31.217 --> 00:18:34.457 They've gotten the API to use the flat file product. 00:18:35.882 --> 00:18:40.922 And they came to us because they tried using the open API generators and what 00:18:40.922 --> 00:18:44.642 they found was that some of the code didn't compile after they would use 00:18:44.642 --> 00:18:48.782 the generator, and they weren't happy with the idiomatic nature of the code. 00:18:49.772 --> 00:18:53.762 Like it was very clear that all of the languages were not of equal quality. 00:18:54.362 --> 00:18:57.062 And so they came to us and said, Hey, I heard that you guys can 00:18:57.062 --> 00:18:59.322 produce production-ready SDKs. 00:18:59.522 --> 00:19:00.242 We wanna see it. 00:19:00.632 --> 00:19:04.292 And so we took their open API spec, brought it into Fern, and then 00:19:04.292 --> 00:19:09.482 were able to generate SDKs and we guarantee that the SDK will compile 00:19:09.512 --> 00:19:13.892 some of, some of my gripes with the Open API generators is like when 00:19:13.892 --> 00:19:15.632 they don't compile after generating. 00:19:15.902 --> 00:19:18.272 And so it requires me to start playing around with mustache. 00:19:18.912 --> 00:19:20.142 So with Fern, there's none of that. 00:19:20.352 --> 00:19:21.432 We are open source. 00:19:21.582 --> 00:19:24.492 You can see our code generators and we even take 00:19:24.492 --> 00:19:25.822 contributions from the community. 00:19:25.822 --> 00:19:29.446 But this flat file company, they were able to, now they 00:19:29.446 --> 00:19:31.366 just launched their node JS sdk. 00:19:31.666 --> 00:19:33.856 We'll be working on a Python and a Java. 00:19:33.934 --> 00:19:36.634 Mike, before you mentioned, what languages do you support Danny? 00:19:36.639 --> 00:19:40.054 And the answers that we've started with the, the big three languages, 00:19:40.084 --> 00:19:45.544 which are type script, which also is JavaScript, Python, and Java. 00:19:46.564 --> 00:19:50.034 And then beyond that, if, if some of our customers want other languages, 00:19:50.484 --> 00:19:54.354 what we'll do is we will use the Open API generators and we will 00:19:54.354 --> 00:19:56.364 manage those on customer's behalf. 00:19:56.634 --> 00:19:59.814 And Fern takes care of publishing to GitHub so you can have your source 00:19:59.814 --> 00:20:03.054 code in its own repo, and we take care of publishing to the appropriate 00:20:03.059 --> 00:20:05.724 registry like N P M Maven or Pi P. 00:20:06.719 --> 00:20:06.894 Mike: Yeah. 00:20:06.954 --> 00:20:07.404 Okay. 00:20:07.494 --> 00:20:08.304 Oh, that's really interesting. 00:20:08.304 --> 00:20:11.364 I mean, the, the three languages that you've chosen, I think make a lot of sense 00:20:11.364 --> 00:20:14.737 to cover, you know, the 80 20 problem of what the industry's up to right now. 00:20:14.783 --> 00:20:17.526 And other ones to come, I think are pretty easy to imagine. 00:20:17.555 --> 00:20:20.232 Putting on my, like head of engineering hat if I'm trusting 00:20:20.232 --> 00:20:21.752 someone else to generate the APIs. 00:20:21.887 --> 00:20:24.249 For, or there's the client libraries for my api. 00:20:24.249 --> 00:20:27.384 One of the things that I'm going to be really keen, keenly aware 00:20:27.384 --> 00:20:28.864 of is the state of testing. 00:20:28.875 --> 00:20:32.085 So how, how am I certain that the APIs that are being generated, compiled, but 00:20:32.085 --> 00:20:33.870 then also work what does that look like? 00:20:34.765 --> 00:20:37.555 Danny: Yeah, so we, we make sure to test our code generators. 00:20:37.945 --> 00:20:41.635 That's the point that we view, that's important for us to quality 00:20:41.635 --> 00:20:45.048 control and because of the testing that we do on our code generators. 00:20:45.558 --> 00:20:49.258 We can give you certainty that your code will compile after the SDK is generated. 00:20:49.269 --> 00:20:51.939 So we have, we've had no customers that have had an issue with 00:20:51.939 --> 00:20:53.319 having to test out their sdk. 00:20:53.619 --> 00:20:57.101 Some do choose to write test themselves but we have not run 00:20:57.106 --> 00:20:58.241 into a single issue to date. 00:20:58.916 --> 00:20:59.336 Mike: Sure. 00:20:59.846 --> 00:21:00.266 Okay. 00:21:00.506 --> 00:21:04.516 So let's say I'm sitting here listening to the, the podcast and it 00:21:04.516 --> 00:21:07.393 sounds like Fern might be something that I'm interested in using. 00:21:07.423 --> 00:21:08.653 What's onboarding look like right now? 00:21:09.673 --> 00:21:11.953 Danny: Yeah, right now the best way to get in touch is to go to 00:21:11.953 --> 00:21:13.603 our website and schedule a call. 00:21:13.684 --> 00:21:15.899 We have focused on going deep with our customers instead 00:21:15.899 --> 00:21:17.849 of focusing on self-service. 00:21:18.089 --> 00:21:21.029 Most of our customers are engineering teams who actually wanna understand 00:21:21.029 --> 00:21:22.259 how does this impact my work? 00:21:23.099 --> 00:21:25.629 And kind of how can I minimally impact my workflow? 00:21:25.629 --> 00:21:29.357 Mike, earlier you asked the question of what if I already have an API or multiple 00:21:29.362 --> 00:21:33.337 APIs, and the answer is that you can bring your open API spec that you have 00:21:33.697 --> 00:21:37.657 and then use Fern for your end plus one endpoint so you can use it for the next 00:21:37.657 --> 00:21:42.171 endpoint and have kind of, it reminds me of the transition from JavaScript to 00:21:42.171 --> 00:21:45.951 TypeScript that companies went through where you keep all your JavaScript code, 00:21:45.951 --> 00:21:49.191 you just build TypeScript over time, and eventually it becomes the way that you do. 00:21:50.061 --> 00:21:50.451 Mike: right? 00:21:50.451 --> 00:21:50.661 Yeah. 00:21:50.661 --> 00:21:53.069 Incremental adoption is, is an interesting feature there. 00:21:53.069 --> 00:21:53.849 That's really cool. 00:21:53.889 --> 00:21:54.369 Okay. 00:21:54.429 --> 00:21:54.639 Yeah. 00:21:54.639 --> 00:21:54.999 Wow. 00:21:54.999 --> 00:21:57.583 So you support the, the big three languages. 00:21:57.583 --> 00:21:59.743 You can, we can kind of get into incremental adoption. 00:21:59.923 --> 00:22:01.513 What are the hard problems that you're facing right now? 00:22:01.513 --> 00:22:03.043 Like, what are the things that are, that you're thinking of 00:22:03.048 --> 00:22:03.943 that are keeping you up at night? 00:22:04.327 --> 00:22:06.577 Danny: One of the things that keeps me upward up at night 00:22:06.577 --> 00:22:08.017 is backwards compatibility. 00:22:08.137 --> 00:22:11.927 A lot of our customers want to ensure that their APIs are back compat. 00:22:11.951 --> 00:22:14.801 And that is going to take engineering and a little bit of r and d on our 00:22:14.801 --> 00:22:17.468 end to make sure that we can support that in a very first class way. 00:22:17.471 --> 00:22:19.871 So that's one of the things that I've, I, I kind of wake up thinking 00:22:19.871 --> 00:22:21.581 through how do we ensure that? 00:22:22.571 --> 00:22:27.641 Don't allow a developer to break their API accidentally. 00:22:28.331 --> 00:22:28.781 Mike: right? 00:22:28.781 --> 00:22:29.171 I see. 00:22:29.171 --> 00:22:29.531 Yeah. 00:22:29.531 --> 00:22:33.469 And so by that you, you literally mean let's say I have version 1.0 of my API 00:22:33.469 --> 00:22:37.039 out in the wild and my TypeScript API that I built myself in-house using whatever, 00:22:37.249 --> 00:22:40.826 you know, open API spec and tools and teams and engineering that I wanted I 00:22:40.826 --> 00:22:44.831 guess is what you're saying there that uh, if tomorrow I adopted Fern and Fern 00:22:44.831 --> 00:22:49.382 is generating version 1.0 0.1 of my api, and you, you wanna make sure that 00:22:49.382 --> 00:22:50.732 that's backwards compatible, is that. 00:22:50.805 --> 00:22:54.525 Danny: It is actually a, a good way to speak about this might actually be to 00:22:54.525 --> 00:22:59.085 go to talk to Stripe . So what Stripe does is every time that they release 00:22:59.085 --> 00:23:03.405 a new version of their api, they do not break their previous consumers. 00:23:03.885 --> 00:23:07.021 And so I have a friend who's been using Stripe for six years now 00:23:07.471 --> 00:23:09.101 and they have not updated their. 00:23:09.811 --> 00:23:13.801 Code to submit basically a payment to call the Stripe APIs. 00:23:13.801 --> 00:23:15.661 And that's amazing to me that someone can do that. 00:23:16.201 --> 00:23:19.411 And the way that Stripe does it is that they have their V1 of the API 00:23:19.411 --> 00:23:23.041 actually call the V2 of the api. 00:23:23.491 --> 00:23:27.361 Behind the scenes they have like a translator that they've written and then 00:23:27.361 --> 00:23:32.851 that V2 of the API actually sends the request to the server, gets a response, 00:23:32.851 --> 00:23:34.891 and then they translate it back to the v1. 00:23:35.461 --> 00:23:37.228 And they've done that for multiple versions over. 00:23:37.228 --> 00:23:41.481 And they built automation to build those translators between their versions. 00:23:41.901 --> 00:23:44.361 And I think that, I believe that they're called gates. 00:23:44.811 --> 00:23:48.111 That technology is going to be very exciting if we can democratize it and 00:23:48.111 --> 00:23:49.651 give that to everyone in the world. 00:23:49.651 --> 00:23:53.872 Right now it just exists in a, the very small walled gardens 00:23:54.082 --> 00:23:55.132 of the big tech companies. 00:23:55.612 --> 00:23:56.122 Mike: Yeah. 00:23:56.152 --> 00:23:56.552 Got it. 00:23:56.800 --> 00:23:57.850 completely understand that. 00:23:57.850 --> 00:23:59.784 And having experienced it from the inside of Stripe, it's, 00:23:59.784 --> 00:24:01.304 it's pretty incredible to see. 00:24:01.366 --> 00:24:04.973 I, I also have built companies on Stripes, APIs in the past, which is like, as a 00:24:04.973 --> 00:24:06.653 consumer, not having to worry about that. 00:24:06.732 --> 00:24:09.701 Super, super helpful and like that's the kind of thing that, that afford. 00:24:09.951 --> 00:24:13.564 Sleep and you know, not no hair pulling when you're especially working with, 00:24:13.569 --> 00:24:14.944 dealing with taking people's money 00:24:15.014 --> 00:24:15.404 Danny: Mike. 00:24:16.244 --> 00:24:19.184 Mike, this reminds me of a quote from William Gibson that 00:24:19.184 --> 00:24:20.714 the future is already here. 00:24:20.714 --> 00:24:24.464 It's just not evenly distributed, and I think you got to 00:24:24.464 --> 00:24:25.604 experience that at Stripe. 00:24:25.609 --> 00:24:29.174 I got to experience that at aws, and if furnace successful, we will 00:24:29.614 --> 00:24:33.974 democratize some of the innovations that occurred within and were 00:24:33.974 --> 00:24:35.864 invented within those organizations. 00:24:36.239 --> 00:24:36.659 Mike: Sure. 00:24:36.809 --> 00:24:37.109 Yeah. 00:24:37.109 --> 00:24:39.270 I appreciate the open source angle that you're taking too 00:24:39.270 --> 00:24:40.380 with your code generators. 00:24:40.478 --> 00:24:43.221 So what's, what is I guess what's the strategy there? 00:24:43.221 --> 00:24:45.261 Like how are you engaging the community in, in helping to 00:24:45.261 --> 00:24:46.911 build open source tooling? 00:24:46.911 --> 00:24:50.347 Is there a an adoption curve that comes along with that as an organization? 00:24:50.347 --> 00:24:51.067 What does that look like? 00:24:51.842 --> 00:24:52.672 Danny: A absolutely. 00:24:52.702 --> 00:24:58.222 We've been able to create a pricing model where we have a free open source tier, 00:24:58.612 --> 00:25:02.272 and then a paid professional plant tier, and I'll speak about those for a second. 00:25:02.275 --> 00:25:06.919 In the free open source, you can use all of our code generators and. 00:25:07.279 --> 00:25:10.369 We output the files that are generated and compiled. 00:25:10.369 --> 00:25:13.639 So for example, if you have a type script sdk or you have FAST API 00:25:13.639 --> 00:25:17.269 code that comes to your local file system, but you can use all of firm's 00:25:17.269 --> 00:25:23.419 generators in the paid version, we will publish the generated code for you. 00:25:23.689 --> 00:25:28.129 So typically we see GitHub and the registries like npm, Maven, 00:25:28.129 --> 00:25:30.319 pi, PI as the destinations. 00:25:30.499 --> 00:25:33.379 We also see Postman as a common destination, and then 00:25:33.379 --> 00:25:34.369 you get support from our. 00:25:35.404 --> 00:25:39.004 And so we've seen that be a successful way to, there's kind of a bimodal 00:25:39.004 --> 00:25:42.214 distribution with folks that wanna try it and kind of hack around with it. 00:25:42.256 --> 00:25:46.546 And the common pattern that we've seen is that developers 00:25:46.546 --> 00:25:48.556 actually build before they buy. 00:25:49.066 --> 00:25:52.186 They wanna bring able to bring it to their team and show it to them 00:25:52.246 --> 00:25:56.386 how it works before even getting into contracting and procurement. 00:25:56.656 --> 00:25:59.989 And so we are very And have that context around anyone that 00:25:59.989 --> 00:26:01.369 wants to come to you as use us. 00:26:01.369 --> 00:26:03.829 It's like you should be able to try this before you're convinced you 00:26:03.829 --> 00:26:05.029 should be spending money with us. 00:26:06.244 --> 00:26:07.474 Mike: Yeah, that's a common pattern. 00:26:07.553 --> 00:26:08.933 For, for large companies especially. 00:26:08.933 --> 00:26:10.463 It's sort of build me a proof of concept. 00:26:10.463 --> 00:26:11.903 Show me why we would do this. 00:26:12.053 --> 00:26:14.903 Give us the value prop in a, you know, micro atomic level. 00:26:14.903 --> 00:26:17.963 Show it to the team, shop it around to, you know, whoever needs to sign 00:26:17.963 --> 00:26:20.141 the dotted line to, to adopt new tools. 00:26:20.160 --> 00:26:23.184 And that can be a really effective way for people to both prove to themselves 00:26:23.184 --> 00:26:25.494 that they need it, but then to prove to their organization that it's 00:26:25.494 --> 00:26:26.724 something that provides value too. 00:26:27.429 --> 00:26:29.559 Danny: And we don't have to reinvent the wheel here, Mike. 00:26:30.669 --> 00:26:35.019 We have seen examples of Code Gen four APIs, and so I'll 00:26:35.019 --> 00:26:36.069 walk through a couple of 'em. 00:26:36.639 --> 00:26:40.539 We've had the privilege of seeing Apollo with GraphQL build 00:26:40.544 --> 00:26:41.919 a business around code gen. 00:26:42.759 --> 00:26:48.249 Then in a more recent company that's been built is buff around protocol 00:26:48.249 --> 00:26:49.869 buffers, and that's buff.build. 00:26:50.409 --> 00:26:55.269 And they have been able to build a business around cogen in the G 00:26:55.269 --> 00:26:57.249 R P C and Protocol Buffers world. 00:26:57.624 --> 00:26:58.074 Mike: Yeah. 00:26:58.359 --> 00:27:03.099 Danny: aspiration is that rest APIs are much more than 90% of all 00:27:03.099 --> 00:27:04.299 APIs that have been built today. 00:27:04.809 --> 00:27:10.479 And so we aspire to be Fern the Cogen company for rest APIs. 00:27:11.424 --> 00:27:11.904 Mike: Sure. 00:27:12.264 --> 00:27:12.444 Yeah. 00:27:12.444 --> 00:27:12.654 Wow. 00:27:12.654 --> 00:27:13.884 That's a massive undertaking. 00:27:13.913 --> 00:27:16.347 And definitely a lot of mountain to lift there. 00:27:16.398 --> 00:27:21.061 It seems to me that one, one of the, the advantages of using open source under 00:27:21.061 --> 00:27:26.568 underlying tooling to build co-generation for your APIs is particularly being able 00:27:26.568 --> 00:27:30.028 to have community adoption and sort of approval from a robust set of people 00:27:30.051 --> 00:27:31.491 testing out your tools and using it. 00:27:31.791 --> 00:27:35.331 And I feel like that's also maybe one of the values that Open api, the, 00:27:35.331 --> 00:27:37.250 the specification provides as well. 00:27:37.250 --> 00:27:39.980 So is that something that you're thinking about, maybe contributing back to 00:27:39.980 --> 00:27:43.250 open API itself or trying to influence the tooling or the structure or the 00:27:43.255 --> 00:27:46.329 organization or the people, whatever parts of that might make sense for you? 00:27:47.529 --> 00:27:51.399 Danny: At this point, I am really laser focused on serving our customers. 00:27:51.849 --> 00:27:53.799 And deploying Fern successfully with them. 00:27:53.799 --> 00:27:55.699 And so that takes up all of my time right now. 00:27:55.729 --> 00:28:01.351 I am not spending time focused on the open api either the technical steering 00:28:01.351 --> 00:28:03.467 community or some of those meetings. 00:28:03.481 --> 00:28:05.021 I'm spending all of my time with our customers. 00:28:05.791 --> 00:28:06.121 Mike: Yeah. 00:28:06.151 --> 00:28:06.481 Cool. 00:28:06.541 --> 00:28:06.961 Right on. 00:28:06.966 --> 00:28:08.299 So what's, what's next? 00:28:08.304 --> 00:28:10.089 What are the things that you're working on delivering right now? 00:28:11.404 --> 00:28:13.834 Danny: Yeah, I'll give you one of the problem statements that a customer came 00:28:13.839 --> 00:28:18.284 to us with that is just fun for anyone who likes to think about API challenges. 00:28:18.307 --> 00:28:22.472 This company is building in the microservices architecture world. 00:28:23.042 --> 00:28:26.462 And they've got a microservice, that's Python Fast api. 00:28:26.462 --> 00:28:30.092 They've got another one that's TypeScript Express and they have another one and go. 00:28:30.692 --> 00:28:32.312 So they have three microservices. 00:28:32.372 --> 00:28:36.002 Each is a different engineering team within their organization, but they 00:28:36.007 --> 00:28:39.782 want one SDK for each of their major languages that they support, and 00:28:39.782 --> 00:28:43.412 they want one Postman collection and they want one API docs experience. 00:28:43.982 --> 00:28:48.122 So they came to us and said, Hey Danny, how do we take a bunch of 00:28:48.122 --> 00:28:50.342 different backends and abstract that. 00:28:51.947 --> 00:28:53.297 our API consumers. 00:28:53.927 --> 00:28:55.337 And so that's just a fun challenge. 00:28:55.397 --> 00:28:57.317 And the right answer there is build schema first. 00:28:57.677 --> 00:29:02.147 And so we actually got access to their GitHub repo, went in and wrote them up 00:29:02.147 --> 00:29:06.857 a firm definition so that they could be using our specification, and then 00:29:06.857 --> 00:29:10.513 we're able to generate a single kind of developer experience to be the 00:29:10.513 --> 00:29:13.033 interface into multiple microservices. 00:29:13.033 --> 00:29:16.513 And so the, the consumers of their API don't even know that that's 00:29:16.513 --> 00:29:17.563 their architecture internally. 00:29:17.563 --> 00:29:19.513 And I think that's exactly the way it should. 00:29:20.473 --> 00:29:20.863 Mike: Sure. 00:29:20.863 --> 00:29:22.843 It's almost like a unifying agent at that point. 00:29:23.818 --> 00:29:24.658 Danny: That's exactly right. 00:29:24.728 --> 00:29:26.408 Companies shouldn't be building this internally. 00:29:26.408 --> 00:29:29.534 I talked to another prospect recently who they built that 00:29:29.539 --> 00:29:33.254 unifying technology internally and they said, it's not that great. 00:29:33.254 --> 00:29:34.214 It's got some bugs. 00:29:34.514 --> 00:29:37.004 We kind of get an open API spec that's not great, but we 00:29:37.004 --> 00:29:38.672 try to unify into that format. 00:29:38.672 --> 00:29:41.646 And I am very excited to offer that to more organizations in 00:29:41.646 --> 00:29:45.846 the coming year of if you have a microservices architecture fern can 00:29:45.846 --> 00:29:47.296 work really well for being that un. 00:29:48.841 --> 00:29:49.321 Mike: Yeah. 00:29:49.388 --> 00:29:52.351 There's a lot of complexity that will come along with microservices, and I think 00:29:52.621 --> 00:29:55.951 people get to that level of complexity despite the promise of microservices 00:29:55.951 --> 00:29:58.712 being like, oh, you really just need to worry about your, your little. 00:29:59.176 --> 00:30:02.635 You know segment of the world, your sliver of the code, it's a microservice. 00:30:02.635 --> 00:30:04.585 You can make a billion of 'em and they all work together. 00:30:04.643 --> 00:30:06.776 But then suddenly you, you find yourself, you know, sitting in a 00:30:06.776 --> 00:30:10.766 room with red yarn tied from place to place to place and not really 00:30:10.771 --> 00:30:12.206 understanding the larger picture there. 00:30:12.267 --> 00:30:15.715 Having a a zoomed out view of that, and especially something that can sort of 00:30:15.715 --> 00:30:18.957 orchestrate that across the organization, even across teams, like you mentioned. 00:30:18.987 --> 00:30:19.437 That's super. 00:30:20.987 --> 00:30:21.137 Yeah. 00:30:21.137 --> 00:30:24.560 So if, if devs are interested in working with Fern what, what's 00:30:24.560 --> 00:30:25.580 the best way to get started today? 00:30:26.825 --> 00:30:33.515 Danny: The best way to get started is to head to our website, build with fern.com. 00:30:34.370 --> 00:30:34.760 Mike: Cool. 00:30:35.105 --> 00:30:36.605 Danny: Check it out, read the docs. 00:30:36.605 --> 00:30:37.475 There's a getting started. 00:30:38.315 --> 00:30:39.695 But I'm happy to help as well. 00:30:39.695 --> 00:30:43.925 So my email is Danny build with verne.com and you can send me 00:30:43.925 --> 00:30:47.795 a link to your existing docs or attach your open API spec. 00:30:47.804 --> 00:30:50.028 Our most successful customers have actually gotten that 00:30:50.028 --> 00:30:51.108 white glove onboarding. 00:30:51.738 --> 00:30:54.768 And as much as I love the idea of self-service adoption and bottoms 00:30:54.768 --> 00:30:58.585 up we've experienced that these engineering organizations want 00:30:58.585 --> 00:31:02.065 someone to come in and really deeply understand their workflow before they. 00:31:03.130 --> 00:31:05.680 Editing that to try to enhance and make things easier. 00:31:05.950 --> 00:31:08.110 Cuz a lot of times you run into more trouble than it's worth. 00:31:08.530 --> 00:31:10.889 And so we take a very hands-on approach in showing kind of the 00:31:10.889 --> 00:31:12.759 before and after of using Fern. 00:31:13.649 --> 00:31:15.629 Mike: Yeah, especially when bringing something new into the world, I 00:31:15.629 --> 00:31:18.029 think it's helpful to go through that experience yourself too, right? 00:31:18.029 --> 00:31:21.209 Probably as a founder, you're validating the onboarding experience and seeing 00:31:21.209 --> 00:31:24.179 the things that you can be doing better and feeling some of their pain is, is 00:31:24.179 --> 00:31:25.689 likely a valuable thing for you too. 00:31:25.690 --> 00:31:29.102 Danny: Very much Mike, it very much aligns with some of the Why Combinator 00:31:29.102 --> 00:31:33.076 advice that I've gotten from their, they call them group partners, which 00:31:33.076 --> 00:31:37.156 are like the advisors that each company gets, and they have been very clear 00:31:37.156 --> 00:31:40.396 that there are two ways that we should be spending our time these days. 00:31:41.356 --> 00:31:45.406 One, talking to customers and two coding. 00:31:46.576 --> 00:31:46.936 Mike: Sure. 00:31:47.056 --> 00:31:49.636 Danny: And if you're not doing either of those two, like reevaluate 00:31:49.636 --> 00:31:50.626 how you're spending your time. 00:31:50.626 --> 00:31:51.926 And so that's really stuck with me. 00:31:51.945 --> 00:31:54.105 I'll count this time right now as talking to customers. 00:31:54.465 --> 00:31:55.605 Mike: Yeah, I think that's fair. 00:31:55.605 --> 00:31:56.715 I think that's totally fair. 00:31:56.732 --> 00:31:59.428 What if our listeners want to check out your open source stuff? 00:31:59.428 --> 00:32:00.866 What's your uh, GitHub organization called? 00:32:01.496 --> 00:32:08.036 Danny: Our GitHub organization is Fern api and our repo is called Fern. 00:32:09.026 --> 00:32:09.356 Mike: Got it. 00:32:09.386 --> 00:32:09.707 Okay. 00:32:09.710 --> 00:32:12.764 I should say as well that I will of course include links to a lot 00:32:12.764 --> 00:32:13.874 of this stuff in the show notes. 00:32:13.926 --> 00:32:14.166 Yeah. 00:32:14.166 --> 00:32:17.166 So we'll, we'll have notes for that, for folks to check out. 00:32:17.166 --> 00:32:19.300 Yeah, from there, I guess so I don't know. 00:32:19.300 --> 00:32:21.230 Any other questions or any other things you wanted to cover? 00:32:21.254 --> 00:32:24.486 Danny: I think the last thing on my mind is that if there's one takeaway, 00:32:24.666 --> 00:32:30.966 it's that Fern makes building rest APIs easier and faster for engineering teams. 00:32:32.676 --> 00:32:36.126 Mike: Yeah, that seems like a, a solid pitch there without a doubt. 00:32:36.213 --> 00:32:39.490 And Danny, so I'll include your email in the show notes as well. 00:32:39.520 --> 00:32:42.880 Do you find yourself traipsing across Twitter or LinkedIn or Macedon, 00:32:42.880 --> 00:32:44.170 any of those places these days? 00:32:44.204 --> 00:32:48.320 Danny: I'm a LinkedIn person, so it'll be I, I'll include the link in the show notes 00:32:48.320 --> 00:32:49.910 for folks who wanna connect and reach out. 00:32:50.285 --> 00:32:50.945 Mike: Yeah, perfect. 00:32:50.945 --> 00:32:51.915 I'll have that in there as well. 00:32:51.915 --> 00:32:54.223 Danny Sheridan, it has been wonderful chatting with you. 00:32:54.247 --> 00:32:56.025 It's been really cool to hear about Fern. 00:32:56.074 --> 00:32:58.309 If, if you're listening to the show check out the show notes. 00:32:58.314 --> 00:32:59.279 Lots of good stuff in there. 00:32:59.279 --> 00:33:00.552 Danny, thanks so much for coming along. 00:33:00.593 --> 00:33:01.539 It's been a pleasure chatting with you. 00:33:02.529 --> 00:33:06.099 Danny: I look forward to creating more APIs that people won't hate. 00:33:06.879 --> 00:33:07.539 Mike: Here's to that. 00:33:07.779 --> 00:33:08.599 Take care, Denny.