DEV Community: Saurabh Sharma

What I Learned Building a Payroll Calculator Site Solo (Not Truly Solo 😅)

Saurabh Sharma — Fri, 14 Aug 2026 07:54:02 +0000

PayTimeHub started as one page - a paycheck withholding calculator - because I couldn't find one online that didn't bury the number under three popups and an email gate. It's since grown into a small family of calculators: paycheck withholding by state, a raise calculator, hourly-to-salary conversion, hours-to-decimal timesheet conversion, and time-and-a-half overtime. Nothing behind a signup, nothing sent to a server. A few things stood out along the way that I didn't expect going in.

The tax logic is the actual product

I assumed the hard part would be the frontend. It wasn't. Federal withholding is a set of published brackets, but state withholding is fifty different rulebooks, several of which don't tax income at all, some of which have their own standard deduction schedules, and a couple that change their brackets more often than you'd think reasonable for a tax table. Getting [state]-paycheck-calculator right per state meant the actual engineering effort lives in a tax engine, not in a component tree. The UI took a weekend. The tax logic is still the thing I go back and double-check.

The lesson: for a "calculator" site, the calculator is the product. Everything else - layout, copy, SEO - is packaging around a number that has to be correct, because a wrong number here isn't a cosmetic bug, it's a wrong paycheck estimate someone might actually plan around.

Floating-point math will find you eventually

Money math in JavaScript looks fine until it doesn't. 0.1 + 0.2 not equaling 0.3 is the famous example, but the version that actually bit me was subtler: a raise calculation that produced $53,999.999999999996 instead of a clean $54,000 on one specific input, not because of an obviously bad float, but because the multiplication itself introduced error just below a rounding boundary. I wrote about that one separately, but the broader takeaway was that every calculator that touches money needs to funnel through the exact same rounding function, or you end up with five slightly different .toFixed(2) calls that quietly disagree with each other on the edges.

Static-first is a feature, not a shortcut

Astro was the right call, but not for the reason I expected going in. I picked it for the build output - static pages, minimal JS, fast Lighthouse scores. What turned out to matter more is that "no server, no data leaves the browser" isn't just a privacy pitch, it removes an entire category of things I don't have to build: no auth, no database, no rate limiting, no GDPR data-handling story. The calculators run entirely client-side. That constraint made the whole project smaller in a good way - there's less surface area for something to go wrong, and less to maintain six months from now.

Dynamic routes make "fifty states" tractable

Before I set up [state]-paycheck-calculator and [value]-salary-to-hourly as dynamic routes, I was mentally treating "add all 50 states" as fifty separate pages to hand-write. That's the wrong mental model for this kind of site. One template plus a data file per state is the actual shape of the problem, and it's the difference between a task that takes a weekend and one that never gets finished because it feels too big to start.

Shipping something narrow beats shipping something broad

Early on I was tempted to build a general "financial calculator suite" - retirement, mortgage, budgeting, the works. I'm glad I didn't. Payroll and pay math is a coherent enough niche that the calculators reinforce each other: someone converting hourly to salary is plausibly also the kind of person who wants to know their overtime rate or their raise in real terms. A broader suite would have diluted that, and I'd have shipped ten shallow tools instead of five that actually do their one job well.

What's next

More state-specific accuracy passes, and probably a couple more calculators in the same vein - the goal isn't to cover every financial calculation that exists, just to keep doing pay and payroll math well. If you're curious, the whole thing is live at paytimehub.com.

The rounding bug that almost shipped in a payroll calculator

Saurabh Sharma — Fri, 14 Aug 2026 07:47:02 +0000

I've been building PayTimeHub, a set of free payroll and pay calculators - paycheck withholding, raise calculator, hours-to-decimal, time and a half. Money math looks trivial until you actually ship it, and one bug almost got through that's worth writing up.

The setup

