SDK Engineer - JavaScript

Job description

About this role

Our JS/TS SDKs are the front door to the platform: database queries, auth, storage, realtime subscriptions and edge functions, used by a very large number of developers and by most of the AI coding tools building on Supabase today. This is a library-authoring role, and the work happens in the open: public repos, public issue trackers, and API decisions whose consequences are permanent. The type system here is a design surface rather than a formality. If you get satisfaction from an inference that Just Works, from a migration guide that saves people an afternoon, and from an issue tracker that isn't a graveyard, you'll like it here.

Responsibilities

• Build and evolve our JavaScript/TypeScript SDKs.
• Start new things. Alongside the maintenance work, you're expected to find what's missing, make the case for it, and build it. Some of what we ship next doesn't exist yet, and nobody will hand you the list.
• Work in the open. These are public repos: you'll triage inbound issues, review and shepherd outside contributions, keep CI and release automation healthy, and hold a clear, kind line on scope.
• Own the type experience. Keep generated database types flowing correctly through the client APIs so autocomplete and inference stay correct in real codebases.
• Keep us honest across runtimes. Node, Deno, Bun, browsers, Cloudflare Workers, React Native/Expo, including dual ESM/CJS publishing and types that resolve correctly under every module resolution mode. Test it, don't assume it.
• Work on realtime. Long-lived WebSocket connections, reconnection, and subscription and presence semantics.
• Track the platform. When auth, realtime, storage, postgrest or edge-runtime ship a change, make sure the SDKs reflect it, and that we say so in the changelog.

Qualifications and requirements

• Expert-level TypeScript. You use generics, conditional and mapped types as design tools, you can explain why an inference breaks.
• You've authored or maintained a published library with a public API and consumers outside your own company. You know what it costs to change something people depend on.
• You've worked on open-source projects and know the maintainer side of them. Issue triage at volume, reviewing outside PRs, release automation, changelogs and semver, security reports, and saying no to a feature request without losing the person who asked.
• npm packaging fluency: dual ESM/CJS builds, export maps, type resolution, semver discipline, and the failure modes consumers actually hit.
• Testing as a habit: unit, type-level and end-to-end against a real stack. Every fix comes with a regression test.
• Strong written communication. Design docs, changelogs and issue replies are a large part of the output here, much of it public, and we're async by default.
• Real autonomy: you find the important work, scope it, ship it, and say what you didn't do.
• Communicate clearly across both technical and non-technical audiences.