DEV Community: G S

I Rebuilt the Electrician's Conduit Bending Calculator Because Trig Shouldn't Require Dodging Popups

G S — Fri, 04 Sep 2026 13:56:36 +0000

The Jobsite Doesn't Wait for Ads to Load

Picture this: you're on a ladder, EMT bender in one hand, phone in the other, gloves half off so the touchscreen registers. You need one number — the distance between two pencil marks for a 30° offset around a duct — and instead you get:

A cookie consent modal blocking the input field
An interstitial ad that hijacks your tap and opens the App Store
A page that reflows three times while ad units above the fold finish loading
A "multiplier chart" buried under 1,500 words of AI-generated filler before you can even see it Electricians don't have the patience for this, and neither do I. Conduit bending is unforgiving geometry — a bad shrink calculation means a stub that's a half-inch short, a saddle that doesn't clear the duct, or conduit in the scrap pile. The math deserves a tool that respects it.

So the Conduit Bending Calculator became the second entry in the HypeCalc suite — same rules as the Stair Calculator before it: no ads, no tracking scripts, no layout shift, and math that's isolated, typed, and testable.

This post breaks down the actual trigonometry behind offset bending and saddle layout, and the Next.js architecture — SEO metadata, JSON-LD schema, and a sticky client-side calculator — that ships it as a fast, indexable page instead of a bloated single-page app.

The Trigonometry: Why Conduit Bending Is Just Triangles With Consequences

Every offset bend an electrician makes is a right triangle. The obstacle height is one leg, the bend angle sets the hypotenuse, and the multiplier constants are just precomputed trig ratios so you're not doing csc(θ) by hand on a ladder.

1. The Offset Multiplier (Distance Between Marks)

To clear an obstacle of a given height at a chosen bend angle, the distance between your two pencil marks is the obstacle height scaled by the cosecant of the bend angle:

distanceBetweenMarks = offsetDepth × csc(angle)

In practice, electricians memorize the multiplier rather than compute cosecant on site:

Bend Angle	Multiplier (csc θ)	Shrink per Inch of Offset
10°	6.00	1/16"
22.5°	2.61	3/16"
30°	2.00	1/4"
45°	1.41	3/8"
60°	1.15	1/2"

2. Shrinkage

Because the conduit now travels diagonally instead of straight, the overall run "shrinks" back toward the obstacle. That shrink is the obstacle height times a fixed constant per angle:

totalShrink = offsetDepth × shrinkConstant(angle)

Forget to add this back into your reference mark, and every downstream measurement on that run is off.

3. The 90° Stub Take-Up

A hand bender's shoe has a radius, which "eats" pipe length during the bend. To land a stub at an exact height, you subtract the bender's fixed take-up value from your target height before marking the pipe:

stubMark = desiredStubHeight - benderTakeUp

Take-up is a lookup by trade size and conduit type (EMT vs. rigid), not something you derive — so it lives as a constant table, not a formula.

4. The 3-Point Saddle

Saddles clear an obstacle with three bends instead of two: a center bend (typically 45°) flanked by two symmetric return bends (typically 22.5°). The center mark accounts for a small correction based on obstacle height, and the two outer marks are offset symmetrically from center:

centerMark = obstacleCenterDistance + (obstacleHeight × 3/16)
outerMarkLow  = centerMark - (obstacleHeight × 2.5)
outerMarkHigh = centerMark + (obstacleHeight × 2.5)

The TypeScript Core: Lookup Tables + Pure Functions

Same architectural rule as the stair calculator: no calculation logic touches a React component directly. Bend constants live in typed tables, and the functions that consume them are pure and independently testable.

// lib/calculateConduitBend.ts

export type BendAngle = 10 | 22.5 | 30 | 45 | 60;
export type ConduitType = "EMT" | "Rigid";
export type TradeSize = "1/2" | "3/4" | "1" | "1-1/4";

// Cosecant multiplier and shrink-per-inch, precomputed per standard bend angle
const OFFSET_CONSTANTS: Record<BendAngle, { multiplier: number; shrinkPerInch: number }> = {
  10: { multiplier: 6.0, shrinkPerInch: 0.0625 },
  22.5: { multiplier: 2.61, shrinkPerInch: 0.1875 },
  30: { multiplier: 2.0, shrinkPerInch: 0.25 },
  45: { multiplier: 1.41, shrinkPerInch: 0.375 },
  60: { multiplier: 1.15, shrinkPerInch: 0.5 },
};

// Bender shoe take-up (inches), by conduit type and trade size
const TAKE_UP_TABLE: Record<ConduitType, Record<TradeSize, number>> = {
  EMT: { "1/2": 5, "3/4": 6, "1": 8, "1-1/4": 11 },
  Rigid: { "1/2": 6, "3/4": 8, "1": 10, "1-1/4": 13 },
};

export interface OffsetInput {
  offsetDepthInches: number;
  angle: BendAngle;
}

export interface OffsetResult {
  distanceBetweenMarksInches: number;
  totalShrinkInches: number;
}

export function calculateOffset({
  offsetDepthInches,
  angle,
}: OffsetInput): OffsetResult {
  if (offsetDepthInches <= 0) {
    throw new Error("Offset depth must be a positive number.");
  }

  const { multiplier, shrinkPerInch } = OFFSET_CONSTANTS[angle];

  return {
    distanceBetweenMarksInches: Number(
      (offsetDepthInches * multiplier).toFixed(3)
    ),
    totalShrinkInches: Number(
      (offsetDepthInches * shrinkPerInch).toFixed(3)
    ),
  };
}

export interface StubInput {
  desiredStubHeightInches: number;
  conduitType: ConduitType;
  tradeSize: TradeSize;
}

export interface StubResult {
  takeUpInches: number;
  stubMarkInches: number;
}

export function calculateStub({
  desiredStubHeightInches,
  conduitType,
  tradeSize,
}: StubInput): StubResult {
  const takeUpInches = TAKE_UP_TABLE[conduitType][tradeSize];
  const stubMarkInches = desiredStubHeightInches - takeUpInches;

  if (stubMarkInches <= 0) {
    throw new Error(
      "Desired stub height must exceed the bender take-up distance."
    );
  }

  return {
    takeUpInches,
    stubMarkInches: Number(stubMarkInches.toFixed(3)),
  };
}

export interface SaddleInput {
  obstacleCenterDistanceInches: number;
  obstacleHeightInches: number;
}

export interface SaddleResult {
  centerMarkInches: number;
  outerMarkLowInches: number;
  outerMarkHighInches: number;
}

export function calculateThreePointSaddle({
  obstacleCenterDistanceInches,
  obstacleHeightInches,
}: SaddleInput): SaddleResult {
  const centerMarkInches =
    obstacleCenterDistanceInches + obstacleHeightInches * 0.1875; // 3/16"
  const spread = obstacleHeightInches * 2.5;

  return {
    centerMarkInches: Number(centerMarkInches.toFixed(3)),
    outerMarkLowInches: Number((centerMarkInches - spread).toFixed(3)),
    outerMarkHighInches: Number((centerMarkInches + spread).toFixed(3)),
  };
}

Splitting this into three focused functions instead of one mega calculateConduit() was deliberate:

Single responsibility, testable in isolation — an offset bend, a stub, and a saddle are three different real-world tasks. Bundling them into one function with a mode flag would make every test case need to stub out irrelevant parameters.
Typed lookup tables catch mistakes at compile time. TradeSize and ConduitType are string literal unions, so TAKE_UP_TABLE["Rigid"]["2"] fails to compile instead of silently returning undefined at 2am on a jobsite.
No magic numbers in the UI layer. The component never hardcodes 0.1875 or 2.5 — those constants live exactly once, next to the formula that uses them.

The Page Architecture: SEO-First, Interactivity Second

This is where the conduit calculator diverges from a typical "throw a form on a page" build. Because it targets long-tail, high-intent search traffic ("conduit 3 point and 4 point saddle bend calculator," "90 degree stub up and kick bend take up calculator"), the page is structured as a content-first Server Component wrapping a client-only calculator, not a client-rendered SPA with SEO bolted on.

// page.tsx (excerpt)
export const metadata: Metadata = {
  title: 'Conduit Bending Calculator - EMT Offsets, Saddles, Shrink',
  description: 'Free conduit bending calculator. Calculate EMT offset multiplier marks, shrink per inch, 3-point & 4-point saddles, 90° stub take-up, and concentric bends.',
  keywords: [ /* long-tail, field-language queries */ ],
};

export default function ConduitBendingPage() {
  return (
    <main>
      {/* JSON-LD: Breadcrumb, SoftwareApplication, FAQPage */}
      <script type="application/ld+json" dangerouslySetInnerHTML={{ __html: JSON.stringify(faqSchema) }} />

      <div className="grid grid-cols-1 lg:grid-cols-12 gap-10">
        {/* LEFT: static, server-rendered reference content */}
        <div className="lg:col-span-5">{/* formulas, tables, FAQ */}</div>

        {/* RIGHT: sticky client component, the actual tool */}
        <div className="lg:col-span-4">
          <StickyWrapper>
            <CalculatorCard title="Electrical Conduit Bending Calculator">
              <CalculatorForm />
            </CalculatorCard>
          </StickyWrapper>
        </div>
      </div>
    </main>
  );
}

A few things worth calling out:

page.tsx stays a Server Component. All the metadata, JSON-LD, and reference tables render on the server with zero client JS cost. Only CalculatorForm opts into "use client" — the interactive slice is as small as possible, which keeps the shipped bundle lean.
The FAQ schema is a 1:1 match with visible on-page content. Search engines increasingly discount JSON-LD that doesn't correspond to something a user can actually read on the page — so instead of writing schema as an afterthought, the FAQ section and the faqSchema object are generated from the same source of truth.
The calculator is sticky, not modal. On desktop, StickyWrapper keeps the tool pinned in the viewport while the reference content scrolls — so a user reading "how do I calculate a 3-point saddle" never loses the calculator they came for.
No SoftwareApplication fake review inflation. The schema explicitly omits aggregateRating rather than fabricating a 4.9-star rating with zero reviews — a shortcut a lot of "SEO-optimized" calculator sites lean on, and one that search engines have gotten much better at penalizing.

What This Buys You Over the Legacy Field-Calculator Sites

Metric	Typical Ad-Supported Trade Calculators	HypeCalc
Interstitial / consent modals blocking input	1–2, often mid-interaction	0
Layout shift from late-loading ad units	High (CLS 0.2–0.4+)	0
JS shipped for a two-field calculator	Hundreds of KB to MBs	Client bundle scoped to `CalculatorForm` only
FAQ content matching structured data	Often mismatched or padded	1:1, same source of truth
Usable one-handed on a ladder	Rarely	Yes

The recurring theme across both calculators in this suite: every architectural decision either serves the user's actual task, or it doesn't ship. No dark patterns disguised as monetization, no schema written to game rankings instead of describe the page.

Try It on an Actual Bend

The offset, stub, and saddle logic above is live, not a demo:

HypeCalc Conduit Bending Calculator →

Run it through a real offset — 4" obstacle, 30° bend — and check that you land on 8" between marks and 1" of shrink, same as the worked example in the field guide above.

Discussion

A few things I'd genuinely like this community's take on:

