How to build a salary benchmarking tool with Claude

Last month I needed a salary range for a senior software engineer in Austin. Not a ballpark. A defensible number I could put in a job post and hold my ground on when the hiring manager pushed back.

My options were all bad. Pay thousands of dollars a year for a comp data subscription I couldn’t justify for a team our size. Dig through a market report from last September and hope the market hadn’t moved. Or do what I actually did: open a dozen tabs, cross-check Levels.fyi against a LinkedIn range against two numbers a recruiter friend texted me, and average them into a guess.

That guess took 40 minutes, and I didn’t trust it.

The frustrating part isn’t that good comp data doesn’t exist. It’s that it lives in someone else’s tool, shaped around someone else’s questions, priced for someone else’s budget. The number I needed, for this role at this level in this city at our stage, was never one click away. It was fifteen.

The data was never the hard part

For years the answer to this was simple. The data is the product, so you rent the data. You pay for the dataset and the tool around it comes along for the ride.

But the data was never the expensive part for a team like mine. Plenty of decent market data is public or already sitting in our own offer history. What I was really paying for was the interface and the upkeep. The thing that turns a column of numbers into an answer.

That part got cheap. I rebuilt the interface myself, in an afternoon, with Claude. It cost nothing, and it answers my questions instead of someone else’s. The data I still own. That distinction turns out to be the whole game, and I’ll come back to it.

Here’s where it landed. One page where I pick a role, level, location, and company stage, and get a median base, the full percentile range, a total comp breakdown, and a table of comparable roles to sanity-check against.

I’m going to walk through the exact build, prompt by prompt, because the prompts are the interesting part. Copy them and swap in whatever your team actually hires for.

The first prompt gets you something rough and working

I opened Claude, described the job I needed done, and let it write the code. Claude builds this kind of thing as an artifact, an interactive panel that runs right there next to the chat, so you see the working tool the moment it finishes.

Here’s the opening prompt:

I'm in people ops. I want a simple internal salary benchmarking tool
I can use in the browser. Let me pick a role, a level (entry / mid /
senior), and a location, and show me an estimated median base salary
plus a typical range. Build it as a single self-contained HTML file
with the data baked in, so I can run it without a server. Use
believable US market numbers as placeholders for now.

Thirty seconds later, this:

It’s plain. The numbers are placeholders Claude generated. But it works. Pick a role, get a range, and the math stays consistent as you change the inputs. That’s the right place to start.

Notice what the prompt did and didn’t ask for. I described the job to be done, not the design. I didn’t say “make it look good” or specify a single color. Design is easy to bolt on once the logic is right, and asking for it too early just gives you a pretty thing that calculates the wrong numbers.

Refine the model until it answers real questions

A single median is almost useless on its own. Nobody gets hired at exactly the median, and base salary is only part of what you’re offering. So the next prompt pushed the model closer to how comp actually works:

Good start. Now make it more useful:
- Add a company stage input (seed, Series A-B, Series C+, public).
- Show the full distribution: P10, P25, median, P75, P90, as a
  labeled range bar.
- Break out estimated total comp: base, bonus or variable, and
  annualized equity, with a stacked bar.
- Recalculate live whenever I change any input. Keep it one file.

This is the version I’d actually use. The range bar matters more than the single number, because the gap between P25 and P75 is the real conversation with a candidate and a hiring manager. And splitting base from bonus and equity is the difference between a number and an offer. For an early-stage role, equity can do half the work, which never shows up if all you quote is base. That blind spot is exactly the total compensation gap that makes offers fall apart at the last step.

Switch to a senior software engineer in the Bay Area at a Series C company and the tool now shows a $213k median, a $189k to $240k typical range, and roughly $264k in total comp once you add variable pay and annualized equity. Same logic, different inputs, instant answer. That’s the thing I could never get from fifteen browser tabs.

The data is the part you can’t outsource

Here’s the prompt that matters most, and it has two halves.

Two changes. First, add a "comparable roles" table showing every role
at the same level and market, so I can sanity-check relative pay.
Second, and put this where I can't miss it: add a clear note that
these are directional placeholder numbers, not a source of truth, and
that I should replace them with our own offer data before making any
real offer.

I told Claude to write that warning into the tool on purpose. The placeholder numbers look authoritative the second they sit in a clean interface with percentile bars next to them. They aren’t. They’re a model’s best guess from public ranges, and a confident wrong number is more dangerous than an obvious blank, because you stop questioning it.

So the real step, the one that turns a toy into a tool, is the second half of the prompt:

Here's our actual data. I'm pasting our last 18 months of offers as a
CSV (role, level, location, base, bonus, equity). Replace the
placeholder dataset with this and recompute every median and
percentile from our real numbers.

