About this role
You make developer tools, so your users are engineers and developer experience isn't a polish pass at the end, it's the product. You need someone to own the surfaces developers actually touch: the SDKs, the API, the CLI, the docs, the time-to-first-success. This is the role I'm looking for. If those surfaces are bad, nothing behind them matters, and I'd treat that as the whole job.
What I'm looking for in you
- Small and technically serious; you believe a good SDK is a product, not an afterthought.
- You sweat the error messages and the first five minutes as much as the architecture behind them.
- Engineers own the developer-facing layer end to end, no PM translating between you and the people who actually use the thing.
- You ship in days, not planning cycles.
What you're building
Your product is the developer-facing layer and the systems under it:
- Idiomatic SDKs (maybe generated) in whatever languages the users are in
- A CLI, likely
TypeScriptorGodepending on the project - An API that reads like documentation
- Reference docs that stay honest
- The database that fits the data; I'm not attached to any particular engine, just the right one for the job
Success looks like how fast a developer gets from landing on the page to their first working call, and how rarely they file an issue to figure out what you meant.
What you can expect from me
I read an API and feel where it's going to hurt before I write a line against it:
- I've shipped open-source devtools other people install, agent skills that wire themselves into Cursor and Claude Code, and a CLI distributed through npm with thirty-odd releases behind it.
- I treat the SDK and the docs as product, not paperwork.
- I defend a clean interface in review without turning it into a fight.