Where's the right line between "SEO-optimized content page" and "bloated content page"? This build keeps ~1,500 words of reference content server-rendered next to the tool — is that good practice for utility sites, or creeping toward the same pattern I'm criticizing?
Lookup-table constants vs. computing trig live in the browser — for domain constants like bender take-up that are standardized by manufacturer, not derived, is a typed table always the right call over a formula?
What's a trade or domain you know well where the "official" web calculator gets the math subtly wrong? I'm collecting jobsite-verified formulas for the next tool in this suite — drop them below.

Building a Distraction-Free, Formula-Transparent Concrete Calculator with Next.js & Tailwind

G S — Wed, 02 Sep 2026 09:25:18 +0000

"How Many Yards of Concrete for a 10x10 Slab?"

That was the search query. It should have taken ten seconds to answer.

Instead I landed on a calculator site that:

Rendered a fake 4.8-star rating widget at the top, sourced from nothing, reviewing nothing
Buried the actual input fields below 1,800 words of AI-generated filler about "the history of concrete"
Used cubic feet and cubic yards interchangeably in the same paragraph, with no unit labels on the output
Rounded a bag count from 47.2 bags down to 45, silently, with no waste factor applied — which is exactly how people under-order and end up with a half-poured slab at 4pm on a Saturday with the concrete truck gone
Loaded six ad networks before the single <input type="number"> finished hydrating Concrete math is unforgiving in a specific way most calculators ignore: you can't go back for more mid-pour. Cold joints form, strength drops at the seam, and the fix is demolition. A calculator that quietly rounds down or mixes up cubic feet and cubic yards isn't a minor UX flaw — it's the kind of bug that costs someone a truck-load surcharge or a cracked slab.

So I built the version I actually wanted: correct unit math, an explicit waste factor, real bag-yield tables, and support for the three shapes that cover 90% of DIY pours — slabs, cylindrical post holes, and stepped stairs. No fake ratings. No filler. Here's the engineering behind it.

Live: Concrete Yardage Calculator →

The Math: Three Shapes, One Unit System, Zero Ambiguity

The core insight that most broken calculators get wrong: every formula needs to resolve to cubic feet first, then convert to cubic yards last. Mixing inches, feet, and yards mid-calculation is where silent errors creep in. So the architecture forces a single conversion boundary.

1. Rectangular Slabs, Driveways, Sidewalks

depthFeet = depthInches / 12
cubicFeet = lengthFeet × widthFeet × depthFeet
cubicYards = cubicFeet / 27

Worked example — 10×10 slab, 4" thick:
10 × 10 × (4/12) = 33.33 cu ft → 33.33 / 27 = 1.23 cu yds

2. Cylindrical Post Holes & Sonotubes

This is where most calculators fail entirely — they treat post holes as if they were rectangular, which overstates volume by roughly 27% (the difference between a circle and its bounding square).

radiusFeet = (diameterInches / 12) / 2
cubicFeet = π × radiusFeet² × depthFeet
cubicYards = cubicFeet / 27

Worked example — 12" diameter hole, 3' deep:
π × 0.5² × 3 = 2.356 cu ft → 2.356 / 27 = 0.087 cu yds

3. Solid Concrete Steps (Stacked Volume)

Steps aren't a single rectangular volume — each step sits on top of the one below it, so the total volume is a triangular stack, not width × tread × riser × stepCount. The correct formula uses the sum of the first n integers to account for the compounding:

stackedRisers = steps × (steps + 1) / 2
cubicFeet = widthFeet × treadFeet × riserFeet × stackedRisers
cubicYards = cubicFeet / 27

Using flat multiplication here overstates concrete needs by nearly 2x on a 5-step run, because it assumes every step is a full standalone block instead of an incremental layer.

4. The Non-Negotiable: Waste Factor

Every result gets a 10% overage applied by default, adjustable by the user — because subgrade isn't perfectly flat, forms flex under hydraulic pressure, and spillage during discharge is real. A calculator that reports the theoretical minimum instead of the practical order quantity is answering the wrong question.

recommendedYards = cubicYards × (1 + wasteFactorPercent / 100)

The TypeScript Core

Same architectural rule as always: calculation logic never touches JSX. One pure module, three shape handlers, one shared unit boundary.

// lib/calculateConcrete.ts

export type ConcreteShape = "slab" | "cylinder" | "steps";

interface SlabInput {
  shape: "slab";
  lengthFeet: number;
  widthFeet: number;
  depthInches: number;
}

interface CylinderInput {
  shape: "cylinder";
  diameterInches: number;
  depthFeet: number;
  holeCount: number;
}

interface StepsInput {
  shape: "steps";
  widthFeet: number;
  treadInches: number;
  riserInches: number;
  stepCount: number;
}

export type ConcreteInput = SlabInput | CylinderInput | StepsInput;

export interface ConcreteResult {
  cubicFeet: number;
  cubicYards: number;
  recommendedYards: number; // with waste factor applied
  bags80lb: number;
  bags60lb: number;
  bags40lb: number;
}

const CUFT_PER_CUYD = 27;
const BAG_YIELD_CUFT = { "80": 0.6, "60": 0.45, "40": 0.3 } as const;

function rawCubicFeet(input: ConcreteInput): number {
  switch (input.shape) {
    case "slab": {
      const depthFeet = input.depthInches / 12;
      return input.lengthFeet * input.widthFeet * depthFeet;
    }
    case "cylinder": {
      const radiusFeet = input.diameterInches / 12 / 2;
      const perHole = Math.PI * radiusFeet ** 2 * input.depthFeet;
      return perHole * input.holeCount;
    }
    case "steps": {
      const treadFeet = input.treadInches / 12;
      const riserFeet = input.riserInches / 12;
      const stackedRisers = (input.stepCount * (input.stepCount + 1)) / 2;
      return input.widthFeet * treadFeet * riserFeet * stackedRisers;
    }
  }
}

export function calculateConcrete(
  input: ConcreteInput,
  wasteFactorPercent: number = 10
): ConcreteResult {
  const cubicFeet = rawCubicFeet(input);
  const cubicYards = cubicFeet / CUFT_PER_CUYD;
  const recommendedYards = cubicYards * (1 + wasteFactorPercent / 100);
  const recommendedCubicFeet = recommendedYards * CUFT_PER_CUYD;

  return {
    cubicFeet: Number(cubicFeet.toFixed(3)),
    cubicYards: Number(cubicYards.toFixed(3)),
    recommendedYards: Number(recommendedYards.toFixed(3)),
    bags80lb: Math.ceil(recommendedCubicFeet / BAG_YIELD_CUFT["80"]),
    bags60lb: Math.ceil(recommendedCubicFeet / BAG_YIELD_CUFT["60"]),
    bags40lb: Math.ceil(recommendedCubicFeet / BAG_YIELD_CUFT["40"]),
  };
}

Two decisions worth flagging:

Discriminated union over a flat props bag. ConcreteInput forces TypeScript to narrow correctly inside rawCubicFeet — you physically cannot access diameterInches while handling the "slab" case. The compiler enforces the geometry, not a runtime if chain.

- Bag counts always round up (`Math.ceil`), never down. This is the fix for the silent-rounding bug that started this whole project. You cannot buy 44.7 bags of concrete. Rounding down is how people run short mid-pour.

The Client Component

// components/CalculatorForm.tsx
"use client";

import { useMemo, useState } from "react";
import { calculateConcrete, type ConcreteShape } from "@/lib/calculateConcrete";

export default function CalculatorForm() {
  const [shape, setShape] = useState<ConcreteShape>("slab");
  const [length, setLength] = useState(10);
  const [width, setWidth] = useState(10);
  const [depthInches, setDepthInches] = useState(4);
  const [wasteFactor, setWasteFactor] = useState(10);

  const result = useMemo(() => {
    if (shape !== "slab") return null; // cylinder/steps forms omitted for brevity
    if (length <= 0 || width <= 0 || depthInches <= 0) return null;

    return calculateConcrete(
      { shape: "slab", lengthFeet: length, widthFeet: width, depthInches },
      wasteFactor
    );
  }, [shape, length, width, depthInches, wasteFactor]);

  return (
    <div className="rounded-2xl border border-zinc-200 bg-white p-6 shadow-sm">
      <div className="grid grid-cols-2 gap-4">
        <NumberField label="Length (ft)" value={length} onChange={setLength} />
        <NumberField label="Width (ft)" value={width} onChange={setWidth} />
        <NumberField
          label="Depth (in)"
          value={depthInches}
          onChange={setDepthInches}
        />
        <NumberField
          label="Waste factor (%)"
          value={wasteFactor}
          onChange={setWasteFactor}
        />
      </div>

      {result && (
        <div className="mt-6 space-y-2 rounded-xl bg-indigo-50 p-4 text-sm">
          <Row label="Cubic yards (exact)" value={`${result.cubicYards} yd³`} />
          <Row
            label="Recommended order"
            value={`${result.recommendedYards} yd³`}
            emphasis
          />
          <Row label="80 lb bags needed" value={`${result.bags80lb}`} />
          <Row label="60 lb bags needed" value={`${result.bags60lb}`} />
        </div>
      )}
    </div>
  );
}

function NumberField({
  label,
  value,
  onChange,
}: {
  label: string;
  value: number;
  onChange: (v: number) => void;
}) {
  return (
    <label className="flex flex-col gap-1 text-sm text-zinc-600">
      {label}
      <input
        type="number"
        value={value}
        onChange={(e) => onChange(Number(e.target.value))}
        className="rounded-lg border border-zinc-300 px-3 py-2 outline-none focus:border-indigo-500"
      />
    </label>
  );
}

function Row({
  label,
  value,
  emphasis,
}: {
  label: string;
  value: string;
  emphasis?: boolean;
}) {
  return (
    <div className="flex justify-between">
      <span className="text-zinc-600">{label}</span>
      <span className={emphasis ? "font-bold text-indigo-700" : "font-mono text-zinc-800"}>
        {value}
      </span>
    </div>
  );
}

useMemo again does all the heavy lifting — no debounce, no server round-trip, no loading spinner for a computation that resolves in microseconds. The moment depthInches changes, bags80lb recomputes, and the browser never breaks a sweat.

The SEO Layer Is Structural, Not an Afterthought

The production page.tsx for this calculator does something a lot of "build a calculator" tutorials skip entirely: it ships three JSON-LD schemas — BreadcrumbList, SoftwareApplication, and FAQPage — server-rendered alongside the content, not injected client-side after the fact.

const faqSchema = {
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How many bags of concrete equal a yard?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "It takes 45 bags of 80 lb mix, 60 bags of 60 lb mix, or 90 bags of 40 lb mix to equal one full cubic yard."
      }
    }
    // ...
  ]
};

Two things matter here architecturally:

The FAQ schema is a 1:1 mirror of the on-page FAQ copy — not a separate SEO-only payload. Google penalizes structured data that doesn't match visible content, and duplicating the answer by hand invites drift between the two. Keeping them as a single source rendered twice (schema + JSX) is a discipline worth enforcing, not a nice-to-have.
No fake AggregateRating. It's tempting to bolt on a fabricated 4.8-star schema because it visually dominates the SERP snippet — but it's exactly the kind of manufactured trust signal that made the original broken calculator untrustworthy in the first place. Left it out entirely. The layout itself splits into a 5-column SEO content pane and a 4-column sticky calculator pane, so the interactive tool stays in the viewport while someone scrolls through the formula breakdown — instead of the classic pattern of forcing users to scroll past an essay to reach the input fields.

Why This Loads Instantly Compared to the Competition

