Salary Equity Analysis Tool

I've been experimenting with vibe coding long enough to form a strong opinion: the most compelling use case for AI in the compensation field right now is using vibe coding to replace Excel.

Think about it — I wouldn't trust an LLM to make salary decisions or run analysis I can't repeat. At the end of the day, a large language model looks for the most statistically probable answer, not necessarily the right one. However, I can trust apps I've built and tested, because they will always deliver results using the same algorithm.

Salary transparency and pay equity are major themes right now, and a point of controversy. Excel allows us to run simple analyses to identify compensation disparities, but things get difficult when we want to account for performance, location, and tenure simultaneously.

So I built an app — a fully functional salary equity analyzer that normalizes data based on those parameters. It took me about 8 hours using Claude Code. The tool runs multiple linear regression, identifies at-risk employees, generates PDF reports, and is now live. Click the button at the top of this page to try it yourself.

Pay equity analysis tools from vendors can cost thousands per year. This one is free. I do ask that you not include identifiable employee data — I have no control over how long files are stored on the server.

This post walks through exactly how I did it — the process, the prompts, and the honest reality of how difficult it was.

The Tool I Built

The Salary Equity Analyzer is a web application that lets you upload employee compensation data in CSV format and run a statistical pay equity analysis. Here's what it does:

• Validates your data for missing fields, formatting issues, and salary outliers

• Runs multiple linear regression controlling for job title, experience, location, and performance

• Calculates gender and race pay gaps with confidence intervals across five progressive adjustment models

• Identifies specific employees who may be underpaid relative to their peers using studentized residuals

• Generates a pay equity score from 0 to 100

• Exports results to CSV and PDF with an executive summary

The statistical methodology follows industry best practices for pay equity audits — log-transformed salary as the dependent variable, dummy-coded categorical predictors, and progressive model building to show how gaps change as controls are added.

The Process: From PRD to Deployment

Step 1: Write a Product Requirements Document

Before touching any AI tool, I wrote a detailed PRD. This is the single most important step. A vague prompt produces vague results. A detailed specification produces a working application.

My PRD covered the data schema, statistical methodology (down to the regression equation), UI requirements, privacy warnings, export formats, and edge cases like small sample sizes. I used Claude to help draft and refine it. I did not choose statistical methodology. I started with vague description and kept updating my asks until PRD seemed complete. Then I used another AI and asked it to poke holes in PRD and suggest improvements.

The PRD is available as a downloadable resource HERE. If you're building something similar, start there.

Step 2: Break the Work into Tasks

I fed the PRD to Claude and asked it to break the document into a sequenced task list with specific prompts for each step. It produced a structured build plan, 70% of which contained unfamiliar words.
I had no idea what Node.js or React were before the AI started coding through my task list. I wrote the PRD in the language of compensation analysis — data fields, statistical methods, business requirements. The AI chose the technology stack. I just had to trust the process and focus on whether the output matched my requirements.
AI produced a structured build plan:

1. Project scaffolding — set up the full-stack structure (Node.js + Python + React)

2. Data import and validation — CSV upload, schema validation, outlier detection

3. Core statistical engine — the regression analysis in Python using statsmodels

4. Advanced statistics — intersectionality analysis, model diagnostics, pay equity scoring

5. Results dashboard — visualizations, pay gap charts, at-risk employee tables

6. Export functionality — CSV and PDF report generation

7. Testing and deployment — Railway hosting with Docker

The plan also included prompts. Each prompt was detailed and specific. For example, the statistical engine prompt included the exact regression equation, the expected JSON output format, which Python libraries to use, and how to handle edge cases. The more specific the prompt is, the better the output.
And I used another AI again to review the build plan and suggest improvements. Now, many improvements were overkills. You need to understand that every small add-on add complexity. So I rejected an idea to connect to Google Docs, because that would’ve required user authorization which is a whole chapter in the build plan. I limited data processing ability to some reasonable number of records, the number that wouldn’t need me to rent a cloud space for storage. And there were other things to keep it simple.

My most focused work were - PRD and Build Plan (aka To-Do list), I spend about 4 hours on and off perfecting them.

Step 3: Build Iteratively

I ran each task through Claude Code in my terminal. This was the first time I used terminal! I did it on Mac. I always knew what terminal was, but never needed it.
And here I just turned myself into Claude secretary. I have started a separate chat, uploaded PRD and Build Plan, and asked Claude to guide me through building app using Claude.

Claude told me to:

1. Navigate to the project folder

2. Launch Claude Code

3. Paste the task prompt

4. Review the changes Claude Code proposes

5. Approve, test, iterate

Claude Code reads your entire codebase, understands the project structure, and makes targeted edits. It's not generating code in isolation — it knows what already exists and builds on it.
At some point some tools were missing. For some forgotten to me reasons I had GitHub Repo (I had very vague idea what that is), but I needed to connect me to my Mac, and Claude. And that Node.js didn’t want to start and etc. Every time I would just copy error into my Claude-guiding chat and do what it told me to do.

Step 4: Fix What Breaks (Because Things Will Break)

This is the part most vibe coding tutorials skip. Things broke. Multiple things.

Here's a sample of issues I encountered:

• Hardcoded Python path: The code referenced /usr/bin/python3.11 — which worked on my machine but would fail on any deployment server. Claude Code replaced it with dynamic Python detection using environment variables. - BTW, I copied this line from Claude Chat, I understand every word separately, but together they only make half-sense to me

• Dead authentication code: The app had OAuth login flows that weren't connected to anything. Apparently that Google Docs idea wasn’t removed completely. Clicking "Start Analysis" crashed the page. Claude had to strip out the dead code.

• Broken export button: The export feature didn’t work. It referenced a wrong field name in the data layer according to Claude. The button existed in the UI but did nothing when clicked.

• Corrupted PDF generation: Exported PDFs wouldn't open. Claude said the file stream wasn't closing properly before the HTTP response was sent.

• Missing gender in results: When running analysis on equitable test data, the dashboard only showed Male and Non-Binary pay gaps — Female was being used as the regression reference group and silently excluded from the visualization.

Each of these was fixable with a targeted prompt to Claude Code describing the symptom. The key lesson: vibe coding isn't "set and forget." You need to test every feature, read error messages carefully, and be specific when describing bugs.

Step 5: Deploy

Deployment required its own set of decisions. I use Squarespace, Claude informed me that the app runs on both Node.js and Python and can’t deployed on Squarespace, so I needed to choose another hosting options. I chose Railway because pricing seemed reasonable. Claude Code generated the Dockerfile (again, no idea what that is), configured the multi-stage build, and set up the railway.toml configuration.

The first deployment failed — according to Claude the production build was importing Vite (a development tool) at runtime. Another targeted fix. Second deployment succeeded.

I connected a custom subdomain through my DNS provider, Railway auto-provisioned SSL, and the tool was live.

Even though steps 3-5 took another 4 hours, most of this time I was catching up on missed episodes of Traitors on Peacock, playing with my dog, and following Claude instructions almost mindlessly. The only decision I have made consciously was how much I wanted to spend on app hosting.

The Honest Assessment

Total time from blank page to live deployment: approximately 8 hours spread across one day. That includes writing the PRD, building all features, debugging, and deploying.

Could a professional developer build a better version? Absolutely. According to Claude the code has rough edges — the type system could be tighter, test coverage is minimal, and some potentially cool features (cohort analysis, Google Sheets integration) weren’t implemented.

But for an HR professional who needs a working pay equity analysis tool? This does the job. The statistical methodology is sound, the results are interpretable, and the tool is live and accessible.