Every calculator on the site takes a dollar amount, does some arithmetic on it, and shows the result back to the user. A raise calculator multiplies a salary by a percentage. An overtime calculator multiplies an hourly rate by 1.5. Simple stuff, until you remember that JavaScript does floating-point math.

Try this in a console:

0.1 + 0.2
// 0.30000000000000004

Now imagine that showing up on a page that's supposed to tell someone their new salary. A $52,000 salary with a 3.85% raise should read as a clean $54,000. Depending on how you chain the multiplication and division, you can end up with something like $53,999.999999999996, which then gets formatted and displayed as a genuinely wrong number - or worse, rounds inconsistently between two calculators that are supposed to agree with each other.

The fix

Nothing exotic, just a single shared rounding function that every calculator on the site routes its output through before display:

export function roundCurrency(amount: number): number {
  return Math.round((amount + Number.EPSILON) * 100) / 100;
}

The Number.EPSILON nudge matters more than it looks like it should. Without it, plain Math.round(amount * 100) / 100 still misfires on specific inputs, because the multiplication itself can introduce a floating-point error just below a rounding boundary, so a value that should round up rounds down instead. Adding the smallest possible float before rounding pushes those edge cases back onto the correct side without changing any value that wasn't on the boundary to begin with.

Why it's worth writing down

The interesting part isn't the fix - it's that this exact class of bug is invisible in casual testing. Round numbers like $50,000 and 5% never trigger it. It shows up on the specific combinations that don't divide cleanly, the ones a user actually types in, not the ones a developer thinks to test.

Every money-handling calculator on the site now funnels through one rounding function instead of each one doing its own .toFixed(2) inline. Partly for consistency, but mostly so this bug only had one place it could hide.

If you're building anything that does arithmetic on money in JavaScript and displays the result, it's worth checking whether you have one rounding function or five slightly different ones scattered across the codebase. It's an easy thing to get right once, and an easy thing to get subtly wrong five separate times.

Built with Astro, if anyone's curious about the stack. The site itself is at paytimehub.com if you want to see it in action — specifically the pay raise calculator, where this first came up.

🧭 React Router Crash Course (Beginner Friendly)

Saurabh Sharma — Thu, 04 Dec 2025 08:29:45 +0000

Learn what routing is, why it matters in React, and how to set it up step-by-step — with a mini React demo project.

🧐 What Is Routing in React?

So, what the heck is routing?

In simple terms, routing controls what your app shows when a user navigates to different pages.

That’s it! When you click on something like “About” or “Contact,” routing decides which component gets displayed on the screen.

🌐 How Traditional Routing Works

Before SPAs (Single Page Applications), websites used normal HTML navigation with the <a> tag:

<a href="/about">Go to About Page</a>

Every time you clicked on that link, the browser reloaded the page from scratch. That means your app reset, and the DOM (Document Object Model) re-rendered completely — not very efficient!

⚛️ React: The Power of Single Page Applications (SPA)

React builds Single Page Applications, where everything runs inside one main HTML file: index.html.

When navigation happens, React simply replaces parts of the UI dynamically, rather than reloading the entire page.

But to make that navigation magic happen, React needs help — that’s where react-router-dom comes in.

📦 Installing React Router

React itself doesn’t handle routing, so you’ll need to install a library for it. The most popular one is react-router-dom.

Use your package manager of choice:

npm install react-router-dom

Or:

pnpm add react-router-dom

🏗️ Step 1: Setup `BrowserRouter`

After installing, wrap your whole app with BrowserRouter.

This enables React Router throughout your application.

// main.jsx
import React from 'react'
import ReactDOM from 'react-dom/client'
import { BrowserRouter } from 'react-router-dom'
import App from './App.jsx'

ReactDOM.createRoot(document.getElementById('root')).render(
  <BrowserRouter>
    <App />
  </BrowserRouter>
)

That’s your basic setup! Without this step, your app won’t understand routes.

🗺️ Step 2: Define Routes with `<Routes>` and `<Route>`

Now it’s time to tell React what to show on each URL path.