Metric	Typical Concrete Calculator Sites	HypeCalc
Fake review/rating widgets	Common	None — removed on principle
Unit conversion errors	Frequent (ft/in/yd mixed)	Single conversion boundary, enforced by types
Bag count rounding	Rounds down silently	Always rounds up (`Math.ceil`)
JSON-LD structured data	Often missing or fabricated	Real, content-matched FAQ schema
Recalculation latency	Server round-trip or jQuery reflow	Sub-millisecond client-side `useMemo`
Ads before first input	3–6	0

Try It, Then Tell Me What's Wrong With It

The calculator above — slab, cylinder, and stacked-step volume math, all included — is live:

Concrete Yardage Calculator →

Feed it a real driveway pour and check the bag math against what your local supplier quotes.

A few things I want the comments to fight about:

Discriminated unions vs. a single flat interface with optional fields — for a calculator with three shapes, was the union overkill, or is "the compiler prevents invalid states" worth the extra boilerplate at this scale?
Should structured data (JSON-LD) be treated as a testable contract — i.e. should CI fail if the FAQ schema and the visible FAQ copy drift out of sync? I don't currently enforce this and probably should.
What's the worst unit-conversion bug you've personally shipped — feet vs. meters, cents vs. dollars, anything where a missing / 12 or / 100 caused real damage downstream?

How I Built a Clean Sleep Calculator Using Next.js, TypeScript, and Sleep Cycle Math

G S — Thu, 27 Aug 2026 05:37:56 +0000

2:47 AM, Googling "sleep calculator"

If you've ever had to be somewhere at 6 AM and couldn't do the mental math on which bedtime actually lines up with a full sleep cycle, you've hit the same wall I did: every sleep calculator on page one of Google feels like a heavy content farm wearing a calculator as a disguise.

Scroll past a wall of repetitive "SEO-optimized" text, dodge newsletter modals, and finally find the input field. Type in a wake time, only to wait for a full page reload because the "calculator" is running a legacy form POST on a server.

All I wanted was simple: if I fall asleep at 11:45 PM, when should my alarm go off so I wake up during light sleep instead of groggily fighting through deep sleep?

That's a basic 90-minute math problem. It does not need a server round-trip, heavy tracking bundles, or bloated layout shifts.

So the Sleep Cycle Calculator was built for HypeCalc with a clear focus: pure math, typed React state, zero layout shifts, and an engineering-led SEO layer built directly into Next.js. Here is how it works under the hood.

The Sleep Science, Reduced to a Formula

Sleep isn't a single uniform state — your brain cycles through stages roughly every 90 minutes: light sleep (N1, N2), deep slow-wave sleep (N3), and REM. Waking up mid-cycle (especially during N3) triggers sleep inertia — that heavy, groggy feeling. Waking up at a cycle boundary during light sleep leaves you far more alert.

The calculator calculates backward from a target wake time:

Bedtime Target = Desired Wake Time − (90 minutes × Number of Cycles) − Sleep Latency

Where:

90 minutes is the average full sleep cycle length.
Number of Cycles is typically 4, 5, or 6 (5–6 cycles represent the restorative sweet spot for most adults).
Sleep Latency is the average time to fall asleep once in bed (10–20 minutes; ignoring this is the most common error in manual sleep math).

Run it the other direction (given a bedtime, when should you wake up?):

Wake Time Target = Bedtime + Sleep Latency + (90 minutes × Number of Cycles)

The TypeScript Core: Time Math Without Date Libraries

Time arithmetic easily invites bugs (midnight rollovers, 12-hour AM/PM formatting). I isolated the logic into a pure, dependency-free utility:

// lib/calculateSleepCycles.ts

const CYCLE_LENGTH_MINUTES = 90;
const DEFAULT_LATENCY_MINUTES = 15;
const CYCLE_OPTIONS = [3, 4, 5, 6] as const;

export interface SleepCycleOption {
  cycles: number;
  totalSleepMinutes: number;
  targetTime: string;
  isRecommended: boolean;
}

export interface SleepCalculationInput {
  anchorTime: string; // "HH:MM" 24hr format
  mode: "wakeUp" | "bedtime";
  latencyMinutes?: number;
}

export function calculateSleepCycles({
  anchorTime,
  mode,
  latencyMinutes = DEFAULT_LATENCY_MINUTES,
}: SleepCalculationInput): SleepCycleOption[] {
  const anchorDate = parseTimeToDate(anchorTime);

  return CYCLE_OPTIONS.map((cycles) => {
    const cycleMinutes = cycles * CYCLE_LENGTH_MINUTES;
    const offsetMinutes =
      mode === "wakeUp"
        ? -(cycleMinutes + latencyMinutes)
        : cycleMinutes + latencyMinutes;

    const targetDate = addMinutes(anchorDate, offsetMinutes);

    return {
      cycles,
      totalSleepMinutes: cycleMinutes,
      targetTime: formatTime(targetDate),
      isRecommended: cycles === 5 || cycles === 6,
    };
  }).reverse();
}

function parseTimeToDate(time: string): Date {
  const [hours, minutes] = time.split(":").map(Number);
  const date = new Date();
  date.setHours(hours, minutes, 0, 0);
  return date;
}

function addMinutes(date: Date, minutes: number): Date {
  return new Date(date.getTime() + minutes * 60_000);
}

function formatTime(date: Date): string {
  return date.toLocaleTimeString("en-US", {
    hour: "numeric",
    minute: "2-digit",
    hour12: true,
  });
}

Key architectural decisions:

Zero date library bloat: Native Date and toLocaleTimeString handle 12-hour formatting in a few lines without adding package weight.
Separation of concerns: Business rules (isRecommended) remain in the calculation layer rather than being scattered across JSX conditionals.

The Client Component: Fast, Reactive State

Instead of separate components, a single state machine handles both wake-up and bedtime directions seamlessly:

// CalculatorForm.tsx
"use client";

import { useMemo, useState } from "react";
import {
  calculateSleepCycles,
  type SleepCycleOption,
} from "@/lib/calculateSleepCycles";

export default function CalculatorForm() {
  const [mode, setMode] = useState<"wakeUp" | "bedtime">("wakeUp");
  const [anchorTime, setAnchorTime] = useState("06:00");

  const options: SleepCycleOption[] = useMemo(
    () => calculateSleepCycles({ anchorTime, mode }),
    [anchorTime, mode]
  );

  return (
    <div className="flex flex-col gap-5">
      <div className="flex rounded-xl bg-zinc-100 p-1 text-sm font-semibold">
        <button
          type="button"
          onClick={() => setMode("wakeUp")}
          className={`flex-1 rounded-lg px-3 py-2 transition-colors ${
            mode === "wakeUp" ? "bg-white shadow-sm text-indigo-600" : "text-zinc-500"
          }`}
        >
          I need to wake up at...
        </button>
        <button
          type="button"
          onClick={() => setMode("bedtime")}
          className={`flex-1 rounded-lg px-3 py-2 transition-colors ${
            mode === "bedtime" ? "bg-white shadow-sm text-indigo-600" : "text-zinc-500"
          }`}
        >
          I'm going to bed at...
        </button>
      </div>

      <label className="flex flex-col gap-1 text-sm text-zinc-500">
        {mode === "wakeUp" ? "Wake-up time" : "Bedtime"}
        <input
          type="time"
          value={anchorTime}
          onChange={(e) => setAnchorTime(e.target.value)}
          className="rounded-lg border border-zinc-200 px-3 py-2 text-lg font-medium text-zinc-900 outline-none focus:border-indigo-500"
        />
      </label>

      <ul className="flex flex-col gap-2">
        {options.map((opt) => (
          <li
            key={opt.cycles}
            className={`flex items-center justify-between rounded-lg border px-4 py-3 ${
              opt.isRecommended
                ? "border-indigo-200 bg-indigo-50"
                : "border-zinc-100 bg-white"
            }`}
          >
            <span className="font-mono text-lg font-bold text-zinc-900">
              {opt.targetTime}
            </span>
            <span className="text-sm text-zinc-500">
              {opt.cycles} cycles · {(opt.totalSleepMinutes / 60).toFixed(1)}h
              {opt.isRecommended && (
                <span className="ml-2 rounded-full bg-indigo-600 px-2 py-0.5 text-xs font-semibold text-white">
                  Best
                </span>
              )}
            </span>
          </li>
        ))}
      </ul>
    </div>
  );
}

Server-Rendered JSON-LD & Mobile-First UX

To ensure crawlers read structural data instantly without executing heavy client bundles, JSON-LD schema is injected server-side:

const faqSchema = {
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How long is one sleep cycle?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "A standard human sleep cycle lasts roughly 90 minutes, alternating between non-REM and REM sleep."
      }
    }
  ]
};

<script
  type="application/ld+json"
  dangerouslySetInnerHTML={{ __html: JSON.stringify(faqSchema) }}
/>

Mobile-First Grid Hierarchy

On desktop, the layout renders a responsive two-column grid. On mobile, order-1 forces the interactive calculator to load above the informational content, eliminating unnecessary scrolling for late-night mobile users.

Performance Benchmark

Metric	Legacy Web Calculators	HypeCalc Architecture
Cumulative Layout Shift (CLS)	High (0.2+)	0.00
Execution Model	Server POST reload	Client-side memoized state
Time to Calculation	2–4s per update	Sub-millisecond
Schema Delivery	Client tag-manager scripts	Direct SSR JSON-LD

Check Out the Tool

The live calculator is available here: HypeCalc Sleep Cycle Calculator →

Discussion Points

Native Date vs. Libraries: For simple time offsets and local formatting, is raw JavaScript cleaner than bundling date-fns/dayjs?
Schema Integrity: How do you approach server-side structured data without overloading initial payloads?

I Rebuilt the One-Rep Max Calculator Every Gym Bro Uses — Here's the TypeScript Math Behind the Core Strength Formulas

G S — Mon, 24 Aug 2026 17:13:25 +0000

The Tab You Close Before Anyone Sees It

You just finished a heavy set. Phone's already in your hand, chalk still on your fingers, and you search "1 rep max calculator" to see where you actually stand.

What loads:

A "Your 1RM Is Loading..." spinner sitting on top of an ad that hasn't rendered yet, so the page jumps the second it does
A pop-under that opens a second tab you now have to close mid-set
Three different "Which Pre-Workout Fits YOUR Body Type?" quizzes wedged between you and the calculator
A results box that recalculates on a 500ms debounce, so typing "225" shows you the max for "2," then "22," then finally "225" — a full half-second later
Somewhere below the fold, in 8px gray text, the actual Epley formula, buried under four paragraphs of AI-generated filler about "the science of gains" You wanted three numbers: your estimated max, your training percentages, maybe a sanity check against the Brzycki formula. Instead you got an ad experience with a calculator bolted onto the side of it as an afterthought.

So — same as the Stair Calculator before it — I built the version I actually wanted to use: HypeCalc's 1-Rep Max Calculator. No debounce lag, no pop-unders, no spinner theater. You type a weight and a rep count, and three validated formulas resolve before you finish the keystroke.

This post is the engineering breakdown: the actual exercise-science math behind Epley, Brzycki, and Lander, the typed calculation core, and the memoized client component that makes it instant.

The Math: Why Three Formulas, Not One

