<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Platform-Engineering on Omar Crosby</title>
    <link>https://omarcrosby.com/tags/platform-engineering/</link>
    <description>Recent content in Platform-Engineering on Omar Crosby</description>
    <image>
      <title>Omar Crosby</title>
      <url>https://omarcrosby.com/images/og.jpg</url>
      <link>https://omarcrosby.com/images/og.jpg</link>
    </image>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 07 Aug 2026 06:24:36 -0400</lastBuildDate>
    <atom:link href="https://omarcrosby.com/tags/platform-engineering/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>The anatomy of an SDK, in Go</title>
      <link>https://omarcrosby.com/posts/the-anatomy-of-an-sdk-in-go/</link>
      <pubDate>Fri, 07 Aug 2026 06:24:36 -0400</pubDate>
      <guid>https://omarcrosby.com/posts/the-anatomy-of-an-sdk-in-go/</guid>
      <description>A walkthrough of the surface an SDK exposes, in seven parts, with idiomatic Go for every piece: the client constructor with functional options, resource groupings that mirror the caller&amp;#39;s mental model, typed requests and responses, typed errors with request IDs and errors.As, first-class pagination via iter.Seq2, streaming and retries and instrumentation, and the docs/samples/changelog trio that finishes the surface. Companion to the SDK fundamentals post.</description>
    </item>
    <item>
      <title>What makes a good SDK</title>
      <link>https://omarcrosby.com/posts/what-makes-a-good-sdk/</link>
      <pubDate>Fri, 07 Aug 2026 06:24:36 -0400</pubDate>
      <guid>https://omarcrosby.com/posts/what-makes-a-good-sdk/</guid>
      <description>An eight-point rubric for judging whether an SDK is any good, each criterion paired with a real currently-shipping SDK that gets it right — Stripe (idiomatic hand-crafted per language, typed errors with request IDs, exceptional docs), AWS SDK for Go v2 (boring auth via the credential-provider chain, paginators as a distinct type), Anthropic and OpenAI (sensible retry defaults, streaming), Stainless-generated SDKs (types from a single spec), GitHub Octokit (honest versioning). Followed by the two-sided value proposition — what building on those axes actually buys for the vendor and the caller.</description>
    </item>
    <item>
      <title>Capability-first SDK design, and where new work belongs</title>
      <link>https://omarcrosby.com/posts/capability-first-sdk-design-and-where-new-work-belongs/</link>
      <pubDate>Fri, 07 Aug 2026 06:05:10 -0400</pubDate>
      <guid>https://omarcrosby.com/posts/capability-first-sdk-design-and-where-new-work-belongs/</guid>
      <description>The question is almost never &amp;#39;how do we add this method to the SDK?&amp;#39; — it&amp;#39;s &amp;#39;where should this capability live?&amp;#39; A companion to the SDK fundamentals post, covering capability-first SDK design (with the caller-sketch discipline as the practice), the five-way routing framework for new capability requests (pure SDK / additive API change / new endpoint / new API service / push down for generation), signals for extending an existing API vs. creating a new one (with Stripe Terminal and AWS Lambda as named examples), and the version-coordination process when a capability requires changes on both sides.</description>
    </item>
    <item>
      <title>What an SDK actually is, and when to build one</title>
      <link>https://omarcrosby.com/posts/what-an-sdk-actually-is-and-when-to-build-one/</link>
      <pubDate>Fri, 07 Aug 2026 05:34:04 -0400</pubDate>
      <guid>https://omarcrosby.com/posts/what-an-sdk-actually-is-and-when-to-build-one/</guid>
      <description>An SDK is not just a client library — it&amp;#39;s the smallest thing a platform can ship that turns &amp;#39;read our docs and call our API&amp;#39; into &amp;#39;install this and get to work.&amp;#39; First in a four-post series on SDK design: this one covers the fundamentals — what SDKs are, where they came from, how they differ from libraries and frameworks and protocols, why they&amp;#39;re becoming the product itself, and a concrete decision framework for when to build one. Companion posts cover the anatomy of an SDK&amp;#39;s surface in Go, the rubric for what makes one good with named exemplars, and the design-process question of routing new capabilities between the SDK and the API.</description>
    </item>
  </channel>
</rss>
