I publish open-source Go libraries. Not many people use most of them, and I've spent a fair amount of time trying to figure out why. Some of it is distribution. Some of it is the unsexy truth that nobody needed the thing I built. But a real chunk of it — bigger than I want to admit — is that the API was designed for me , the author, and not for the developer arriving cold from a Google search at 2am with a deadline. This post is three rules I now apply when designing a Go SDK. They come from publishing postgresparser — a pure-Go PostgreSQL parser — and watching where new users got stuck. The examples are from that library, but the rules aren't about parsers. They're about what the surface of a Go package should look like if you want strangers to use it. I'll also flag one place I broke my own rule, because the post would be dishonest without it. Rule 1: Expose answers, not nodes The single biggest mistake I see in Go SDKs (and that I've made myself) is shipping the internal data model as the public API.…