I've been working on a project called OvertimePayRate.com, and one thing I've learned so far is that a calculator can look simple on the surface while hiding a surprising amount of complexity underneath.
The idea sounds straightforward.
Enter your pay rate, add your overtime hours, select your state, and get an estimate of your overtime pay.
Pretty simple, right?
Well, not exactly.
The problem isn't the math
Calculating time-and-a-half is relatively easy. If someone earns $20 per hour, the usual overtime rate of 1.5× would be $30 per hour.
The harder part is figuring out which rules should apply in the first place.
Overtime rules in the US can vary by state. Federal requirements, state-specific provisions, salary thresholds, exemptions, and different work situations can all affect the calculation.
A basic calculator can give someone a number in seconds, but that doesn't necessarily mean the number reflects their circumstances.
That's what made this project interesting to me. I didn't want to build just another form with a few multiplication operations behind it. I wanted to explore how to make the result more useful while being honest about its limitations.
What I'm building
OvertimePayRate.com is an overtime pay calculator focused on workers in the United States.
The goal is to let users estimate their overtime pay without having to navigate a complicated spreadsheet or search through a dozen pages just to get started.
Some of the things I'm working on include:
- State-specific calculations: Overtime rules aren't identical everywhere, so state selection needs to matter.
- Occupation-based inputs: A person's work situation can affect which rules need closer examination.
- A rule-based calculation engine: Keeping calculations separate from the UI makes the logic easier to test, review, and maintain.
- Clear explanations: Showing a result is useful, but explaining the assumptions behind that result matters too.
I'm also treating legal accuracy as an ongoing responsibility, not something that can be solved by writing a calculation once and forgetting about it.
The results are estimates, not legal advice or a determination of what a particular employer owes.
The technical side
For the stack, I'm using technologies I wanted to explore in a real project rather than another tutorial.
- Astro for the site and its page structure
- React and TypeScript for interactive calculator functionality
- Tailwind CSS v4 for styling
- Supabase and Drizzle ORM for the database layer
- Cloudflare for deployment
One architectural decision I'm paying particular attention to is separating the rules and calculation logic from the presentation layer.
When a rule changes, I don't want to hunt through UI components trying to figure out where a number was hardcoded. I want the relevant rule to be identifiable, testable, and associated with the period during which it applies.
That becomes especially important for a project dealing with laws and regulations, where a rule that was valid last year might not be valid today.
Of course, having a clean architecture doesn't automatically make the underlying legal data correct. Official sources still need to be checked, and the calculations need tests for the situations they're supposed to cover.
SEO is another challenge I'm thinking about
A calculator is useful, but people also need to be able to find it.
I'm working on making the site accessible through state-specific calculator pages and supporting content, rather than relying on a single homepage to answer every possible question.
That introduces another challenge: creating pages that actually help users instead of generating dozens of nearly identical URLs with different state names.
I'd rather have fewer pages with a clear purpose than a large number of pages that don't add much value.
It's also a reminder that building a useful web tool involves more than getting the core feature to work. Performance, accessibility, discoverability, maintainability, and trust all matter.
What I'm learning from the project
The biggest lesson so far is that the most interesting engineering problems aren't always the most visually impressive ones.
A calculator's interface might take only a small part of the development effort. The decisions behind the result can take much longer: how to represent rules, how to handle exceptions, how to test edge cases, and how to communicate uncertainty without confusing the user.
I'm also trying to avoid the temptation to make the project appear more complete than it is. For something that touches employment rules and money, being transparent about what a tool can and cannot determine is part of building it responsibly.
There is still plenty to improve, and that's part of the process.
If you're building a calculator, legal-information tool, or another small web product, I'd be interested to hear how you approach changing rules, edge cases, and keeping the results trustworthy.
You can check out the project here: OvertimePayRate.com
Thanks for reading!
Top comments (0)