Now the tool isn’t telling me what the internet thinks a role pays. It’s telling me what we have actually paid, structured so I can extend it to roles we haven’t hired for yet. If you don’t have enough offer history, a licensed compensation dataset works the same way. So do the published ranges that pay-transparency laws now put on most job posts in your market. The point is the same either way: the source has to be something you’d defend in a calibration meeting, not something a model invented. This is the unglamorous half of any data-driven recruitment effort, and it’s where most of them quietly fall down.

The part that actually runs the whole thing

You don’t need to read code to build this. But it helps to see the engine, because it’s smaller than you’d think. Everything Claude wrote comes down to a few lookup tables and one line of math:

const ROLES = {
  "Software Engineer": { base: 130000, bonus: 0.08, equity: 0.16 },
  "Product Manager":   { base: 138000, bonus: 0.12, equity: 0.15 },
  "Recruiter":         { base: 82000,  bonus: 0.09, equity: 0.06 },
  // ...one line per role
};
const LEVELS    = { Entry: 0.78, Mid: 1.0, Senior: 1.32, "Staff / Lead": 1.62 };
const LOCATIONS = { "San Francisco Bay Area": 1.24, "New York City": 1.16, Austin: 1.0, "Remote (US)": 0.96 };
const STAGES    = { Seed: 0.92, "Series A-B": 0.97, "Series C+": 1.0, "Public / Enterprise": 1.06 };

// Median base = a role's national median, adjusted for level, market, and stage.
function medianBase(role, level, location, stage) {
  return ROLES[role].base * LEVELS[level] * LOCATIONS[location] * STAGES[stage];
}

That’s the whole idea. A base number per role, then multipliers for level, market, and stage. The percentile bars, the stacked chart, the table, and the styling are all presentation that Claude handles. The model is the part that’s yours to argue with, and it’s readable enough that you can. If you think Austin shouldn’t sit at the national baseline, you change one number. Try doing that inside a subscription tool.

Shipping it took one more prompt

This is what I want. Give me the final file so I can host it, and tell
me the two-line change I'd make each quarter to refresh the numbers.

Claude handed back the file and the instructions. I dropped it on an internal page behind our SSO, though you could just as easily keep it as a published artifact with a private link, or paste it into a Notion embed. Refreshing it every quarter means swapping the dataset and nothing else. The interface I built once. The numbers I update in two minutes.

What this is and what it isn’t

This tool helps me think. It does not make the call.

The scaffolding numbers are not offers. Even with our real data loaded, the output is a starting point for a conversation, not a verdict. Comp is judgment plus a real legal surface, from pay-transparency rules to pay-equity reviews, and none of that is something you want a lookup table deciding for you. The right way to use the range is to bring it into the process early, the way you’d put pay range alignment in the first screening call so you don’t fall in love with a candidate who’s $30k out of band. When it’s time to actually write the thing, your offer letter still has to reflect the specific person, not the median of a category.

In other words, the AI built the interface and does the arithmetic. The data and the decision stay with me. That’s not a limitation I’m working around. It’s the line I want to keep.

The build-versus-buy line moved

The reason this matters goes past comp.

For a long time, a small team’s answer to almost any workflow gap was to buy a tool, because the build option meant engineering time we didn’t have. Claude changed that math for a specific class of problem: contained, logic-shaped tools where you already know the rules and just need an interface wrapped around them. A salary benchmarker is one. So is a PTO accrual checker, a leveling rubric, an interview-debrief scorer. Things you used to rent, you can now build before lunch.

What didn’t change is the other class of problem, where the hard part isn’t the interface, it’s judgment at scale. Screening is the clearest example. A good salary range gets you more applicants, which means more resumes to read and more people to talk to, against the same number of hours in your week. You can’t prompt your way out of reviewing 300 candidates by Friday.

That’s a different kind of tool. Truffle is candidate screening software that combines resume screening, one-way video interviews, and talent assessments, so you design the screening process that fits the role instead of bolting separate tools together. The benchmarking tool tells you what to pay. Something like Truffle handles what shows up after you post the role at that number: AI transcribes and scores each response against the criteria you set, then surfaces a ranked shortlist with 30-second highlights, so you spend your time on the few conversations worth having. The arithmetic of a comp range is a job for an afternoon project. Reading a flooded funnel without losing your week is a different problem, and you stay in control of the call either way.

So the question I keep coming back to in 2026 isn’t “what should we buy.” It’s two questions. What can I build now that I couldn’t last year. And what should I still trust a person to decide. The salary tool sits firmly in the first bucket. Who gets the offer sits firmly in the second. Most of the job is knowing which is which.