The Salary Math Took an Hour. The Calculator Took a Month.

Lex — Sat, 18 Jul 2026 08:36:50 +0000

Multiply an hourly rate by hours per week, then by weeks per year. That's the core formula behind a salary calculator, and you can write it in one line. I recently built SalaryHow, a browser-based calculator for comparing hourly and annual pay, and the arithmetic was genuinely the first hour of the project.

Everything after that hour was about a harder question: what does it take for someone to trust a number on a screen enough to use it in a real decision about a job offer?

This post is about the engineering and UX decisions that question forced. None of them involve novel computer science. Most of them involve assumptions, precision, and the strange fragility of interfaces that recalculate while you type.

The Formula Was the Easy Part

Here's the thing nobody tells you before building a pay calculator: two correct implementations can disagree.

Take $25 per hour. Is that $52,000 per year? Only if you assume 40 hours per week and 52 paid weeks. Assume 50 weeks (two unpaid weeks off) and it's $50,000. Assume 37.5 hours, common in plenty of workplaces, and the number moves again. Monthly pay is worse. Is a month annual divided by 12? Four weeks of pay? Something derived from 4.33 weeks? All three appear in the wild, and they produce visibly different numbers.

None of these are bugs. They're assumptions, and every calculator embeds them whether the author noticed or not.

So the first real engineering decision had nothing to do with code: pick defaults deliberately (40 hours, 52 weeks, 5 workdays, monthly = annual / 12), expose them as editable inputs, and state them near the results. A user who disagrees with an assumption can change it. A user who can't see the assumption just concludes your calculator is wrong, because their last paycheck says so.

The after-tax estimate got the same treatment. It's a single user-adjustable estimated tax rate, labeled as an estimate, with no pretense of modeling actual brackets or withholding. Presenting a rough figure honestly beats presenting a precise-looking figure that's wrong for almost everyone. It's an estimate for comparison, not tax advice, and the interface says so.

One Calculation Model, Not Five

My first prototype had the conversion math living in three components. The hourly view computed annual its own way, the results table computed monthly its own way, and a summary sentence did its own multiplication inline.

They disagreed within a day. A rounding difference here, a forgotten "weeks worked" input there, and the summary sentence contradicted the table above it. Nothing destroys trust in a calculator faster than the calculator disagreeing with itself on one screen.

The fix was boring and absolute: one module owns the math. Every input, whichever direction the user is working in, gets normalized into an annual gross figure first. Every other number is derived from that single value.

// Everything flows through one normalized base.
const annualGross = hourlyRate * hoursPerWeek * weeksPerYear;

const weekly = annualGross / weeksPerYear;
const daily = weekly / workdaysPerWeek;
const monthly = annualGross / 12;
const afterTax = annualGross * (1 - estimatedTaxRate);

Components render values. They never compute them. When someone works from the other direction and enters a salary, the same module derives the hourly rate from the same base, using the same assumptions.

This sounds obvious written down. It's also the single decision that prevented the most bugs, because every future change (a new pay period, a tweak to how workdays affect daily pay) happens in exactly one place, and every displayed number stays consistent with every other one by construction.

Round Once, at the End

Related lesson, learned the annoying way: intermediate rounding poisons everything downstream.

Early on I rounded values as they were computed, because tidy numbers felt right. Then a user-visible problem appeared: monthly pay times 12 didn't equal the annual figure shown two rows up.

// $47,000 / 12 = 3916.666...
const monthlyRounded = 3916.67;
monthlyRounded * 12; // 47,000.04

Four cents. Trivial mathematically, fatal for credibility, because the reader has no way to know the discrepancy is rounding and not a bug. If the calculator is four cents off on something they can verify, why believe it about anything they can't?

The rule that fixed it: full floating-point precision internally, everywhere, always. Formatting happens exactly once, at the presentation layer, through one shared currency formatter (Intl.NumberFormat handles this well). Internal values never round; displayed values always round the same way.

I'd apply that rule to any tool that shows derived numbers, not just this one.

Recalculating on Every Keystroke Is a UX Choice, Not a Free Win

There's no submit button. Change any input and every result updates immediately. People clearly prefer this, and it's what makes comparing scenarios pleasant: nudge hours per week and watch the annual figure respond.

It also creates a category of problems a submit button never has.

While someone types "27.50", the input passes through "2", "27", "27.", and "27.5". A naive implementation recalculates on each intermediate state, so the results flash through nonsense before landing. Clear a field entirely and a careless implementation shows $0 everywhere or, worse, NaN, which reads as "this site is broken" to anyone who doesn't write JavaScript.

The handling that ended up feeling right:

Parse leniently while typing. An empty or partial value keeps the last valid result on screen rather than zeroing everything.
Treat a genuinely invalid value (negative rate, letters) as "hold the previous result and quietly mark the field," not as an error modal.
Skip animations on the numbers. Early versions had a subtle count-up transition. It felt lively in a demo and exhausting in use, because real-time tools trigger it constantly. Numbers now just change.
Keep layout rock-stable. Result rows have fixed positions and reserved widths, so a value growing from $9,000 to $190,000 doesn't reflow the page.

Immediate is good. Twitchy is not. The line between them is entirely in how you handle the in-between states.

Hiding the Advanced Options Without the Page Jumping

Five inputs matter to almost everyone: the rate or salary, and hours per week. The rest (weeks worked, workdays, estimated tax rate) matter a lot to a minority and are noise to everyone else.

So the hourly to salary calculator shows the essential fields by default and folds the rest into an expandable "adjust assumptions" section. First-time users see a form they can complete in five seconds. People with unusual schedules can open the panel and model 50 weeks or a four-day week.

The mistake I made first: animating that panel open by pushing the results down. Expanding options shoved the numbers the user was looking at below the fold, which made the feature feel like a punishment for curiosity. The fix was reserving the layout so results stay anchored while options expand above or beside them, depending on viewport. Small thing. Completely changed whether anyone touched the advanced settings twice.

Reversing the Calculation Isn't Swapping Two Fields

I assumed the salary-to-hourly direction would be the hourly-to-salary form with inputs and outputs exchanged. Same math, after all.

It isn't the same product. Someone converting a salary into an hourly figure is usually asking a different question: often "what is my time actually worth given the hours I really work," which makes the hours-per-week input the emotional center of the page instead of an afterthought. The salary to hourly calculator leads with different labels, emphasizes the effective hourly result over the pay-period table, and explains its assumptions in the opposite direction ("based on X hours per week" rather than "assuming 52 paid weeks").

Defaults differ too. In the hourly direction, defaulting hours to 40 is a convenience. In the salary direction, 40 is an editorializing choice, because salaried people working 50 hours get a very different answer, and that difference is frequently the entire reason they came.

Shared math module underneath, per the earlier lesson. Different interface on top. Direction changes what users mean, and the UI has to honor that even when the arithmetic doesn't care.

A Number Without Context Is Half an Answer

The results area went through more revisions than anything else, and the pattern of every revision was the same: add context, remove decoration.

What survived:

A direct sentence above the table: "$25.00 per hour is about $52,000 per year, before taxes, at 40 hours per week." One line, answers the question, names the assumptions.
A table of pay periods (daily, weekly, biweekly, monthly, annual) with unambiguous labels. "Biweekly" specifically says every two weeks, since a surprising number of people conflate it with twice a month.
Gross and estimated after-tax shown as clearly separated figures, never mixed in one column.
No cents on large annual figures. $52,000 reads as honest; $52,003.47 reads as false precision when the inputs are estimates anyway.

The principle underneath all of it: the output should be understandable to someone who will never inspect the math, while remaining verifiable by someone who will.

Edge Cases That Earn Trust

Most users never enter zero weeks or a $4,000,000 salary. Testing those cases still matters, because the users who do poke at boundaries are exactly the skeptical ones deciding whether to trust you, and a NaN is disqualifying. Cases worth explicit tests:

zero hours or zero weeks (results should degrade gracefully, not divide by zero)
decimal rates like $27.53
one workday per week
50 or 51 weeks worked
more than 40 hours per week
0% tax and implausibly high tax rates
clearing an input mid-typing
switching calculation direction with values already entered (nothing should silently reset)

Each one is a five-minute test. Collectively they're the difference between a tool and a toy.

What I'd Prioritize Again

If I rebuilt this from scratch, the order of operations would change but four decisions would survive untouched.

Write the assumptions down before writing any UI. Every ambiguity you resolve on paper (weeks per year, the meaning of "monthly") is a contradiction you never ship.

Centralize the math ruthlessly. One module, one normalized base value, components that only render.

Separate precision from presentation. Full precision inside, one formatter at the edge, rounding exactly once.

Design for the in-between states first. Empty fields, half-typed decimals, and toggled options are where real-time tools live or die; the happy path was never the hard part.

The broader lesson generalizes past salary math. Any interactive tool is really two products: the calculation, which takes an afternoon, and the trust, which takes the month. Users can't audit your code, so they audit what they can see: whether the numbers agree with each other, whether the assumptions are visible, whether the interface stays calm while they think. Build for that audit and the tool gets used. Skip it and correctness won't save you.

DEV Community: Lex