Subscribe
Share
Share
Embed
Fern - Build APIs Twice as fast - https://buildwithfern.com/
Fern on GitHub - https://github.com/fern-api/fern
Fern's Profile with YCombinator - https://www.ycombinator.com/companies/fern
Danny Sheridan - CEO and cofounder of Fern danny@buildwithfern.com
Creators & Guests
What is APIs You Won't Hate?
A no-nonsense (well, some-nonsense) podcast about API design & development, new features in the world of HTTP, service-orientated architecture, microservices, and probably bikes.
Mike: 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?
Danny: 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.
Mike: 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.
Danny: 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.
Mike: 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?
Danny: 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?
Mike: Wow, that's really interesting.
Tell me more about
Danny: 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.
Mike: yeah,
Danny: 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.
Mike: of
Danny: 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.
Mike: 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.
Danny: 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.
Mike: 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
Danny: Mike.
Mike: yeah,
Danny: 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?
Mike: 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
Danny: 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.
Mike: All right, so
what's the product then?
Gimme the pitch for Fern.
Danny: 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.
Mike: 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?
Danny: 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,
Mike: Yeah.
Danny: 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.
Mike: 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.
Danny: 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
Mike: Yeah.
Danny: 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.
Mike: 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.
Danny: 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.
Mike: 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?
Danny: 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.
Mike: What's that?
Danny: 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.
Mike: Yeah,
Danny: 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.
Mike: sure.
Danny: 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.
Mike: Yeah.
Danny: 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.
Mike: 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?
Danny: 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.
Mike: 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?
Danny: 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.
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?
Danny: We've been working on Fern
for 11 months now, and we are now
in production with 10 customers.
Mike: 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?
Danny: 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.
Mike: Oh yeah.
Okay.
Danny: are you familiar with them, Mike?
Mike: I am.
Yeah.
Danny: 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.
Mike: 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?
Danny: 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.
Mike: 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?
Danny: 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.
Mike: 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?
Danny: 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.
Mike: 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.
Danny: 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.
Mike: 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
Danny: 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.
Mike: 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?
Danny: 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.
Mike: 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.
Danny: 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.
Mike: Yeah.
Danny: 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.
Mike: 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?
Danny: 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.
Mike: Yeah.
Cool.
Right on.
So what's, what's next?
What are the things that you're
working on delivering right now?
Danny: 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.
Mike: Sure.
It's almost like a unifying
agent at that point.
Danny: 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.
Mike: 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?
Danny: The best way to get started is to
head to our website, build with fern.com.
Mike: Cool.
Danny: 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.
Mike: 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.
Danny: 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.
Mike: Sure.
Danny: 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.
Mike: 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?
Danny: Our GitHub organization is
Fern api and our repo is called Fern.
Mike: 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?
Danny: 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.
Mike: 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?
Danny: 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.
Mike: 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.
Danny: I look forward to creating
more APIs that people won't hate.
Mike: Here's to that.
Take care, Denny.