Building a sub-100ms 50-state tax engine in Next.js (without burning serverless compute)

Rahul Rana — Wed, 07 Oct 2026 20:41:05 +0000

Most web calculators are slow for bad reasons.

If you inspect the network tab on popular calculator sites, you will routinely see 40+ JavaScript chunks, multiple ad exchange bidding scripts, and heavy client-side bundles. A page that should take 50 lines of arithmetic ends up taking 3 seconds to become interactive.

Over the past few weeks, I built PureCalc
, a suite of paycheck and construction calculators. My goal was simple: sub-100ms Time to First Byte (TTFB), zero third-party scripts, and static pre-rendering across thousands of routes.

Here is how I structured the tax engine, handled state statutory edge cases, and kept serverless compute costs near zero.

The Route Generation Problem

I wanted dedicated, indexable landing pages for specific queries (e.g., /paycheck-calculator/california/75000-a-year or /concrete-calculator/10x10-slab-4-inch).

Doing this naively with dynamic server-side rendering (SSR) on every request burns serverless execution time and adds cold-start latency.

Instead, I used Next.js static export via generateStaticParams. We precompute 2,300+ common salary tiers and slab dimensions at build time:

typescript
// app/paycheck-calculator/[state]/[salary]/page.tsx
export async function generateStaticParams() {
const states = getAllStates(); // 50 states + DC
const salaryTiers = [
25000, 30000, 40000, 50000, 60000, 75000,
85000, 100000, 125000, 150000, 200000, 250000
];
return states.flatMap((state) =>
salaryTiers.map((salary) => ({
state: state.slug,
salary: ${salary}-a-year,
}))
);
}

By pushing these pages to Vercel's edge cache (s-maxage=31536000), the edge network serves pure static HTML in 65ms. Origin compute only wakes up when a user types an unusual custom number that wasn't in the static build.

Modeling 50 State Tax Engines Cleanly

US income taxes look simple on paper, but state-level exceptions quickly create messy code if you don't structure the data cleanly.

Instead of writing custom conditional logic per state, I separated the engine into three steps:

Federal Taxable Income (Standard deductions, FICA caps).
State Marginal Brackets (or flat tax rates).
Mandatory State Statutory Deductions (SDI, Paid Family Leave, Unemployment).

Here is the TypeScript interface that keeps the engine organized:

typescript
export interface StateTaxConfig {
stateCode: string;
name: string;
type: 'none' | 'flat' | 'progressive';
flatRate?: number;
brackets?: TaxBracket[];
standardDeduction: {
single: number;
married: number;
};
statutoryDeductions?: StatutoryDeduction[];
}
export interface StatutoryDeduction {
name: string;
rate: number;
wageCap?: number; // e.g. Social Security wage limit
uncapped: boolean; // e.g. CA SDI is now uncapped
}

The Trap: Hidden Statutory Deductions

If you only calculate state income tax, your take-home pay numbers will be wrong for several major states.

A few real-world examples:

California SDI: In 2024, California removed the wage cap on State Disability Insurance. It is a flat 1.30% deduction on all gross wages with zero ceiling. If you earn $300k, you pay $3,900 in SDI.
Washington Cares Fund: Washington has no state income tax, but it mandates a 0.58% long-term care payroll tax on gross wages, plus Paid Family and Medical Leave (PFML).
Pennsylvania UC: In addition to its 3.07% flat income tax, Pennsylvania withholds 0.07% for state employee unemployment compensation.

To handle these, the engine loops through statutory rules independently of the income tax bracket calculation:

typescript
export function calculateStatutoryWithholding(
grossIncome: number,
deductions: StatutoryDeduction[]
): Record {
const result: Record = {};
for (const item of deductions) {
const taxableBase = item.uncapped
? grossIncome
: Math.min(grossIncome, item.wageCap ?? grossIncome);
result[item.name] = Math.round(taxableBase * item.rate * 100) / 100;
}
return result;
}

Why Whole-Bag Ceiling Math Matters

On the construction calculator side, floating-point math causes practical problems if you don't account for real-world hardware store constraints.

When calculating concrete bags for a slab: Volume = (Length * Width * Depth_in_feet) / 27

If you calculate a 10x10 ft slab at 4 inches thick:

Base volume = 1.23 cubic yards.
Add 10% for ground unevenness = 1.36 cubic yards (36.67 cubic feet).
An 80 lb bag yields 0.60 cubic feet.
36.67 / 0.60 = 61.11 bags.

If your code runs standard Math.round(), it returns 61 bags. But if a homeowner buys 61 bags, they run out of concrete before filling the forms.

We always apply Math.ceil() to the bag calculation after applying waste:

typescript
export function calculateBagCounts(cubicYardsWithWaste: number) {
const cubicFeet = cubicYardsWithWaste * 27;
return {
bags80lb: Math.ceil(cubicFeet / 0.60),
bags60lb: Math.ceil(cubicFeet / 0.45),
bags40lb: Math.ceil(cubicFeet / 0.30),
};
}

Results & Telemetry

By keeping the frontend lean and eliminating ad network scripts:

Payload size: ~12 KB compressed HTML.
Edge TTFB: 64ms to 85ms across US regions.
Cumulative Layout Shift (CLS): 0.00.
First Contentful Paint (FCP): < 0.4s on mobile 4G.

You can inspect the live tools and test scenarios at purecalchq.com
.

If anyone is working on multi-jurisdiction tax engines or has feedback on local municipal wage taxes (like Philadelphia or Detroit resident surcharges), I would love to connect.

DEV Community: Rahul Rana

Building a sub-100ms 50-state tax engine in Next.js (without burning serverless compute)