
Instantly offer SDKs and API Docs
Turn this teardown into a decision-ready prompt for ChatGPT, Claude, or your agent.
If you only have a few minutes to spare, here’s what investors, operators, and founders should know about Fern (W23).
Fern turned an internal-infrastructure advantage into a product smaller API companies could buy. Amazon and Palantir had built systems to generate client libraries from API definitions. Most companies still chose between hand-maintained SDKs and open-source generators that produced uneven code. Fern packaged the hard parts: language-native SDKs, synchronized documentation, publishing, enterprise controls, and eventually agent-facing interfaces.
The first customer took more than 18 months. Less than four years after founding, Fern had 25 employees, more than 200 customers, millions in annual revenue, and a January 2026 acquisition by Postman.[1] Fern stayed an independent product, and the entire team joined the buyer.[2]
This was a distribution acquisition. Fern had built the downstream layer that turns an API definition into something developers can understand and use. Postman already owned a broad upstream workflow for designing, testing, and collaborating on APIs, plus access to more than 500,000 organizations.[3] Combining the two gave Postman a stronger end-to-end API platform and gave Fern a route into an installed base it could not reach as quickly alone.
Image 1 / 1
Danny Sheridan, Deep Singhvi, and Zach Kirsch started Fern in 2022. Sheridan and Singhvi had met at the University of Michigan in 2015, then spent four years at Amazon and Palantir. There they saw Smithy and Conjure, internal systems that generated bindings in languages such as Python, TypeScript, and Java.[4]
The immediate trigger was failure. In Fern's January 2023 Show HN, the founders wrote, “We built Fern after our previous ed tech startup failed.” They had spent too much time writing repetitive API code instead of building the product.[5] OpenAPI helped describe endpoints, but the generated clients still needed templates, scripts, manual registry publishing, and language-specific repairs.
Fern joined YC's Winter 2023 batch.[6] The early pitch was technical: define an API once, validate it with a compiler, then invoke generators for SDKs, server code, Postman collections, and an OpenAPI specification. It was an infrastructure product before it was a developer-experience brand.
The team spent more than 18 months finding its first customer, Candid Health. Singhvi later said its 300-plus customer Slack channels “light up daily” with feature requests.[1] That slow start revealed a high-trust product shaped through close work with API teams.
Fern accepts OpenAPI, AsyncAPI, Protobuf/gRPC, OpenRPC, or Fern's own definition format. Its compiler validates the input, then generators produce client libraries in TypeScript, Python, Java, Go, Ruby, C#, PHP, Swift, and Rust. Fern can publish those packages and layer custom code over deterministic output.[8]
Fern Docs uses the same source material for API references, code examples, guides, and interactive exploration. Content can live in Git-backed Markdown, while non-engineering teams use a browser editor. Enterprise customers buy authenticated documentation, role-based access, localization, self-hosting, and support.
The combined product removed a common fracture. A company could otherwise use one system for docs, another generator for SDKs, scripts for package publication, and manual work to keep examples aligned. Fern made the API definition the shared input and treated the produced artifacts as one release surface.
Read the complete post-mortem, the rebuild playbook, and the exact reasons Fern is still worth studying now.