Paytrix: From Interface Logic to

Paytrix: From Interface Logic to Compensation Infrastructure

The Insight The builder behind Paytrix understood compensation deeply, not as a payroll function, but as a structural problem. They knew that most companies manage salary bands in spreadsheets, that job title normalization is a nightmare at scale, and that equity analysis gets ignored until it becomes a legal liability. They knew this because they lived it.

So they built what they knew. Fast.

What Existed Paytrix, as delivered, was a polished React application, built with Vite, Tailwind, Radix primitives, and Recharts, spanning six distinct modules: a dashboard, an HRIS data upload flow, a compensation modeling engine, a scenario simulator, an equity analysis suite, and a settings panel. The interface was sharp. The workflows were correct. A user could upload employee data, watch AI "normalize" job titles into a structured architecture, model salary bands against market percentiles, run budget impact scenarios, and review compression risks across career levels.

It looked like a product.

But every piece of logic lived on the client.

Where It Breaks The 114 employees in the system are not uploaded. They are hardcoded in a TypeScript file. The "AI normalization" is a setInterval cycling through four progress labels over two seconds. Market benchmarks are arithmetic constants (industryPremium = 0.08). The equity analysis, compa-ratios, range penetration histograms, compression heatmaps, renders from static arrays defined at the top of the component. Scenario simulation multiplies a base salary by a percentile offset. The entire application state persists to localStorage.

None of this is a criticism. It's what a vibe-coded prototype should be: directionally correct, visually convincing, structurally hollow.

The problems emerge when you try to use it: • No persistence. Clear your browser, lose your scenarios. There's no database, no user accounts, no tenant isolation. • No real data ingestion. The upload flow accepts nothing. There's no CSV parser, no file handler, no validation pipeline. The "AI" that maps "Sr. Software Engineer" to "Engineering / L3 - Mid-Level" is a pre-written array with confidence scores already assigned. • No market data layer. Salary benchmarks are invented constants. There's no connection to BLS, Radford, Mercer, or any compensation data provider. The "industry premium" and "funding stage adjustment" are fixed floats that don't change regardless of input. • No computation engine. Compa-ratios, range penetrations, and compression risks are display values, not derived metrics. Change an employee's salary in the mock data and the equity charts do not move, because the charts read from a different hardcoded array. • No multi-user support. "Welcome back, Alex" is a string literal. There's no auth, no RBAC, no concept of who should see what.

The logic was all there. It just had nowhere to live.

The System That Needed to Exist

What Paytrix required was not more UI work. It required the invisible layer that makes compensation software trustworthy.

Data Ingestion Pipeline A backend service that accepts HRIS CSV uploads, validates schema (employee ID, title, department, salary, location, demographics), handles malformed data gracefully, and stages records for processing. This is not a file drop. It is an ETL pipeline with column mapping, deduplication, and audit logging. The upload endpoint needs to support files from Workday, BambooHR, Rippling, and manual exports, each with different schemas.

Job Architecture Normalization Service The prototype simulates AI-driven title mapping. In production, this is a classification service, likely backed by an LLM or a trained model, that ingests raw job titles and maps them to a canonical taxonomy of families and levels. It needs to handle ambiguity ("Sr. Software Engineer" vs. "Senior Software Engineer" vs. "SWE III"), surface confidence scores that reflect model uncertainty, and support human-in-the-loop correction that feeds back into the model. This is a backend job queue, not a frontend animation.

Market Data Integration Layer Compensation modeling requires real benchmark data. The system needs API integrations with at least one primary data provider (Radford, Mercer, Comptryx) and the ability to ingest custom survey data. Market rates need to be indexed by role, geography, industry, company size, and funding stage. This is a multi-dimensional lookup that changes quarterly. This data must be versioned and cacheable, with fallback logic when specific cuts are not available.

Compensation Calculation Engine The core math, midpoint derivation, band construction, compa-ratio computation, range penetration, compression detection, needs to run server-side against real employee records and real market data. The prototype calculates midpoint = baseMarket * (1 + industryPremium + fundingAdjustment) * percentileMultiplier. In production, this becomes a parameterized model where each variable is resolved from the market data layer, scoped to the company’s configuration, and applied across every employee in the dataset. Band width, skills premiums, and geographic differentials are all configurable per job family.

Scenario Persistence and Comparison The prototype stores scenarios in React context backed by localStorage. Production requires a database-backed scenario system where a user can save named configurations, compare them side by side, share them with stakeholders, and track which scenario was ultimately adopted. Each scenario needs to carry its full parameter set, the resulting budget impact, and a snapshot of the employee population it was run against.

Equity Analysis Engine The hardcoded charts need to be replaced by a statistical analysis service. Gender and ethnicity pay gap calculations require controlled regression, adjusting for level, tenure, location, and department, not raw averages. Compression detection needs to compare adjacent levels within the same job family dynamically. Flagged roles need to be generated algorithmically, not listed manually.

Authentication, Tenancy, and Access Control Compensation data is among the most sensitive in any organization. The system needs proper auth (SSO at minimum for enterprise), tenant isolation so each company sees only its data, and role-based access so an HR analyst sees different things than a VP of People. Audit logging is non-negotiable. Every view, edit, and export must be tracked.

What Changed

The interface did not need to be rebuilt. It needed something behind it.

What was a demo became a system. What was localStorage became a database. What were constants became integrations. What was a progress bar became a processing pipeline.

The prototype proved the idea was right. The architecture made it real.

From demo-ready to production-ready. From UI-driven logic to system-driven reliability.

We built the layer that made it dependable.