Skip to content
Scalar

Sales Development Representative

San Francisco, CA, United StatesOnsite · United States
FullTime · Sales
POSTED 31 AUG
Apply Ask
Role
70 days opentrue age
Posted 31 Aug
Payats field
$70k–85kposted
▼ −50% vs market median $157k
$70k$210k
Market p25–p75
$100k–$210k
SF Bay Area · n=2435 · 365d to 6 Nov
CompanyScalar →
5open roles
Opened · 30d
+0
Closed · 30d
−0
30d window
Market
416,220open · Other
Opened · 7d
+21,7765% of open
All other
623,569open
All tracked boards · live 9 Nov · n=416,220

About Scalar:

Building on a great API is one of the best feelings in software — every interface you want is right there, and it all just works. Building on a bad one is the opposite: out-of-date docs, no SDK in your language, no MCP server. We started Scalar to fix that.

We're a small team (around ten engineers and designers) who wear a lot of hats and obsess over our craft. We think every company deserves Stripe-level docs, SDKs, and MCP servers from day zero — not just the ones with a platform team to build them. Open-source is in our DNA: our whole team contributes to and maintains repositories across the API ecosystem, including the standards everyone relies on, like OpenAPI.

We keep things lean and move without layers of process — engineers pick up problems, talk to each other, and ship. We're looking for owners with high agency: people who see what needs doing and do it. If you do your best work with a lot of autonomy and very little ego, you'll feel at home here.

The role

Right now, sales at Scalar is Marc, our CEO, doing every part of it himself. Finding the account, writing the first email, running the call, going deep on the technical evaluation, negotiating the contract, onboarding the team. That's founder-led sales end to end, and it's worked — it's how we got Zoom, Clerk, Warp, and Profound.

It also doesn't scale, which is why we're hiring you.

We're hiring two SDRs to be the front of that motion, joining alongside our first Solutions Engineer at the same time. You'd be one of the first three people on the sales team — not the fifteenth rep on a floor running someone else's sequence.

Scalar has real pull already. Our API docs package alone is downloaded around 25 million times a month, and our team maintains open-source tooling that a large part of the API ecosystem depends on. What we don't have is anyone systematically turning that reach into conversations with the companies who should be paying us.

There is a motion here and it works — but it's Marc's, and it lives largely in his head. You'll sit next to him, learn how he opens these conversations and why they land, and then build the top of the funnel he has never had time to build. What you learn about what lands on this audience goes straight back into how we all sell.

Who we sell to

Zoom's developer documentation runs on Scalar. So does Clerk's. Warp and Profound ship SDKs we generate from their OpenAPI documents, in every language their users ask for.

Those are your prospects: engineering and platform leaders at companies with a real public API. They can smell a template from across the room, and generic outreach doesn't work on them. Outreach that shows you actually opened their API docs does — and that's the unusual advantage in this job. Almost every company worth contacting publishes their API docs, which means the evidence you need is sitting there in public before you write a single word.

You'll be selling a deeply technical product: documentation platforms, generated SDKs across six languages, and MCP servers that let agents do real work against a customer's API. You don't need to code. You do need to understand what those things are well enough that an engineering leader takes you seriously in the first ninety seconds.

What you'll work on

Outbound — building target lists of companies whose public APIs are underserved, and writing outreach specific enough that an engineering leader replies. We'll give you the tooling; you bring the judgment about who's worth a message

Research that earns the reply — opening a prospect's actual API docs and finding the thing worth leading with: the broken example, the endpoint with no code sample, the SDK that doesn't exist in the language their users keep asking for

Inbound — working signups, open-source users, and docs traffic, and figuring out which of them is a company and which is a side project

Qualification — running first calls, understanding what an engineering team is actually trying to fix, and handing over a meeting that Marc and our Solutions Engineer can close

Source · ScalarFirst seen 7 NovOriginal ↗