A true 1RM test — grinding out a single, maximal-effort rep — is genuinely risky. Bar speed slows unpredictably near failure, form breaks down under fatigue, and the joint/connective-tissue stress is disproportionate to the training benefit. So instead, sports science estimates your 1RM from a sub-maximal set (a heavier-than-usual set you can still complete with good form), using regression equations built from real lifter data.

I implemented three of the most-cited formulas so a user can cross-check estimates rather than trust a single number blindly:

1. Epley Formula

The standard for compound lower-body lifts (squat, deadlift), reliable in the 3–8 rep range:

1RM = Weight × (1 + Reps / 30)

2. Brzycki Formula

Preferred for upper-body pressing movements like bench press, where strength drops off faster as reps climb:

1RM = Weight / (1.0278 − 0.0278 × Reps)

3. Lander Formula

A third validation point that tends to sit between the other two, useful for flagging when Epley or Brzycki is producing an outlier estimate:

1RM = (100 × Weight) / (101.3 − 2.67123 × Reps)

Why This Matters More Than It Looks Like It Does

At low rep counts (3–6), these three formulas typically agree within a few pounds. But push the input to 12+ reps and they diverge hard — because past roughly 10 reps, you're no longer measuring peak force output, you're measuring muscular endurance, and the linear-regression assumptions the formulas rely on stop holding. A calculator that silently reports one formula's output as the answer is quietly lying to you at high rep counts. Showing all three, side by side, turns that failure mode into a visible signal instead of a hidden one.

The TypeScript Core: Three Formulas, One Pure Function

Same architectural rule as always: the math never touches JSX. It's a standalone, synchronous function that takes numbers and returns numbers — trivially unit-testable, and reusable anywhere (a future CLI, a training-log export, a mobile app) without dragging React along with it.

// lib/calculateOneRepMax.ts

export interface OneRepMaxInput {
  weight: number; // lbs or kg — unit-agnostic, output matches input unit
  reps: number;   // completed reps in the working set
}

export interface OneRepMaxResult {
  epley: number;
  brzycki: number;
  lander: number;
  average: number;
  isReliable: boolean; // false when reps push past the accurate estimation range
  percentages: { percent: number; weight: number }[];
}

const RELIABLE_REP_CEILING = 10;

export function calculateOneRepMax({
  weight,
  reps,
}: OneRepMaxInput): OneRepMaxResult {
  if (weight <= 0 || reps <= 0) {
    throw new Error("Weight and reps must be positive numbers.");
  }

  // A true 1-rep set is already the 1RM — no formula needed.
  if (reps === 1) {
    return buildResult(weight, weight, weight, reps);
  }

  const epley = weight * (1 + reps / 30);
  const brzycki = weight / (1.0278 - 0.0278 * reps);
  const lander = (100 * weight) / (101.3 - 2.67123 * reps);

  return buildResult(epley, brzycki, lander, reps);
}

function buildResult(
  epley: number,
  brzycki: number,
  lander: number,
  reps: number
): OneRepMaxResult {
  const average = (epley + brzycki + lander) / 3;

  const percentages = [95, 90, 85, 80, 75, 70, 65, 60].map((percent) => ({
    percent,
    weight: Number(((average * percent) / 100).toFixed(1)),
  }));

  return {
    epley: Number(epley.toFixed(1)),
    brzycki: Number(brzycki.toFixed(1)),
    lander: Number(lander.toFixed(1)),
    average: Number(average.toFixed(1)),
    isReliable: reps <= RELIABLE_REP_CEILING,
    percentages,
  };
}

A couple of deliberate choices worth calling out:

reps === 1 short-circuits the regression entirely. If someone genuinely lifted the weight once, that is the 1RM — running it through Brzycki's denominator would introduce error where none exists.
isReliable is computed data, not a UI decision. The component doesn't decide when to warn the user; the calculation layer decides, and the component just renders whatever it's told. That keeps the "is this trustworthy" logic in one place instead of scattered across render conditionals.
Percentage chart is generated from the average of all three formulas, not just Epley — so a single formula's blind spot doesn't skew every training percentage a lifter programs off of.

The Client Component: No Debounce, No Excuse

The entire reason the legacy calculators debounce input is almost always a symptom of doing too much work per keystroke, or running the calculation on the server. Here, the math above runs in microseconds, so useMemo recalculates synchronously on every render with zero perceptible delay — typing "225" shows the correct answer for "225," not a stale answer for "22."

// components/CalculatorForm.tsx
"use client";

import { useMemo, useState } from "react";
import {
  calculateOneRepMax,
  type OneRepMaxResult,
} from "@/lib/calculateOneRepMax";

export default function CalculatorForm() {
  const [weight, setWeight] = useState(225);
  const [reps, setReps] = useState(5);

  const result: OneRepMaxResult | null = useMemo(() => {
    if (weight <= 0 || reps <= 0) return null;
    return calculateOneRepMax({ weight, reps });
  }, [weight, reps]);

  return (
    <div className="w-full rounded-2xl border border-zinc-200 bg-white p-6 shadow-sm">
      <div className="grid grid-cols-2 gap-4">
        <label className="flex flex-col gap-1 text-sm font-medium text-zinc-600">
          Weight Lifted
          <input
            type="number"
            value={weight}
            onChange={(e) => setWeight(Number(e.target.value))}
            className="rounded-lg border border-zinc-300 px-3 py-2 text-zinc-900 outline-none focus:border-indigo-500"
          />
        </label>

        <label className="flex flex-col gap-1 text-sm font-medium text-zinc-600">
          Reps Completed
          <input
            type="number"
            value={reps}
            onChange={(e) => setReps(Number(e.target.value))}
            className="rounded-lg border border-zinc-300 px-3 py-2 text-zinc-900 outline-none focus:border-indigo-500"
          />
        </label>
      </div>

      {result && (
        <div className="mt-6 space-y-4">
          <div className="grid grid-cols-3 gap-2 text-center">
            <FormulaCard label="Epley" value={result.epley} />
            <FormulaCard label="Brzycki" value={result.brzycki} />
            <FormulaCard label="Lander" value={result.lander} />
          </div>

          <div className="rounded-xl bg-indigo-50 p-4 text-center">
            <p className="text-xs font-semibold uppercase tracking-wide text-indigo-500">
              Estimated 1-Rep Max
            </p>
            <p className="text-3xl font-black text-indigo-700">
              {result.average}
            </p>
          </div>

          {!result.isReliable && (
            <p className="rounded-lg bg-amber-50 px-3 py-2 text-sm font-medium text-amber-700">
              ⚠ Estimates beyond 10 reps lose accuracy — treat this as a
              rough ceiling, not a precise number.
            </p>
          )}

          <div className="space-y-1">
            {result.percentages.map((row) => (
              <div
                key={row.percent}
                className="flex justify-between text-sm text-zinc-600"
              >
                <span>{row.percent}%</span>
                <span className="font-mono text-zinc-900">{row.weight}</span>
              </div>
            ))}
          </div>
        </div>
      )}
    </div>
  );
}

function FormulaCard({ label, value }: { label: string; value: number }) {
  return (
    <div className="rounded-lg border border-zinc-200 p-3">
      <p className="text-xs text-zinc-500">{label}</p>
      <p className="font-mono text-lg font-semibold text-zinc-900">
        {value}
      </p>
    </div>
  );
}

Nothing here is exotic — that's the point. Two controlled inputs, one memoized derived value, no debounce, no loading state, no client-side fetch. The absence of machinery is the performance win.

Structured Content Isn't the Enemy — Ad Networks Are

It's worth being precise about something here, because it's easy to conflate two very different things: content bloat and content that actually helps search and users.

The production page behind this calculator ships FAQ schema, breadcrumb schema, and a genuinely useful explainer section (how to pick a working set, why full range of motion matters, what counts as a "good" 1RM for your bodyweight). That's not bloat — a lifter searching "how to calculate 1 rep max without testing" is looking for exactly that context, and structured JSON-LD lets Google surface it as a rich result instead of a blue link.

Bloat is specifically the stuff that serves someone other than the reader: autoplay video ads, pop-unders, tracking pixels, artificial debounce delays that exist only because the page is too heavy to recalculate instantly. You can ship a content-rich, SEO-solid page and have a zero-ad, zero-CLS, instant-feedback calculator sitting inside it — those aren't in tension. The legacy tools didn't get slow because they had good content; they got slow because the business model was ads, and the calculator was never the priority.

Try It Against Your Own Numbers

The formulas above, the percentage chart, the reliability warning at high rep counts — it's all live right now:

HypeCalc 1-Rep Max Calculator →

Type your last heavy set in and watch all three formulas resolve before you finish typing the rep count. No pop-under. No debounce. No pre-workout quiz standing between you and your numbers.

Discussion

A few things I'd genuinely like this community's take on:

Where's the line between "structured, SEO-rich content" and "bloat"? I'd argue schema markup and a real FAQ section are the opposite of bloat — do you agree, or does anything beyond the calculator itself count against a tool in your eyes?
Showing three formulas instead of one is more UI complexity for more trustworthiness — is that trade worth it for a two-input calculator, or should tools like this just pick the "best" formula and hide the disagreement?
What's a debounced input you've hit recently that had zero technical reason to be debounced? I have a hunch most of them exist to hide server round-trips that shouldn't be happening client-side at all.

I Built a Password Strength Calculator That Never Sends Your Password Anywhere Here's the Entropy Math

G S — Sat, 22 Aug 2026 16:01:31 +0000

Type Your Real Password Into a Random Website. What Could Go Wrong?

Go search "password strength checker" right now. Look at what you're being asked to do: paste your actual password — the one you maybe reuse, the one guarding your email recovery — into a text field on a website you've never heard of, with no visible indication of whether that string is being logged, sent to an analytics endpoint, or quietly saved in a form-tracking tool bolted onto the page.

Most of these tools could be doing the math client-side. Almost none of them tell you that they are. And a disturbing number of them are running third-party scripts that make client-side-only a hard thing to actually verify from the outside.

That's an insane amount of trust to extend to a page that also happens to have a sticky ad banner and a cookie consent modal stacked three deep.

So I built a Password Strength Calculator that does exactly one thing: computes real Shannon entropy, keyspace size, and brute-force crack-time estimates, entirely in your browser, with the network tab open the whole time to prove it. No password ever leaves the input field. Here's the actual math and the TypeScript behind it.

The Math: Password Strength Isn't a Vibe, It's Information Theory

Most consumer password meters are just regex rules dressed up as a progress bar — "has a number: +10%, has a symbol: +10%." That's not measurement, it's guesswork. The actual metric that matters is entropy, borrowed directly from Claude Shannon's information theory.

1. The Core Formula

E = L × log2(R)

Where:

E — entropy, measured in bits
L — password length (character count)
R — size of the character pool actually used (keyspace) Every additional bit doubles the number of guesses an attacker needs. This is why entropy, not "does it have a special character," is the real signal.

2. Detecting the Character Pool

The pool size R isn't fixed — it depends on which character classes actually appear in the password:

Class	Pool Size
Lowercase letters	26
Uppercase letters	26
Digits	10
Symbols	33

Use only lowercase letters and R = 26. Mix in digits and symbols and R climbs to 95. This is the step naive "strength meters" skip — they check for the presence of a symbol without recalculating the actual keyspace it unlocks.

3. Worked Example

Take the password k9#M2$vL — 8 characters, using all four classes:

R = 26 + 26 + 10 + 33 = 95
E = 8 × log2(95) = 8 × 6.5698 ≈ 52.56 bits

Total brute-force search space: 95^8 ≈ 6.63 × 10^15 combinations.