// App.jsx
import { Routes, Route } from 'react-router-dom'
import Home from './pages/Home'
import About from './pages/About'
import Contact from './pages/Contact'
import NotFound from './pages/NotFound'

function App() {
  return (
    <Routes>
      <Route path="/" element={<Home />} />
      <Route path="/about" element={<About />} />
      <Route path="/contact" element={<Contact />} />
      {/* Catch all unknown routes */}
      <Route path="*" element={<NotFound />} />
    </Routes>
  )
}

export default App

/ → Home Page
/about → About Page
/contact → Contact Page
* → Not Found / 404 Page

🔗 Step 3: Create Navigation with `Link` and `NavLink`

Instead of using normal <a> tags, React gives us special components: Link and NavLink.

These navigate between pages without reloading the app.

// Navbar.jsx
import { Link, NavLink } from 'react-router-dom'

function Navbar() {
  return (
    <nav>
      <Link to="/">Home</Link>
      <Link to="/about">About</Link>
      <NavLink
        to="/contact"
        className={({ isActive }) => (isActive ? 'active' : '')}
      >
        Contact
      </NavLink>
    </nav>
  )
}

export default Navbar

✅ Link: Basic navigation (no reload).

✅ NavLink: Same as Link, but automatically adds an “active” class to the current route — perfect for styling active menu items.

🧩 Step 4: Nested Routes and `<Outlet />`

Sometimes you’ll want routes inside routes, like for a dashboard that contains multiple sections (e.g., profile, settings).

That’s where nested routes come in — and the <Outlet /> component helps render them in the right place.

// App.jsx
<Routes>
  <Route path="/" element={<Home />} />
  <Route path="/dashboard" element={<Dashboard />}>
    <Route path="profile" element={<Profile />} />
    <Route path="settings" element={<Settings />} />
  </Route>
</Routes>

Inside Dashboard.jsx:

// Dashboard.jsx
import { Outlet } from 'react-router-dom'

function Dashboard() {
  return (
    <div>
      <h2>Dashboard</h2>
      {/* Child routes will render here */}
      <Outlet />
    </div>
  )
}

export default Dashboard

Now, when visiting /dashboard/profile, React automatically renders the Profile component inside the Dashboard layout!

🚀 Mini React Demo Project: "My First Routed App"

Let’s put it all together into a working mini project.

File Structure:

src/
  ├── main.jsx
  ├── App.jsx
  ├── components/
  │     └── Navbar.jsx
  ├── pages/
  │     ├── Home.jsx
  │     ├── About.jsx
  │     ├── Contact.jsx
  │     └── NotFound.jsx

Example Pages:

// pages/Home.jsx
function Home() {
  return <h1>Welcome to My React App!</h1>
}
export default Home

// pages/About.jsx
function About() {
  return <h1>About This Project</h1>
}
export default About

// pages/Contact.jsx
function Contact() {
  return <h1>Contact Me Anytime!</h1>
}
export default Contact

// pages/NotFound.jsx
function NotFound() {
  return <h1>404 — Page Not Found</h1>
}
export default NotFound

Add the Navbar:

// App.jsx
import Navbar from './components/Navbar'

function App() {
  return (
    <>
      <Navbar />
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
        <Route path="/contact" element={<Contact />} />
        <Route path="*" element={<NotFound />} />
      </Routes>
    </>
  )
}

Now you’ve got a complete, simple React app with modern routing — no page reloads, smooth navigation, and clean URLs.

⚙️ Bonus: Things to Explore Next

React Router Docs — Learn about advanced features like useNavigate, loaders, lazy loading, and route transitions.
Try adding a 404 redirect or a Protected Route for authenticated sections.
Use NavLink styling to highlight the active page.

🏁 Wrapping Up

You just learned how to set up React Router from scratch — including how to install it, define routes, use navigation components, and manage nested routes cleanly.

Now, whenever you start a new React project, you’ll know exactly how to make it multi-page while keeping it fast and smooth.

Keep building! 💪