Hello everyone and welcome back to APIs you won't hate. My name is Mike Fulco. Your APIs you won't hate guide on this mystery tour we're on. Today I have the distinct pleasure of sitting down and chatting with Danny Sheridan from Fern. Danny, it's nice to meet you. How are you doing today?
I am jazzed Mike. I find myself about halfway through the Y Combinator Winter 2023 program, and I'm just full of energy right now, so I'm looking forward to the conversation ahead.
Spot on. Yeah, that's great. You, you are in the winter of your full on contentment from the sounds of it, so that's super dope. I'm really interested in talking to you and hearing about what you're building at Fern. I am a fellow startup co-founder, and I have limitless questions for you about the startup world and especially why Combinator. But let's start here. Tell me a little bit about yourself. Tell me your working history before Fern.
How you got to the fern part of life and any of the other interesting details that, that might have come along the way.
Fantastic. So my name is Danny Sheridan. I am the co-founder and CEO of Fern. and my background started at the University of Michigan. Got to study undergraduate degree focused on business and technology and actually started a business during my university days selling products on Amazon. Got to grow that business and. Actually led me to be recruited by the Amazon Marketplace team. And so went over to work for them as a product manager.
I really didn't know what that title meant when they said, great, how about you come in here and do product management? And over my couple of years working at the Amazon business, I moved over to a w s and that's where I spent most of my time. And in aws I got the privilege of seeing how software's built specifically. can build APIs at scale, lots of services operating, and a very consistent developer experience consuming those APIs.
So that was pretty formative for me in my understanding about the API ecosystem.
Yeah, I can imagine. And it's not your first defense building a business either. So I think you've probably had you know, a, a typical founder story, but maybe an atypical sort of dev story and builder's story. So working at AW, Obviously a giant company, mega corporation. Amazon might be the biggest company in the world, maybe. And now you are running a very small company. Comparatively I'm, I'm sure, unless there's a few hundred thousand people hiding out in the wings that I don't know about.
So tell me about Fern. How did you get started with Fern?
I'll start with talking about my team. Which is to me the most important part of Fern and one of my co-founders. I had the privilege of meeting during my first business that I ran. So we met at the University of Michigan while running this business. I brought him in as the computer scientist to help us move off of Google Sheets and get to a real relational database. And so it's always nice for folks that are thinking about how they find a co-founding team.
To rely on someone you've already worked with and trust. That's definitely a trend that I've seen amongst the co-founding teams at Y Combinator in the current program, there are over 250 teams in this batch, and a very popular pattern is. Previous coworker relationships so that you've both seen them in a professional setting, probably in a social setting to some degree. And there are a few teams that are kind of going in blind with our co-founder. So that was really important to me.
We had a chance to work together for years. And then I went to AWS and my co-founder deep went over to Palantir and worked on some US government focused projects there, building APIs and integrating data. And then after a couple years in the bigger corporate environments, we agreed that it was time to go work together again, starting something anew. And as he was telling his team goodbye at Palantir, one of his teammates pulled him aside and said, Hey, I really have enjoyed working together.
Would you be open to a third co-founder on your team?
Wow, that's really interesting. Tell me more about
Mike, how Mike, how do you vet a third co-founder that you don't know? To me, that's a lot of risk from, from my seat. It's like, Hey, we both have a good mutual connection friend that we've had the opportunity to work with. They worked together for the last 12 months at Palantir before they decided to leave to co-found Fern with me. But there's a lot of risk there. I mean, not John just dilution, but like an early stage of a startup. The biggest risk is team and team cohesion.
yeah,
so Mike, we, we were trying to figure out how do we. De-risk this for ourselves. And our answer was, let's go to Montana.
of
of us are from Mon Montana , right? Of course none of us are from Montana. It was very neutral territory. And we said, let's go get a house in the woods for a week and share a bathroom and cook together and talk about the culture we wanna build. And we didn't even have the business idea. And that was a very effective approach for us. And at the end of the week, we said, great, we're all equal partners. Let's go start a business.
Sure. Yeah. Almost like a, a co-founder peyote quest, you know, off into the, the desert and see what, what visions come to you. That's really interesting. So you spent a week together kind of getting to know each other and from the sounds of it, it probably worked out. Sounds like you jived pretty well with one another.
We were intentional about speaking a lot about the company we intended to build. How big of a company do you wanna build? What type of people do you wanna work at that company and what do you want the culture to be? Of the people that describe it to their family and friends over Thanksgiving, that's kinda the framing we had. And so we were very intentional of working backwards from the company we wanted to build.
And then now there, right now there are three of us who work at Fern, but we anticipate that growing later this year.
Yeah. Wow, that's very interesting. I so I'm a startup founder myself, a repeat offender. I'm, I'm building my third company right now. And definitely all of the people who I've worked with building companies are people who I've known beforehand to a large extent, right. Some of the early employees and companies I've worked with and some of. Third ish co-founder sort of first seats have been people who I didn't know as well. And the chemistry thing is a big part of the picture there.
And you know, I think for a lot of the folks who listen to this show building products with a team is definitely something that you can imagine. But if you haven't gotten into the shoes of starting a company from scratch, it's hard to imagine what it's like building a culture from scratch. Like starting with the culture, starting with the dream, starting with the journey, and creating something that you have a shared vision for, that you can then all, you know, drive in the right direction.
With that being
Mike.
yeah,
one of the things that's on my mind is actually about complimentary skills. Is that something that you spend time thinking about when picking your most recent team at K Craftwork?
Yeah. Complimentary skills complimentary personality types is really interesting too. I'm, I am really interested in working with people who can challenge me and also have a, a breadth of background and experiences and for example, like deal with conflict differently than I do, right?
In a way that is healthy, you know someone who can work through a problem openly and, and honestly is going to be much more useful for a startup team than it would be someone who you know, burs emotion, things like that or doesn't communicate. Skillset is, is massive, right?
Like I'm, I'm really interested in hearing the way you've structured your founding team, but having a technical founder and someone who might be more business minded or more sales minded kind of depends on the sort of business you're building. But you need to complete the, the beginning parts of that puzzle to be able to, to start assembling a business. Certainly
Mike, first time founders focus on product, repeat founders focus on distribution. And that's one of the things that we've done right at the beginning of Fern, is that I spend my entire time focusing on distribution and customer success. And it allows my co-founder, Zach and Deep to spend their time building great product. And that's been very effective for us.
All right, so what's the product then? Gimme the pitch for Fern.
I'd love to. So Fern helps engineering teams build APIs twice as. My team has spent a lot of time doing repetitive tedious tasks. When writing APIs specifically, we would write the types and the networking on the backend, and then we would do it again in type script on the front end. We'd do it again when writing our client libraries and a fourth time when updating our documentation and Postman collection writing code.
The same code repeatedly and keeping it all in sync is time consuming, it's error prone, and it's just not fun engineering work that engineering teams want to do. So firm lets engineering teams build APIs twice as fast. You start by defining your API or importing your open API spec if you're a user of it. And then Fern generates server code, SDKs documentation, and a postman.
Okay. Now you're speaking our language. Open API is something that, as you might imagine, comes up an awful lot when we're, we're talking about building APIs. So it sounds like then your target end users or the, maybe the companies, the people who are, will become users of Fern are ones who need to build APIs that are largely consumed by third parties. Is that right?
That's what we thought initially, and one of the learnings for us is how many folks are coming to us saying actually we want paved roads or standards for how we build APIs internally. So some of the server frameworks that we have built integration with are, I'll just name some of the popular ones. Types, types, type script express, python, fast, api, Java, spring. We've had folks that say, I actually want to be Schema first in my API development process.
But it's hard and they've found that Open API is not right for them because of the quality of the code generators, which we can get into some of the challenges with the open API generators project. But what they come to us is, is saying is that I would like idiomatic. Cogen,
Yeah.
I definitely want some clients and actually. The first client library that they want tends to be a TypeScript SDK that they can use for building their front end. So it's actually they want an internal TypeScript SDK as the very first step that we see most of our customers take.
Sure. Yeah, that makes a lot of sense. I think the discourse over the past couple years has really shifted too from let's build an API that works and figure out how the standards work and make sure we're, you know, putting up the right H C T P verb and right to the right endpoint and designing these things at.
Follow sort of like the, the standards that we're used to from rest and open API and people are suddenly upleveling that discussion and it's more about how do we provide type safety ferment and how do I make sure it's secure ferment and how can I idiomatic is a great term. How can I deploy this in a few languages so that the Java developers feel like they're writing Java code and not like interfacing with a completely foreign bit of tooling. Yeah, I think that's really interesting.
And I think that Design First APIs is something that people are really like starting to embrace lately too. The cogen tooling maybe leaves a bit to be desired, but I, I've seen quite a bit of people talking about using open API tools like postman and Stoplight and all those to build out what their API looks like before they write a line of code. And that is wholly different from where we were, I don't know, 10 years ago, maybe even less than that.
The, the place where I would say I'm not sure that, that makes sense. Like the, the gap in that story for me is that postman is not schema aware. And so it's really not the first place to go to define the api. I get that. It makes examples and a collection is nice to have. But that's kind of gap in my mind of that's not why I would not use it as a API definition
Yeah.
to then build off of. And then stoplight is not as collaborative. There's, there's no like, concept of branching or suggesting a change. And so we run into companies that. Basically to generate an open API spec. So it's kinda like a front end UI to get them to open api and then they use that to feed into, I'm thinking of one company that fed that into the Rust server code generator.
And that was their workflow and they're kind of just duct taping and using some bailing wire to get these tools together. And I look forward to a much more all-in-one experience, which I think is going to be the future of a API development as we look down.
Yeah, I think the developer experience is starting to level up, right? It's the, the collaboration experience is much easier. And designing something that you can have confidence in is, is becoming something that doesn't require, 25 years of, of experience building things to do.
I also think along with type safety, one of the things that comes up quite a bit for, I'd imagine internal teams, those who are using Fern, who their first project might be that type script thing to build their own site. Probably talking about mobile apps too, right? They, they also need to consume their API to build a mobile app, and that's kind of a different story than the web because caching is different and API keys are different and things like that.
When you're downloading, you know, something that executes on a local device too.
And that reminds me, Mike, of there are thin wrappers around an API for SDKs, and then there are smart SDKs. And I'll give one example of just talking to the team at Post Ho, who's a product an an open source self hostable product analytics solution. They have a very smart sdk and so while co-generation can get them maybe 10, 20% of the way, they have a lot of work to do when still building out their SDKs. And so I'm excited to see how much of that smart logic over time can be code genned today.
It's about.
I think the expectations there are getting higher too. As an API consumer, oftentimes I feel like people are getting used to seeing documentation that has. Generated examples right in your documentation Stripe maybe set the standard there for, for putting API keys in your docs that are functional for the user that's consuming it. So this is where I put in my disclaimer that I worked for Stripe in the past, but I'm no longer affiliated with that squad.
But if you have a Stripe account and you go to Stripes you'll get code samples that you can copy and paste into your environment and they'll run because it uses your, your test keys, your api. Which is super cool and an expectation that's starting to level itself across the industry too, right?
And Mike, we've asked companies who, who say that they intend to do that, how they plan to do it, and you know what their answer is.
What's that?
They say that the way that they're going to get copy and pastable code examples for every endpoint. Use the SDK is to hand write it and put it in markdown on their docs. That's the answer today. And that sucks. That will not be the world in five years from now.
Yeah,
exciting place where you really need someone to own the code generation of the SDKs and the docs experience, if you want that to be easy and seamless. And so I'll give two examples to you, Mike, of companies that have decided to own that experience.
sure.
One of them was my former employer at aw. And they did it by building a tool called Smithy that was initially an internal tool. It's a domain specific language for defining APIs. You would define your schema and then you'd click generate, and one of the things you'd get is docs. And because they would generate SDKs and docs, they would be able to put SDKs snippets. In the docs and they built all that themselves. They then open sourced it.
But if you look at the community, it's, it's not very existent because there are a lot of like heavy dependencies on AWS packages and libraries that are not the things that I'd want my customers consuming if I was giving them an sdk. So that's one. AW Ws. They did this and they built it internally by funding a dev team. Not everyone can near, not every business can do that.
Yeah.
company is very near and dear to your past, which is, Stripe calls their internal tooling sorbet. And sorbet is a Ruby domain specific language, which allows you to define an API schema first. And this is how Stripe builds their APIs. They don't start with writing code on the backend. They start with their schema and then they go and generate. And one of the things they're able to do because they own their SDK generation and they own their docs generation, is they put example snippet.
For each endpoint in their docs that are copy and pastable. And it's very clear to me that we are going to take inspiration for that at Fern with what we build over the next 12 months.
Yeah. Well, you've, you've definitely done your homework if that's the case. And so, so let me spit it back at you then. It sounds like from what you're describing, at least some of the value proposition as a team that needs to build APIs of kind of any description, whether it's internal or external, is something that helps you define the shape of your API and the sort of requirements of the API itself co-generation from there to get you client libraries.
Well actually I don't think we've talked about languages, but some amount of languages that you can, you can work through. And then theoretically the great documentation that should follow from that, that is human understandable and useful and has code snippets and things like that, that are useful as well. Is, is that a fair description of kind of what you're after with Fern?
And we'll, we'll leave you with the Postman collection as well. Cause a lot of teams enjoy the postman being a destination of their api. That's exactly what we're after. We're going to enable engineering teams to design schema first, and we're gonna do the undifferentiated heavy lifting associated with con libraries and talks.
Yeah. Okay. So that leaves me with the question of, I could imagine many engineering teams that are existent in the world today probably have some sort of api that exists right now. Right? So is there a process for adopting Fern as a tool to use or I don't know, backing into schema that that Fern can consume and then generate from?
Yeah, so we, we have invented our own specification, and I think of the XKCD about another standard. You know, all the standards don't work. Let's invent another. We very much acknowledge that we're introducing another standard into the world, and so to ease that transit. You are able to bring in an open API spec and you can either import that and then continue building it out in Fern, or we actually have a mode where you can just use open API into Fern.
And behind the scenes we turn it into this specification that we call the Fern definition, which is a yammel specification that is simpler to write than what I'll call verbose open api. and happy to talk more about that if you're interested in Mike.
Yeah, sure, sure. I that, that's a bold undertaking. I know the scope of an API definition can be quite a bit to begin with, but then all the other things that Open API can, you know do and provide for co-generation, all those other things, there's a lot of surface area to cover there. Apart from my own disdain for Yammel which we can get into on another podcast. I, I suppose yeah, I think that's really interesting. I'm I'm curious maybe. So let's take a step back actually.
So how long has Fern been in the world? How long has it been available to use?
We've been working on Fern for 11 months now, and we are now in production with 10 customers.
Cool. Right on. Oh, that's really exciting. So what is your, well, so 10 customers is a decent size sample set. Have you seen a pattern in the size of those companies or maybe the appetite for certain types of companies or engineering teams or whatever to jump into adopting a new standard or a new process?
Yeah, I think it'd be best to speak about one company specifically, and so I'll pick one of our customers to talk about, which is the team at Flat File. They do CSV importing is their business.
Oh yeah. Okay.
are you familiar with them, Mike?
I am. Yeah.
All right. They've gotten the API to use the flat file product. And they came to us because they tried using the open API generators and what they found was that some of the code didn't compile after they would use the generator, and they weren't happy with the idiomatic nature of the code. Like it was very clear that all of the languages were not of equal quality. And so they came to us and said, Hey, I heard that you guys can produce production-ready SDKs. We wanna see it.
And so we took their open API spec, brought it into Fern, and then were able to generate SDKs and we guarantee that the SDK will compile some of, some of my gripes with the Open API generators is like when they don't compile after generating. And so it requires me to start playing around with mustache. So with Fern, there's none of that. We are open source. You can see our code generators and we even take contributions from the community.
But this flat file company, they were able to, now they just launched their node JS sdk. We'll be working on a Python and a Java. Mike, before you mentioned, what languages do you support Danny? And the answers that we've started with the, the big three languages, which are type script, which also is JavaScript, Python, and Java.
And then beyond that, if, if some of our customers want other languages, what we'll do is we will use the Open API generators and we will manage those on customer's behalf. And Fern takes care of publishing to GitHub so you can have your source code in its own repo, and we take care of publishing to the appropriate registry like N P M Maven or Pi P.
Yeah. Okay. Oh, that's really interesting. I mean, the, the three languages that you've chosen, I think make a lot of sense to cover, you know, the 80 20 problem of what the industry's up to right now. And other ones to come, I think are pretty easy to imagine. Putting on my, like head of engineering hat if I'm trusting someone else to generate the APIs. For, or there's the client libraries for my api. One of the things that I'm going to be really keen, keenly aware of is the state of testing.
So how, how am I certain that the APIs that are being generated, compiled, but then also work what does that look like?
Yeah, so we, we make sure to test our code generators. That's the point that we view, that's important for us to quality control and because of the testing that we do on our code generators. We can give you certainty that your code will compile after the SDK is generated. So we have, we've had no customers that have had an issue with having to test out their sdk. Some do choose to write test themselves but we have not run into a single issue to date.
Sure. Okay. So let's say I'm sitting here listening to the, the podcast and it sounds like Fern might be something that I'm interested in using. What's onboarding look like right now?
Yeah, right now the best way to get in touch is to go to our website and schedule a call. We have focused on going deep with our customers instead of focusing on self-service. Most of our customers are engineering teams who actually wanna understand how does this impact my work? And kind of how can I minimally impact my workflow?
Mike, earlier you asked the question of what if I already have an API or multiple APIs, and the answer is that you can bring your open API spec that you have and then use Fern for your end plus one endpoint so you can use it for the next endpoint and have kind of, it reminds me of the transition from JavaScript to TypeScript that companies went through where you keep all your JavaScript code, you just build TypeScript over time, and eventually it becomes the way that you do.
right? Yeah. Incremental adoption is, is an interesting feature there. That's really cool. Okay. Yeah. Wow. So you support the, the big three languages. You can, we can kind of get into incremental adoption. What are the hard problems that you're facing right now? Like, what are the things that are, that you're thinking of that are keeping you up at night?
One of the things that keeps me upward up at night is backwards compatibility. A lot of our customers want to ensure that their APIs are back compat. And that is going to take engineering and a little bit of r and d on our end to make sure that we can support that in a very first class way. So that's one of the things that I've, I, I kind of wake up thinking through how do we ensure that? Don't allow a developer to break their API accidentally.
right? I see. Yeah. And so by that you, you literally mean let's say I have version 1.0 of my API out in the wild and my TypeScript API that I built myself in-house using whatever, you know, open API spec and tools and teams and engineering that I wanted I guess is what you're saying there that uh, if tomorrow I adopted Fern and Fern is generating version 1.0 0.1 of my api, and you, you wanna make sure that that's backwards compatible, is that.
It is actually a, a good way to speak about this might actually be to go to talk to Stripe . So what Stripe does is every time that they release a new version of their api, they do not break their previous consumers. And so I have a friend who's been using Stripe for six years now and they have not updated their. Code to submit basically a payment to call the Stripe APIs. And that's amazing to me that someone can do that.
And the way that Stripe does it is that they have their V1 of the API actually call the V2 of the api. Behind the scenes they have like a translator that they've written and then that V2 of the API actually sends the request to the server, gets a response, and then they translate it back to the v1. And they've done that for multiple versions over. And they built automation to build those translators between their versions. And I think that, I believe that they're called gates.
That technology is going to be very exciting if we can democratize it and give that to everyone in the world. Right now it just exists in a, the very small walled gardens of the big tech companies.
Yeah. Got it. completely understand that. And having experienced it from the inside of Stripe, it's, it's pretty incredible to see. I, I also have built companies on Stripes, APIs in the past, which is like, as a consumer, not having to worry about that. Super, super helpful and like that's the kind of thing that, that afford. Sleep and you know, not no hair pulling when you're especially working with, dealing with taking people's money
Mike. Mike, this reminds me of a quote from William Gibson that the future is already here. It's just not evenly distributed, and I think you got to experience that at Stripe. I got to experience that at aws, and if furnace successful, we will democratize some of the innovations that occurred within and were invented within those organizations.
Sure. Yeah. I appreciate the open source angle that you're taking too with your code generators. So what's, what is I guess what's the strategy there? Like how are you engaging the community in, in helping to build open source tooling? Is there a an adoption curve that comes along with that as an organization? What does that look like?
A absolutely. We've been able to create a pricing model where we have a free open source tier, and then a paid professional plant tier, and I'll speak about those for a second. In the free open source, you can use all of our code generators and. We output the files that are generated and compiled.
So for example, if you have a type script sdk or you have FAST API code that comes to your local file system, but you can use all of firm's generators in the paid version, we will publish the generated code for you. So typically we see GitHub and the registries like npm, Maven, pi, PI as the destinations. We also see Postman as a common destination, and then you get support from our.
And so we've seen that be a successful way to, there's kind of a bimodal distribution with folks that wanna try it and kind of hack around with it. And the common pattern that we've seen is that developers actually build before they buy. They wanna bring able to bring it to their team and show it to them how it works before even getting into contracting and procurement. And so we are very And have that context around anyone that wants to come to you as use us.
It's like you should be able to try this before you're convinced you should be spending money with us.
Yeah, that's a common pattern. For, for large companies especially. It's sort of build me a proof of concept. Show me why we would do this. Give us the value prop in a, you know, micro atomic level. Show it to the team, shop it around to, you know, whoever needs to sign the dotted line to, to adopt new tools. And that can be a really effective way for people to both prove to themselves that they need it, but then to prove to their organization that it's something that provides value too.
And we don't have to reinvent the wheel here, Mike. We have seen examples of Code Gen four APIs, and so I'll walk through a couple of 'em. We've had the privilege of seeing Apollo with GraphQL build a business around code gen. Then in a more recent company that's been built is buff around protocol buffers, and that's buff.build. And they have been able to build a business around cogen in the G R P C and Protocol Buffers world.
Yeah.
aspiration is that rest APIs are much more than 90% of all APIs that have been built today. And so we aspire to be Fern the Cogen company for rest APIs.
Sure. Yeah. Wow. That's a massive undertaking. And definitely a lot of mountain to lift there. It seems to me that one, one of the, the advantages of using open source under underlying tooling to build co-generation for your APIs is particularly being able to have community adoption and sort of approval from a robust set of people testing out your tools and using it. And I feel like that's also maybe one of the values that Open api, the, the specification provides as well.
So is that something that you're thinking about, maybe contributing back to open API itself or trying to influence the tooling or the structure or the organization or the people, whatever parts of that might make sense for you?
At this point, I am really laser focused on serving our customers. And deploying Fern successfully with them. And so that takes up all of my time right now. I am not spending time focused on the open api either the technical steering community or some of those meetings. I'm spending all of my time with our customers.
Yeah. Cool. Right on. So what's, what's next? What are the things that you're working on delivering right now?
Yeah, I'll give you one of the problem statements that a customer came to us with that is just fun for anyone who likes to think about API challenges. This company is building in the microservices architecture world. And they've got a microservice, that's Python Fast api. They've got another one that's TypeScript Express and they have another one and go. So they have three microservices.
Each is a different engineering team within their organization, but they want one SDK for each of their major languages that they support, and they want one Postman collection and they want one API docs experience. So they came to us and said, Hey Danny, how do we take a bunch of different backends and abstract that. our API consumers. And so that's just a fun challenge. And the right answer there is build schema first.
And so we actually got access to their GitHub repo, went in and wrote them up a firm definition so that they could be using our specification, and then we're able to generate a single kind of developer experience to be the interface into multiple microservices. And so the, the consumers of their API don't even know that that's their architecture internally. And I think that's exactly the way it should.
Sure. It's almost like a unifying agent at that point.
That's exactly right. Companies shouldn't be building this internally. I talked to another prospect recently who they built that unifying technology internally and they said, it's not that great. It's got some bugs. We kind of get an open API spec that's not great, but we try to unify into that format. And I am very excited to offer that to more organizations in the coming year of if you have a microservices architecture fern can work really well for being that un.
Yeah. There's a lot of complexity that will come along with microservices, and I think people get to that level of complexity despite the promise of microservices being like, oh, you really just need to worry about your, your little. You know segment of the world, your sliver of the code, it's a microservice. You can make a billion of 'em and they all work together.
But then suddenly you, you find yourself, you know, sitting in a room with red yarn tied from place to place to place and not really understanding the larger picture there. Having a a zoomed out view of that, and especially something that can sort of orchestrate that across the organization, even across teams, like you mentioned. That's super. Yeah. So if, if devs are interested in working with Fern what, what's the best way to get started today?
The best way to get started is to head to our website, build with fern.com.
Cool.
Check it out, read the docs. There's a getting started. But I'm happy to help as well. So my email is Danny build with verne.com and you can send me a link to your existing docs or attach your open API spec. Our most successful customers have actually gotten that white glove onboarding. And as much as I love the idea of self-service adoption and bottoms up we've experienced that these engineering organizations want someone to come in and really deeply understand their workflow before they.
Editing that to try to enhance and make things easier. Cuz a lot of times you run into more trouble than it's worth. And so we take a very hands-on approach in showing kind of the before and after of using Fern.
Yeah, especially when bringing something new into the world, I think it's helpful to go through that experience yourself too, right? Probably as a founder, you're validating the onboarding experience and seeing the things that you can be doing better and feeling some of their pain is, is likely a valuable thing for you too.
Very much Mike, it very much aligns with some of the Why Combinator advice that I've gotten from their, they call them group partners, which are like the advisors that each company gets, and they have been very clear that there are two ways that we should be spending our time these days. One, talking to customers and two coding.
Sure.
And if you're not doing either of those two, like reevaluate how you're spending your time. And so that's really stuck with me. I'll count this time right now as talking to customers.
Yeah, I think that's fair. I think that's totally fair. What if our listeners want to check out your open source stuff? What's your uh, GitHub organization called?
Our GitHub organization is Fern api and our repo is called Fern.
Got it. Okay. I should say as well that I will of course include links to a lot of this stuff in the show notes. Yeah. So we'll, we'll have notes for that, for folks to check out. Yeah, from there, I guess so I don't know. Any other questions or any other things you wanted to cover?
I think the last thing on my mind is that if there's one takeaway, it's that Fern makes building rest APIs easier and faster for engineering teams.
Yeah, that seems like a, a solid pitch there without a doubt. And Danny, so I'll include your email in the show notes as well. Do you find yourself traipsing across Twitter or LinkedIn or Macedon, any of those places these days?
I'm a LinkedIn person, so it'll be I, I'll include the link in the show notes for folks who wanna connect and reach out.
Yeah, perfect. I'll have that in there as well. Danny Sheridan, it has been wonderful chatting with you. It's been really cool to hear about Fern. If, if you're listening to the show check out the show notes. Lots of good stuff in there. Danny, thanks so much for coming along. It's been a pleasure chatting with you.
I look forward to creating more APIs that people won't hate.
Here's to that. Take care, Denny.