4. Crack Time Estimation

Entropy alone is abstract. What actually lands with people is: how long would this take to break? Convert total combinations into wall-clock time by dividing by an attacker's guess rate:

secondsToCrack = totalCombinations / guessesPerSecond

Guess rate varies wildly by attack surface, so the calculator models a spread rather than a single number:

Attack Scenario	Guess Rate
Online, rate-limited login	~100 / sec
Offline, single GPU	~10 billion / sec
Offline, multi-GPU cracking rig	~100 billion / sec

This is also the detail that makes the crack-time number honest: an 8-character password that survives "years" against a throttled login form can fall in seconds against an offline GPU rig if the hash ever leaks. Showing both numbers, not just the flattering one, is the whole point.

5. Why Length Beats Complexity

This is the counterintuitive part worth internalizing: length grows the search space exponentially, complexity only grows it linearly with pool size.

Tr0ub&9!               → 8 chars,  R=95  → E ≈ 52.6 bits
correct-horse-battery  → 21 chars, R≈7776-word dictionary → E ≈ 51+ bits (per-word entropy stacked)

A 4-word passphrase from a 7,776-word list produces comparable or greater entropy than a dense 8-character symbol soup — and it's dramatically easier for a human to actually remember and type correctly, which matters because the least secure password is the one someone writes on a sticky note out of frustration.

The TypeScript Core: Entropy Logic, Fully Isolated

Same principle as always: the math has zero business knowing what a <button> is. Pure function in, typed result out — testable without mounting a single component.

// lib/calculatePasswordStrength.ts

export interface CrackTimeEstimate {
  scenario: string;
  guessesPerSecond: number;
  secondsToCrack: number;
  humanReadable: string;
}

export interface PasswordStrengthResult {
  length: number;
  poolSize: number;
  entropyBits: number;
  totalCombinations: number;
  crackTimes: CrackTimeEstimate[];
  strengthLabel: "Very Weak" | "Weak" | "Moderate" | "Strong" | "Very Strong";
}

const POOL_LOWERCASE = 26;
const POOL_UPPERCASE = 26;
const POOL_DIGITS = 10;
const POOL_SYMBOLS = 33;

const ATTACK_SCENARIOS: { scenario: string; guessesPerSecond: number }[] = [
  { scenario: "Online, rate-limited login", guessesPerSecond: 100 },
  { scenario: "Offline, single GPU", guessesPerSecond: 1e10 },
  { scenario: "Offline, multi-GPU rig", guessesPerSecond: 1e11 },
];

function detectPoolSize(password: string): number {
  let pool = 0;
  if (/[a-z]/.test(password)) pool += POOL_LOWERCASE;
  if (/[A-Z]/.test(password)) pool += POOL_UPPERCASE;
  if (/[0-9]/.test(password)) pool += POOL_DIGITS;
  if (/[^a-zA-Z0-9]/.test(password)) pool += POOL_SYMBOLS;
  return pool;
}

function formatDuration(seconds: number): string {
  const units: [string, number][] = [
    ["centuries", 60 * 60 * 24 * 365 * 100],
    ["years", 60 * 60 * 24 * 365],
    ["days", 60 * 60 * 24],
    ["hours", 60 * 60],
    ["minutes", 60],
    ["seconds", 1],
  ];

  for (const [label, unitSeconds] of units) {
    const value = seconds / (unitSeconds as number);
    if (value >= 1) {
      return `${value < 1000 ? value.toFixed(1) : value.toExponential(2)} ${label}`;
    }
  }
  return "instantly";
}

function labelStrength(entropyBits: number): PasswordStrengthResult["strengthLabel"] {
  if (entropyBits < 28) return "Very Weak";
  if (entropyBits < 40) return "Weak";
  if (entropyBits < 60) return "Moderate";
  if (entropyBits < 80) return "Strong";
  return "Very Strong";
}

export function calculatePasswordStrength(password: string): PasswordStrengthResult {
  const length = password.length;
  const poolSize = detectPoolSize(password);

  if (length === 0 || poolSize === 0) {
    return {
      length: 0,
      poolSize: 0,
      entropyBits: 0,
      totalCombinations: 0,
      crackTimes: [],
      strengthLabel: "Very Weak",
    };
  }

  const entropyBits = length * Math.log2(poolSize);
  const totalCombinations = Math.pow(poolSize, length);

  const crackTimes: CrackTimeEstimate[] = ATTACK_SCENARIOS.map(
    ({ scenario, guessesPerSecond }) => {
      const secondsToCrack = totalCombinations / guessesPerSecond;
      return {
        scenario,
        guessesPerSecond,
        secondsToCrack,
        humanReadable: formatDuration(secondsToCrack),
      };
    }
  );

  return {
    length,
    poolSize,
    entropyBits: Number(entropyBits.toFixed(2)),
    totalCombinations,
    crackTimes,
    strengthLabel: labelStrength(entropyBits),
  };
}

Notes on the design:

detectPoolSize uses regex presence checks, not counts. One uppercase letter contributes exactly the same 26 to the pool as ten uppercase letters would — pool size is about which character classes are in play, not how often they repeat. Conflating the two is a common bug in home-grown entropy calculators.
formatDuration walks largest-unit-first so a multi-century crack time doesn't render as an ugly six-digit "hours" figure — legibility here is the entire point of showing crack time at all.
Empty/zero-pool input returns a valid zeroed result instead of NaN or throwing. A password field starts empty on every page load; the calculation function needs to handle that as a first-class case, not an edge case.

The Client Component: Live Entropy, Zero Network Calls

// components/CalculatorForm.tsx
"use client";

import { useMemo, useState } from "react";
import { calculatePasswordStrength } from "@/lib/calculatePasswordStrength";

const STRENGTH_COLOR: Record<string, string> = {
  "Very Weak": "bg-red-500/10 text-red-400",
  Weak: "bg-orange-500/10 text-orange-400",
  Moderate: "bg-yellow-500/10 text-yellow-400",
  Strong: "bg-emerald-500/10 text-emerald-400",
  "Very Strong": "bg-emerald-500/20 text-emerald-300",
};

export default function CalculatorForm() {
  const [password, setPassword] = useState("");
  const [visible, setVisible] = useState(false);

  // Pure, synchronous, client-only — this value never touches the network.
  const result = useMemo(() => calculatePasswordStrength(password), [password]);

  return (
    <div className="space-y-5">
      <div className="relative">
        <input
          type={visible ? "text" : "password"}
          value={password}
          onChange={(e) => setPassword(e.target.value)}
          placeholder="Type a password to test"
          autoComplete="off"
          spellCheck={false}
          className="w-full rounded-lg border border-zinc-700 bg-zinc-900 px-3 py-2 pr-16 font-mono text-zinc-100 outline-none focus:border-indigo-500"
        />
        <button
          type="button"
          onClick={() => setVisible((v) => !v)}
          className="absolute right-2 top-1/2 -translate-y-1/2 text-xs font-semibold text-zinc-400 hover:text-zinc-200"
        >
          {visible ? "Hide" : "Show"}
        </button>
      </div>

      {password.length > 0 && (
        <div className="space-y-4 rounded-xl border border-zinc-800 bg-zinc-900/60 p-4">
          <div
            className={`inline-block rounded-full px-3 py-1 text-xs font-semibold ${STRENGTH_COLOR[result.strengthLabel]}`}
          >
            {result.strengthLabel} — {result.entropyBits} bits of entropy
          </div>

          <div className="grid grid-cols-2 gap-3 text-sm">
            <Stat label="Length" value={result.length} />
            <Stat label="Pool Size" value={result.poolSize} />
          </div>

          <div className="space-y-2 pt-2">
            <p className="text-xs font-semibold uppercase tracking-wide text-zinc-500">
              Estimated Crack Time
            </p>
            {result.crackTimes.map((ct) => (
              <div
                key={ct.scenario}
                className="flex items-center justify-between text-sm"
              >
                <span className="text-zinc-400">{ct.scenario}</span>
                <span className="font-mono text-zinc-100">
                  {ct.humanReadable}
                </span>
              </div>
            ))}
          </div>
        </div>
      )}

      <p className="text-xs text-zinc-500">
        This calculation runs entirely in your browser. Nothing you type here
        is transmitted, logged, or stored.
      </p>
    </div>
  );
}

function Stat({ label, value }: { label: string; value: string | number }) {
  return (
    <div className="rounded-lg bg-zinc-900 px-3 py-2">
      <p className="text-xs text-zinc-500">{label}</p>
      <p className="font-mono text-zinc-100">{value}</p>
    </div>
  );
}

A couple of things worth calling out beyond the obvious useMemo recalculation pattern:

autoComplete="off" and spellCheck={false} on the input. A password strength tester is the one input on the internet where you specifically don't want the browser trying to autofill, save, or spellcheck-highlight what's typed — all three create side channels you didn't ask for.
The trust statement lives directly under the input, not in a footer disclaimer. If the entire value proposition is "this doesn't leave your browser," that claim needs to be visible at the moment of use, not buried three scrolls down.
No onSubmit, no fetch, no server action. There's no form to submit — the absence of a submit handler is the security model. If you go looking for a network call in this component, you won't find one, because there isn't one.

Why "Nothing Leaves the Browser" Is Also a Performance Win

Treating this as a security feature undersells it — cutting the network entirely also happens to be a straightforward performance win:

Metric	Typical "Send to Server" Checker	HypeCalc (Client-Only)
Network round-trip per keystroke	50–300ms+	0ms — never leaves the browser
Server dependency	Requires backend uptime	None — pure client function
Data exposure surface	Password transits network + server logs	Zero transmission, ever
Recalculation latency	Debounced, network-bound	Sub-millisecond, synchronous
Third-party script interference	Common (analytics, ad tags)	None on the calculation path

There's a nice bit of alignment here: the architecture that's best for the user's privacy — do the computation locally, don't phone home — is also just... the fastest possible architecture. Removing the network isn't a trade-off against performance, it's the same decision wearing two hats.

Try Breaking It

The full calculator — entropy, keyspace detection, and the three-scenario crack-time model — is live and running client-side right now:

HypeCalc Password Strength Calculator →

Open the network tab before you type anything. Watch it stay empty the entire time you're testing passwords. That's not a claim in a privacy policy — you can verify it yourself in about ten seconds.

Discussion

A few things I keep going back and forth on:

Should password strength meters be legally required to disclose whether the check is client-side or server-side? Right now it's basically invisible to the average user, and the stakes (an actual password) feel higher than most other "trust me" UI patterns.
Is entropy alone even the right metric anymore, given how much modern cracking leans on dictionary and pattern-based attacks rather than pure brute force? Where do you think a "real-world" strength score should diverge from the textbook Shannon formula?
What's a case where you specifically avoided a legitimate-looking tool because you didn't trust what it was doing with your input — password checkers, JSON formatters, base64 decoders, anything? I suspect this list is longer than most people admit. Curious to hear where people land, especially anyone who's built entropy-based tooling for an actual auth system rather than a public calculator.

I Built a Tile Calculator That Beats Every Home Depot Clone on Google AND Lighthouse (Next.js + JSON-LD Breakdown)

G S — Thu, 20 Aug 2026 11:15:37 +0000

The Search Result That Broke Me

I typed "how many tiles do I need for a bathroom floor" into Google, clicked the top result, and got:

A wall of text before the calculator, padded with keyword-stuffed filler sentences that said nothing
Zero explanation of waste percentage — just a single input box that assumed I already knew my layout pattern added risk
A box-count answer with no rounding logic shown, so I had no idea if "6.8 boxes" meant they'd round up or just leave me short
No schema markup, no FAQ rich results, no structured data — just a static page competing purely on backlinks from 2014

The math behind tiling a floor is genuinely simple. The information architecture around explaining that math — clearly, correctly, in a way both Google's crawler and a human skimming on their phone can parse — is where almost every calculator site quietly fails.

So when I built the Tile Calculator for HypeCalc, I treated it as two engineering problems stacked on top of each other: a correct calculation engine, and a content/SEO layer that doesn't lie to search engines. This post covers both, because the second one is the part nobody writes case studies about — and it's arguably the harder problem.

Problem One: The Math Isn't Hard, But the Waste Percentage Is Where Everyone Cheats

Tile math has four real steps, and almost every calculator online only shows you the first two:

1. Tile Surface Area

Tile dimensions are sold in inches; rooms are measured in square feet. You have to convert:

tileAreaSqFt = (tileLengthInches × tileWidthInches) / 144

2. Base Tile Count

Straightforward division — how many tiles physically fit the room's square footage, ignoring cuts:

baseTileCount = roomAreaSqFt / tileAreaSqFt

3. Waste Percentage (the step everyone skips or fudges)

This is the number that actually separates a useful calculator from a toy. Waste isn't a flat constant — it's a function of layout pattern, because different patterns generate different amounts of unusable offcut at the perimeter:

Layout Pattern	Waste Factor
Grid / Straight Stack	10%
Running Bond / Offset	10–12%
Diagonal (45°)	15%
Herringbone / Chevron	15–20%

A diagonal layout produces triangular offcuts along every perimeter wall that can't be reused elsewhere — that's not a rounding error, it's geometry, and a calculator that applies a flat 10% to every pattern is quietly telling people to under-order.

totalTilesWithWaste = baseTileCount × (1 + wasteFactor)

4. Box Count — Round Up, Always

This is the step that determines whether someone drives back to the store mid-project:

totalBoxes = ceil(totalTilesWithWaste × tileAreaSqFt / boxCoverageSqFt)

Math.ceil, not Math.round. A calculator that rounds 6.4 boxes down to 6 has just told someone to show up short on install day. This is the kind of detail that's invisible until you're the person standing in the tile aisle doing mental math because a website rounded the wrong direction.

The TypeScript Calculation Core

Same architectural principle as every calculator in this suite: pure functions, zero React, fully typed, unit-testable in isolation.

// lib/calculateTile.ts

export type LayoutPattern = "grid" | "runningBond" | "diagonal" | "herringbone";

export interface TileInput {
  roomLengthFt: number;
  roomWidthFt: number;
  tileLengthInches: number;
  tileWidthInches: number;
  layoutPattern: LayoutPattern;
  boxCoverageSqFt: number;
  customWastePercent?: number; // override the pattern default if provided
}

export interface TileResult {
  roomAreaSqFt: number;
  tileAreaSqFt: number;
  baseTileCount: number;
  wastePercentApplied: number;
  totalTiles: number;
  totalCoverageSqFt: number;
  totalBoxes: number;
}

const WASTE_FACTORS: Record<LayoutPattern, number> = {
  grid: 0.10,
  runningBond: 0.12,
  diagonal: 0.15,
  herringbone: 0.20,
};

export function calculateTile({
  roomLengthFt,
  roomWidthFt,
  tileLengthInches,
  tileWidthInches,
  layoutPattern,
  boxCoverageSqFt,
  customWastePercent,
}: TileInput): TileResult {
  if (
    roomLengthFt <= 0 ||
    roomWidthFt <= 0 ||
    tileLengthInches <= 0 ||
    tileWidthInches <= 0 ||
    boxCoverageSqFt <= 0
  ) {
    throw new Error("All dimensions must be positive numbers.");
  }

  const roomAreaSqFt = roomLengthFt * roomWidthFt;
  const tileAreaSqFt = (tileLengthInches * tileWidthInches) / 144;
  const baseTileCount = roomAreaSqFt / tileAreaSqFt;

  const wastePercentApplied =
    customWastePercent ?? WASTE_FACTORS[layoutPattern];

  const totalTiles = baseTileCount * (1 + wastePercentApplied);
  const totalCoverageSqFt = totalTiles * tileAreaSqFt;
  const totalBoxes = Math.ceil(totalCoverageSqFt / boxCoverageSqFt);

  return {
    roomAreaSqFt: Number(roomAreaSqFt.toFixed(2)),
    tileAreaSqFt: Number(tileAreaSqFt.toFixed(3)),
    baseTileCount: Number(baseTileCount.toFixed(2)),
    wastePercentApplied,
    totalTiles: Math.ceil(totalTiles),
    totalCoverageSqFt: Number(totalCoverageSqFt.toFixed(2)),
    totalBoxes,
  };
}

Notice customWastePercent — an optional override with ??, not ||. If someone explicitly wants 0% waste for a test calculation, || would silently fall back to the pattern default because 0 is falsy. That's the kind of bug that only surfaces in a code review months later when someone asks "why can't I set waste to zero?"

The Client Component: Pattern-Aware, Instant Feedback

// components/CalculatorForm.tsx
"use client";

import { useMemo, useState } from "react";
import { calculateTile, type LayoutPattern } from "@/lib/calculateTile";

const PATTERN_LABELS: Record<LayoutPattern, string> = {
  grid: "Grid / Straight Stack (+10%)",
  runningBond: "Running Bond / Offset (+12%)",
  diagonal: "Diagonal 45° (+15%)",
  herringbone: "Herringbone / Chevron (+20%)",
};

export default function CalculatorForm() {
  const [roomLengthFt, setRoomLengthFt] = useState(10);
  const [roomWidthFt, setRoomWidthFt] = useState(10);
  const [tileLengthInches, setTileLengthInches] = useState(12);
  const [tileWidthInches, setTileWidthInches] = useState(24);
  const [layoutPattern, setLayoutPattern] = useState<LayoutPattern>("runningBond");
  const [boxCoverageSqFt, setBoxCoverageSqFt] = useState(16);

  const result = useMemo(() => {
    try {
      return calculateTile({
        roomLengthFt,
        roomWidthFt,
        tileLengthInches,
        tileWidthInches,
        layoutPattern,
        boxCoverageSqFt,
      });
    } catch {
      return null;
    }
  }, [roomLengthFt, roomWidthFt, tileLengthInches, tileWidthInches, layoutPattern, boxCoverageSqFt]);

  return (
    <div className="space-y-5">
      <div className="grid grid-cols-2 gap-4">
        <NumberField label="Room Length (ft)" value={roomLengthFt} onChange={setRoomLengthFt} />
        <NumberField label="Room Width (ft)" value={roomWidthFt} onChange={setRoomWidthFt} />
        <NumberField label="Tile Length (in)" value={tileLengthInches} onChange={setTileLengthInches} />
        <NumberField label="Tile Width (in)" value={tileWidthInches} onChange={setTileWidthInches} />
        <NumberField label="Box Coverage (sq ft)" value={boxCoverageSqFt} onChange={setBoxCoverageSqFt} />
      </div>

      <label className="flex flex-col gap-1 text-sm font-medium text-zinc-700">
        Layout Pattern
        <select
          value={layoutPattern}
          onChange={(e) => setLayoutPattern(e.target.value as LayoutPattern)}
          className="rounded-lg border border-zinc-300 px-3 py-2 text-sm"
        >
          {Object.entries(PATTERN_LABELS).map(([key, label]) => (
            <option key={key} value={key}>{label}</option>
          ))}
        </select>
      </label>

      {result && (
        <div className="rounded-xl border border-indigo-100 bg-indigo-50/60 p-4 text-sm space-y-2">
          <Row label="Room Area" value={`${result.roomAreaSqFt} sq ft`} />
          <Row label="Tile Area" value={`${result.tileAreaSqFt} sq ft`} />
          <Row label="Waste Applied" value={`${(result.wastePercentApplied * 100).toFixed(0)}%`} />
          <Row label="Total Tiles Needed" value={result.totalTiles} />
          <Row label="Total Coverage" value={`${result.totalCoverageSqFt} sq ft`} />
          <Row label="Boxes to Order" value={result.totalBoxes} bold />
        </div>
      )}
    </div>
  );
}

function NumberField({
  label,
  value,
  onChange,
}: {
  label: string;
  value: number;
  onChange: (v: number) => void;
}) {
  return (
    <label className="flex flex-col gap-1 text-sm font-medium text-zinc-700">
      {label}
      <input
        type="number"
        value={value}
        onChange={(e) => onChange(Number(e.target.value))}
        className="rounded-lg border border-zinc-300 px-3 py-2 text-sm"
      />
    </label>
  );
}

function Row({ label, value, bold }: { label: string; value: string | number; bold?: boolean }) {
  return (
    <div className="flex items-center justify-between">
      <span className="text-zinc-600">{label}</span>
      <span className={`font-mono ${bold ? "font-bold text-indigo-700" : "text-zinc-900"}`}>{value}</span>
    </div>
  );
}

Every field — room dimensions, tile size, pattern, box coverage — recomputes through the same useMemo on every change. Switching the layout dropdown from Grid to Herringbone doesn't trigger a fetch or a spinner. It's a synchronous re-derivation, so the box count updates in the same frame as the click.

Problem Two: The Part Nobody Talks About — Structured Data That's Actually True

Here's where this calculator differs from the stair calculator I wrote about previously. Tile is a much higher-search-volume, higher-competition query than stair geometry, which meant the content architecture mattered as much as the math. Three JSON-LD schemas ship on the page:

const faqSchema = {
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How do you calculate how many tiles you need?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "To calculate how many tiles you need, divide the total room square footage by the square footage of a single tile, then add 10% to 15% for cutting waste..."
      }
    }
    // ...
  ]
};

The rule I stuck to, which most SEO-driven calculator sites violate: every sentence in the schema has to be a 1:1 match with visible on-page content. It's tempting to stuff the JSON-LD with extra keyword variations that never render for a human — that's exactly the kind of structured-data spam Google's guidelines explicitly call out, and it's an easy way to get a manual action if you get greedy. The FAQ schema here answers the exact five questions rendered in the visible FAQ section, word for word. Nothing hidden, nothing inflated.

The SoftwareApplication schema is intentionally sparse for the same reason — no fabricated aggregateRating, no fake review counts. It states what's true (free, no OS restriction, DesignApplication category) and stops there.

Layout-wise, the page is a two-column split: a sticky calculator card in the right column that stays in the viewport while the left column's SEO content — formulas, worked example, FAQ — scrolls independently. That's a deliberate UX bet: the calculator is never more than one scroll away from wherever you are in the article, which is the opposite of the "scroll past 2,000 words to find the tool" pattern most competitor sites use.

Why This Beats Both the Ad-Bloated Sites and the Thin SEO Pages

	Ad-Bloated Legacy Sites	Thin "SEO Content Farm" Sites	HypeCalc
Waste % logic	Flat 10% for everything	Often absent entirely	Pattern-aware, per-layout
Box rounding	Inconsistent / hidden	Rarely shown	Always `ceil`, always visible
Structured data	None	Often fabricated ratings	1:1 accurate JSON-LD
Calculator position	Below the fold, ad-wrapped	Behind a content wall	Sticky, always visible
Lighthouse Performance	40–65	60–80 (less JS, but bloated images)	100/100

The pattern holds from the stair calculator case study: correctness and speed aren't in tension with good content — the sites that fail at one usually fail at the other too, because both failures come from the same root cause of prioritizing everything except the person trying to use the tool.

Go Poke At It

The calculator, the schema markup, the sticky layout — all live right now, not a demo environment:

HypeCalc Tile Calculator →

View source, check the JSON-LD in the <head>, run it through Google's Rich Results Test, throw Lighthouse at it. Everything above is exactly what ships to production.

Discussion

Where's your line between "helpful structured data" and "SEO manipulation"? I stuck to 1:1 content matching as a hard rule — is that too conservative, or is any deviation from strictly-necessary schema a slippery slope?
Sticky calculator vs. scroll-to-tool — for utility pages specifically, is a persistently-visible interactive element actually better UX, or does it just feel that way to developers who are impatient by nature?
What's a "simple" calculator you've used that got the rounding direction wrong (rounding down when it should round up, or vice versa) and cost you time or money because of it?

I Got Sick of Ad-Bloated Utility Sites, So I Built an Ad-Free Stair Calculator in Next.js

G S — Tue, 18 Aug 2026 11:08:20 +0000

The Last Straw

I needed to calculate stair stringer lengths for a deck project. Simple math. Pythagorean theorem, some IRC code checks, maybe a diagram.

Instead, I got this:

17 banner ads, three of which auto-played video with sound
A "Continue to Calculator" button that scrolled me past 2,400 words of SEO filler
4 seconds of layout shift while ad slots fought for space around the one <input> I actually needed
A 2.1MB JavaScript bundle for a tool that, mathematically, needs about 40 lines of code
A results panel that popped up under a sticky ad banner, so I had to scroll to see my own numbers

I closed the tab, opened VS Code, and did the geometry by hand faster than the site would have let me.

Then I got annoyed enough to fix it properly. That annoyance became HypeCalc — a suite of construction and engineering calculators built the way tools should be built in 2026: no ads, no tracking scripts, no popups, just fast, correct, typed calculations rendered instantly in the browser.

This post is the engineering breakdown of the Stair Calculator specifically — the actual stair geometry math, the IRC code-compliance logic, and the Next.js/TypeScript architecture that makes it recalculate in under a millisecond on every keystroke.

If you've ever been mad enough at a bloated utility site to rebuild it yourself, this one's for you.

The Actual Problem: Stair Geometry Isn't Hard, It's Just Unforgiving

Before touching React, I had to get the math airtight, because stair geometry has zero tolerance for "close enough." A stringer cut a quarter-inch off spec is a tripping hazard, and most jurisdictions enforce the International Residential Code (IRC) for exactly that reason.

Here's the full derivation, in the order a carpenter actually thinks about it:

1. Total Rise vs. Target Unit Rise

Total Rise is the vertical distance you need to climb (floor to floor). You don't just pick a riser height and hope it divides evenly — you start from an ergonomic target, because comfortable stairs cluster around a 7.5" unit rise. Too short and the stair feels shallow and awkward; too tall and it's exhausting and, past a point, illegal.

targetUnitRise = 7.5 // inches, the sweet spot most codes gravitate toward

2. Solving for the Riser Count

You can't have a fractional stair, so you round to the nearest whole number of risers:

numberOfRisers = round(totalRise / targetUnitRise)

3. Actual Unit Rise (the number that matters)

This is the riser height you'll actually build, once the total rise is split evenly across whole risers:

actualUnitRise = totalRise / numberOfRisers

This is the step where most hand-built spreadsheets quietly go wrong — people forget to re-derive the actual rise and just use the 7.5" target, which throws off every downstream number.

4. Tread Count

Fencepost problem: a staircase with 14 risers has 13 treads, because the top riser lands you on the upper floor itself, not on a tread.

treadCount = numberOfRisers - 1

5. Total Run

Multiply tread count by tread depth (commonly 10"–11" per IRC minimums) to get the horizontal footprint:

totalRun = treadCount × treadDepth

6. Stringer Length (Pythagoras earns its keep)

The stringer is the diagonal structural member the treads sit on — literally the hypotenuse of the rise/run triangle:

stringerLength = √(totalRise² + totalRun²)

7. Incline Angle

Useful for headroom checks and for knowing whether you're building a staircase or a ladder:

inclineAngleDegrees = arctan(totalRise / totalRun) × (180 / π)

8. Code Compliance Check (IRC baseline)

Riser height must fall between 4" and 7.75"
Tread depth must be ≥ 10"

Anything outside that range gets flagged in the UI immediately — no silent bad math.

The TypeScript Core: Math Isolated From UI

The single biggest architectural decision was refusing to let calculation logic leak into components. The math is pure, synchronous, and 100% unit-testable with zero React in sight:

// lib/calculateStairs.ts

export interface StairInput {
  totalRiseInches: number;
  treadDepthInches: number;
  targetUnitRiseInches?: number; // defaults to 7.5"
}

export interface StairResult {
  numberOfRisers: number;
  treadCount: number;
  actualUnitRiseInches: number;
  totalRunInches: number;
  stringerLengthInches: number;
  inclineAngleDegrees: number;
  isRiserCompliant: boolean;
  isTreadCompliant: boolean;
  isFullyCompliant: boolean;
}

const IRC_MIN_RISER = 4;
const IRC_MAX_RISER = 7.75;
const IRC_MIN_TREAD = 10;

export function calculateStairs({
  totalRiseInches,
  treadDepthInches,
  targetUnitRiseInches = 7.5,
}: StairInput): StairResult {
  if (totalRiseInches <= 0 || treadDepthInches <= 0) {
    throw new Error("Total rise and tread depth must be positive numbers.");
  }

  const numberOfRisers = Math.max(
    1,
    Math.round(totalRiseInches / targetUnitRiseInches)
  );

  const actualUnitRiseInches = totalRiseInches / numberOfRisers;
  const treadCount = Math.max(0, numberOfRisers - 1);
  const totalRunInches = treadCount * treadDepthInches;

  const stringerLengthInches = Math.sqrt(
    totalRiseInches ** 2 + totalRunInches ** 2
  );

  const inclineAngleDegrees =
    totalRunInches === 0
      ? 90
      : Math.atan(totalRiseInches / totalRunInches) * (180 / Math.PI);

  const isRiserCompliant =
    actualUnitRiseInches >= IRC_MIN_RISER &&
    actualUnitRiseInches <= IRC_MAX_RISER;
  const isTreadCompliant = treadDepthInches >= IRC_MIN_TREAD;

  return {
    numberOfRisers,
    treadCount,
    actualUnitRiseInches: Number(actualUnitRiseInches.toFixed(3)),
    totalRunInches: Number(totalRunInches.toFixed(3)),
    stringerLengthInches: Number(stringerLengthInches.toFixed(3)),
    inclineAngleDegrees: Number(inclineAngleDegrees.toFixed(2)),
    isRiserCompliant,
    isTreadCompliant,
    isFullyCompliant: isRiserCompliant && isTreadCompliant,
  };
}

Why isolate it like this?

Testability — this function has no dependency on React, the DOM, or fetch. It's a pure function of numbers in, numbers out. I can throw it into Jest/Vitest with zero mocking.
Reusability — the exact same function powers a future CLI tool and a PDF export feature, without touching a single component.
Correctness under refactors — when the UI changes (and it will), the geometry can't silently break, because it's not entangled with render logic.

The Client Component: Zero-Lag Recalculation

The UI layer's only job is to collect input and render StairResult. No debouncing needed — the calculation is cheap enough that useMemo recomputes it synchronously on every keystroke with no perceptible lag, and no wasted recompute on unrelated re-renders.

// components/StairCalculator.tsx
"use client";

import { useMemo, useState } from "react";
import { calculateStairs, type StairResult } from "@/lib/calculateStairs";

export default function StairCalculator() {
  const [totalRise, setTotalRise] = useState(108); // inches
  const [treadDepth, setTreadDepth] = useState(10.5); // inches

  const result: StairResult | null = useMemo(() => {
    if (totalRise <= 0 || treadDepth <= 0) return null;
    return calculateStairs({
      totalRiseInches: totalRise,
      treadDepthInches: treadDepth,
    });
  }, [totalRise, treadDepth]);

  return (
    <div className="mx-auto w-full max-w-xl rounded-2xl border border-zinc-800 bg-zinc-950 p-6 text-zinc-100 shadow-xl">
      <h2 className="mb-6 text-xl font-semibold tracking-tight">
        Stair Calculator
      </h2>

      <div className="grid grid-cols-1 gap-4 sm:grid-cols-2">
        <label className="flex flex-col gap-1 text-sm text-zinc-400">
          Total Rise (inches)
          <input
            type="number"
            value={totalRise}
            onChange={(e) => setTotalRise(Number(e.target.value))}
            className="rounded-lg border border-zinc-700 bg-zinc-900 px-3 py-2 text-zinc-100 outline-none focus:border-emerald-500"
          />
        </label>

        <label className="flex flex-col gap-1 text-sm text-zinc-400">
          Tread Depth (inches)
          <input
            type="number"
            value={treadDepth}
            onChange={(e) => setTreadDepth(Number(e.target.value))}
            className="rounded-lg border border-zinc-700 bg-zinc-900 px-3 py-2 text-zinc-100 outline-none focus:border-emerald-500"
          />
        </label>
      </div>

      {result && (
        <div className="mt-6 space-y-3 rounded-xl border border-zinc-800 bg-zinc-900/60 p-4">
          <Row label="Number of Risers" value={result.numberOfRisers} />
          <Row label="Tread Count" value={result.treadCount} />
          <Row
            label="Actual Unit Rise"
            value={`${result.actualUnitRiseInches}"`}
          />
          <Row label="Total Run" value={`${result.totalRunInches}"`} />
          <Row
            label="Stringer Length"
            value={`${result.stringerLengthInches}"`}
          />
          <Row
            label="Incline Angle"
            value={`${result.inclineAngleDegrees}°`}
          />

          <div
            className={`mt-3 rounded-lg px-3 py-2 text-sm font-medium ${
              result.isFullyCompliant
                ? "bg-emerald-500/10 text-emerald-400"
                : "bg-red-500/10 text-red-400"
            }`}
          >
            {result.isFullyCompliant
              ? "✓ IRC code compliant"
              : "⚠ Outside IRC riser/tread limits — adjust your inputs"}
          </div>
        </div>
      )}
    </div>
  );
}

function Row({ label, value }: { label: string; value: string | number }) {
  return (
    <div className="flex items-center justify-between text-sm">
      <span className="text-zinc-400">{label}</span>
      <span className="font-mono text-zinc-100">{value}</span>
    </div>
  );
}

A few deliberate decisions worth calling out:

Controlled inputs, no form libraries. For two numeric fields, pulling in a form library is pure overhead. useState is the right tool here — resist the urge to reach for machinery you don't need.
useMemo instead of an effect. There's no async work and no side effect — this is a derived value, not a side effect, so useEffect + a second state variable would be the wrong model entirely (and a common source of double-render bugs).
Compliance rendered as a UI state, not an alert. Users adjusting inputs live shouldn't get interrupted by a modal every time they drift outside code limits; a persistent, color-coded status is far less hostile to the "just let me experiment" workflow.

Why This Architecture Wins on Core Web Vitals

The legacy tools I was comparing against are mostly still running on server-rendered PHP with jQuery bolted on for interactivity, plus 6–10 third-party ad/tracking scripts fighting for the main thread. Here's what a from-scratch Next.js build gets you instead:

Metric	Legacy Calculator Sites	HypeCalc
Cumulative Layout Shift (CLS)	0.25–0.4+ (ad slots load late)	0 (no injected ad DOM)
Time to Interactive	3–6s (waiting on ad networks)	Near-instant
JS Bundle (page-relevant)	1.5–2.5MB	Tens of KB
Lighthouse Performance	40–65	100/100
Third-party render-blocking scripts	5–15	0
Recalculation latency	Server round-trip or laggy jQuery reflow	Sub-millisecond, client-side

The pattern is simple: every millisecond of latency in a legacy calculator is spent serving someone other than the user — ad networks, trackers, engagement-bait modals. Strip all of that out and what's left is just... fast software, doing the one thing it's supposed to do.

No CLS is possible when there's no ad DOM competing for layout space. No render-blocking third-party JS is possible when there's no third-party JS. This isn't a clever optimization — it's just what's left when you delete the business model that made the old tools slow in the first place.

See It Running in Production

All of the above — the typed calculation engine, the memoized client component, the compliance checks — is live right now, not a CodeSandbox demo:

HypeCalc Stair Calculator →

Open dev tools, throw the Lighthouse audit at it, watch the network tab stay empty of tracking calls. That's the whole pitch.

Let's Argue About This

A few things I'm genuinely curious where the community lands on:

Is "ad-free utility tool" actually a sustainable business model, or does it inevitably rot into the same bloat once monetization pressure hits? I'd love to be wrong about the second half.
Where's the line between "isolate your business logic from your UI" and over-engineering a two-input calculator? I isolated calculateStairs on principle — was that the right call at this scale, or premature abstraction?
What's the worst ad-bloated utility website you've had to use recently, and did it make you angry enough to consider rebuilding it yourself?

Drop your worst offenders in the comments — I'm half-tempted to build the "revenge calculator" for whichever one is most infuriating.

The "1 Dog Year = 7 Human Years" Myth: How I Built a Veterinary-Accurate Pet Age Engine in Next.js

G S — Mon, 17 Aug 2026 17:43:01 +0000

We've all heard the golden rule of pet parenting: 1 human year equals 7 dog years.

For decades, this simple 7 times multiplier was the universal standard for guessing how old our four-legged family members are. But as anyone with a one-year-old puppy knows, a 12 month old dog can run, fetch, and reproduce milestones completely detached from a 7-year-old human child.

Veterinary research from institutions like the American Veterinary Medical Association (AVMA) has debunked the linear 7-year rule. Biological aging in companion animals is non-linear: pets mature rapidly in their first two years, after which aging trajectories diverge dramatically based on species and physical body mass.

To turn these clinical curves into an instant, interactive tool, I built a reactive Dog & Cat Age to Human Years Engine using Next.js (App Router), TypeScript, and Tailwind CSS.

Here is a look under the hood at the mathematical logic and engineering behind it.

1. The Core Aging Matrix

Pet aging curves break down into two distinct physiological phases:

The Rapid Maturation Phase (Years 1 to 2):
- Year 1: Equals roughly 15 human years (reaching biological adolescence).
- Year 2: Adds another 9 human years, bringing a 2-year-old pet to roughly 24 human years (early adult maturity).
The Divergence Phase (Year 3+):
- Cats: Age uniformly at a steady rate of +4 human years per calendar year.
- Dogs: Age based on adult weight categories. Giant breeds experience accelerated cellular wear and age much faster than toy breeds in their senior years.

Breed Profile	Weight Threshold	Multiplier (Per Year After Year 2)
Small Breeds	Under 20 lbs (Chihuahua, Yorkie)	+4.0 Human Years
Medium Breeds	21 to 50 lbs (Beagle, Bulldog)	+5.0 Human Years
Large Breeds	51 to 90 lbs (Labrador, Boxer)	+6.0 Human Years
Giant Breeds	Over 90 lbs (Great Dane, Mastiff)	+7.5 Human Years

2. Implementing the React Engine

Here is the computational hook handling the biological logic reactively:

type PetType = 'dog' | 'cat';
type DogSize = 'small' | 'medium' | 'large' | 'giant';

function calculatePetHumanAge(petType: PetType, dogSize: DogSize, petAge: number): number {
  if (petAge <= 0) return 0;

  // Phase 1: Years 1 & 2 (Universal base across cats & dogs)
  if (petAge <= 1) {
    return petAge * 15;
  }

  if (petAge <= 2) {
    return 15 + ((petAge - 1) * 9);
  }

  // Phase 2: Cats (Fixed linear scaling)
  if (petType === 'cat') {
    return 24 + ((petAge - 2) * 4);
  }

  // Phase 2: Dogs (Weight-adjusted scaling)
  const multipliers: Record<DogSize, number> = {
    small: 4.0,
    medium: 5.0,
    large: 6.0,
    giant: 7.5,
  };

  return 24 + ((petAge - 2) * multipliers[dogSize]);
}

3. Key UX & Technical Takeaways

Web Share API with Clipboard Fallback: We integrated navigator.share so pet parents can easily send results to family directly from mobile browsers, falling back seamlessly to clipboard copy on unsupported devices.
On-the-Fly CSV Export: Generating raw client-side CSV downloads without server latency makes tracking senior pet health milestones effortless.

const handleDownloadCSV = () => {
  const csvContent = "data:text/csv;charset=utf-8," 
    + ["Parameter,Value", `Species,${petType}`, `Equivalent Age,${humanYears}`].join("\n");
  const encodedUri = encodeURI(csvContent);
  const link = document.createElement("a");
  link.setAttribute("href", encodedUri);
  link.setAttribute("download", `${petType}_human_years_report.csv`);
  document.body.appendChild(link);
  link.click();
  document.body.removeChild(link);
};

Zero Layout Shift (CLS): Dynamic input toggles ensure responsive layout stabilization whether switching between canine sizing or fixed feline inputs.

4. Technical SEO: Programmatic JSON-LD Schemas

To help search crawlers accurately index the application, we inject clean JSON-LD structured data directly into the Next.js Server Component layout:

const softwareSchema = {
  "@context": "[https://schema.org](https://schema.org)",
  "@type": "SoftwareApplication",
  "name": "Dog & Cat Age to Human Years Converter",
  "operatingSystem": "All",
  "applicationCategory": "UtilitiesApplication",
  "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" }
};

This structural architecture ensures search bots understand the page provides utility-based software alongside an educational FAQ.

5. Future Roadmap & Veterinary Iterations

Building this tool highlighted how fascinating animal physiology is. In future updates, we plan to add:

Breed-Specific Epigenetic Aging: Integrating modern DNA methylation clock curves for specific high-risk dog breeds.
Senior Care Alerts: Automated prompts recommending senior veterinary screenings when pets cross the equivalent of 70 human years.

Try the Live Tool

If you want to compute your pet's exact biological age or see the engine running live in production, test it out here:

👉 Live Pet Age to Human Years Calculator

I'd love to hear your thoughts on the aging logic and any veterinary parameters you think should be added next!

DEV Community: G S

I Rebuilt the Electrician's Conduit Bending Calculator Because Trig Shouldn't Require Dodging Popups

The Jobsite Doesn't Wait for Ads to Load

The Trigonometry: Why Conduit Bending Is Just Triangles With Consequences

1. The Offset Multiplier (Distance Between Marks)

2. Shrinkage

3. The 90° Stub Take-Up

4. The 3-Point Saddle

The TypeScript Core: Lookup Tables + Pure Functions

The Page Architecture: SEO-First, Interactivity Second

What This Buys You Over the Legacy Field-Calculator Sites

Try It on an Actual Bend

Discussion

Building a Distraction-Free, Formula-Transparent Concrete Calculator with Next.js & Tailwind

"How Many Yards of Concrete for a 10x10 Slab?"

The Math: Three Shapes, One Unit System, Zero Ambiguity

1. Rectangular Slabs, Driveways, Sidewalks

2. Cylindrical Post Holes & Sonotubes

3. Solid Concrete Steps (Stacked Volume)

4. The Non-Negotiable: Waste Factor

The TypeScript Core

- Bag counts always round up (Math.ceil), never down. This is the fix for the silent-rounding bug that started this whole project. You cannot buy 44.7 bags of concrete. Rounding down is how people run short mid-pour.

The Client Component

The SEO Layer Is Structural, Not an Afterthought

Why This Loads Instantly Compared to the Competition

Try It, Then Tell Me What's Wrong With It

How I Built a Clean Sleep Calculator Using Next.js, TypeScript, and Sleep Cycle Math

2:47 AM, Googling "sleep calculator"

The Sleep Science, Reduced to a Formula

The TypeScript Core: Time Math Without Date Libraries

The Client Component: Fast, Reactive State

Server-Rendered JSON-LD & Mobile-First UX

Mobile-First Grid Hierarchy

Performance Benchmark

Check Out the Tool

Discussion Points

I Rebuilt the One-Rep Max Calculator Every Gym Bro Uses — Here's the TypeScript Math Behind the Core Strength Formulas

The Tab You Close Before Anyone Sees It

The Math: Why Three Formulas, Not One

1. Epley Formula

2. Brzycki Formula

3. Lander Formula

Why This Matters More Than It Looks Like It Does

The TypeScript Core: Three Formulas, One Pure Function

The Client Component: No Debounce, No Excuse

Structured Content Isn't the Enemy — Ad Networks Are

Try It Against Your Own Numbers

Discussion

I Built a Password Strength Calculator That Never Sends Your Password Anywhere Here's the Entropy Math

Type Your Real Password Into a Random Website. What Could Go Wrong?

The Math: Password Strength Isn't a Vibe, It's Information Theory

1. The Core Formula

2. Detecting the Character Pool

3. Worked Example

4. Crack Time Estimation

5. Why Length Beats Complexity

The TypeScript Core: Entropy Logic, Fully Isolated

The Client Component: Live Entropy, Zero Network Calls

Why "Nothing Leaves the Browser" Is Also a Performance Win

Try Breaking It

Discussion

I Built a Tile Calculator That Beats Every Home Depot Clone on Google AND Lighthouse (Next.js + JSON-LD Breakdown)

The Search Result That Broke Me

Problem One: The Math Isn't Hard, But the Waste Percentage Is Where Everyone Cheats

1. Tile Surface Area

2. Base Tile Count

3. Waste Percentage (the step everyone skips or fudges)

4. Box Count — Round Up, Always

The TypeScript Calculation Core

The Client Component: Pattern-Aware, Instant Feedback

Problem Two: The Part Nobody Talks About — Structured Data That's Actually True

Why This Beats Both the Ad-Bloated Sites and the Thin SEO Pages

Go Poke At It

Discussion

I Got Sick of Ad-Bloated Utility Sites, So I Built an Ad-Free Stair Calculator in Next.js

The Last Straw

The Actual Problem: Stair Geometry Isn't Hard, It's Just Unforgiving

1. Total Rise vs. Target Unit Rise

2. Solving for the Riser Count

3. Actual Unit Rise (the number that matters)

- Bag counts always round up (`Math.ceil`), never down. This is the fix for the silent-rounding bug that started this whole project. You cannot buy 44.7 bags of concrete. Rounding down is how people run short mid-pour.