DEV Community: G S

Zero Server Bills: Handling High-Resolution PNG to WebP Compression on the Client Side

G S — Thu, 24 Sep 2026 09:28:14 +0000

Anyone who's ever tried to run a photo-heavy website knows that high-resolution PNG files can be a real burden, both in terms of loading speed and storage costs. This tool takes care of that by converting large, high-resolution PNGs into the much smaller WebP format, and it does all of that work directly inside your browser instead of on a remote server. That means there are no server bills involved in processing your images, since your own device is doing all the heavy lifting. Whether you're a photographer, a store owner, or just someone with a lot of big image files, this gives you an easy way to shrink them down without any extra cost or complexity.

The process itself is simple enough for anyone to use. Just open the tool, then drag your high-resolution PNG files into the upload box, or click to browse and select them from your computer. The tool converts them to WebP almost instantly, showing you a clear comparison between the original file size and the newly compressed one. Once you're satisfied with the results, click download to save your smaller, web-ready images.

Working with high-resolution images usually means bigger files, and bigger files usually mean more strain on whatever is doing the processing. When that processing happens on a server, the company running it has to pay for the computing power needed to handle those larger files, especially when lots of people are converting big images at the same time. By handling everything on your own device instead, this tool sidesteps that cost entirely, since your browser is simply using the processing power your computer already has. It's a smart shift that benefits both the people building the tool and the people using it.

This also means the tool can comfortably handle genuinely large images without slowing to a crawl or timing out, which is a common problem with server-based converters that place limits on file size to control their own costs. Since there's no server capacity being shared among users, your high-resolution photos get the same fast treatment as smaller ones, without any special restrictions. You're not stuck waiting in a queue behind other people's uploads, either, since your conversion is happening independently on your own device the entire time.

Keeping everything local also means your images stay private throughout the entire process, which matters even more when you're working with detailed, high-quality photos. There's no uploading involved, so there's no risk of your files being stored, logged, or accessed by anyone else along the way. This is especially valuable for photographers or businesses handling professional images they'd rather not hand over to an unknown server. You get full-quality compression results with none of the usual trust required to use an online tool.

Put simply, this approach gives you a converter that's fast, completely free, and easy to use, no matter how large or high-resolution your images are. There's no software to install, no account needed, and no hidden limitations waiting to slow you down. Big batches of high-res photos get handled just as smoothly as a single small image, every single time. For anyone dealing with high-resolution PNGs regularly, this is a dependable way to compress images without worrying about costs, limits, or privacy.

Convert PNG to WebP Directly in the Browser: No Servers, No Upload Limits

G S — Thu, 24 Sep 2026 09:25:39 +0000

If you've ever tried converting a bunch of PNG images online only to hit an annoying file size cap or a "please wait in line" message, you'll appreciate what this tool does differently. It converts your PNG images into the smaller, more efficient WebP format right inside your web browser, with no servers involved at any point in the process. Because there's no server doing the work, there's also no arbitrary upload limit stopping you from converting large files or big batches at once. It's a simple, no-fuss way to get smaller, faster-loading images for your website, online store, or anywhere else you need them.

Using it is about as easy as it gets. Open the tool in your browser, then drag and drop your PNG files into the upload area, or click to select them from your device. The conversion happens almost immediately, and you'll see each new WebP file along with its updated, smaller size right on the page. When you're ready, just click download to save your converted images, and you're done.

The biggest difference between this tool and most other converters is what happens after you drop in your file, or rather, what doesn't happen. Instead of your image traveling across the internet to some company's server, being processed there, and then sent back to you, everything takes place locally using your browser's own capabilities. This is exactly why there are no upload limits here, since there's no remote server capacity to worry about running out of. Your browser does all the work, which means the tool can comfortably handle large images or long batches without breaking a sweat.

This local approach also solves another common frustration: slow or unreliable uploads. Sending large image files to a server can take a while, especially on a weaker internet connection, and sometimes the process fails partway through and forces you to start over. Since this tool skips uploading entirely, none of that applies, and conversions happen at the speed of your own device rather than the speed of your internet connection. It's a small change that ends up making a noticeably smoother experience.

There's also a welcome privacy bonus that comes along with skipping servers altogether. Because your images never leave your browser, there's no risk of them being stored, logged, or seen by anyone else during conversion. This is especially reassuring if you're working with private photos, client materials, or anything else you'd rather keep to yourself. You get the same great results as any other converter, just without having to trust a stranger's server with your files.

Altogether, this makes for a tool that's fast, completely free, and remarkably easy to use, with none of the usual limits or waiting around. There's no software to download, no account required, and no confusing settings to figure out before you get started. Whether you're converting a single image or dozens at once, the process stays quick and consistent every time. For anyone tired of upload limits and slow converters, this is a refreshingly simple way to get the job done.

No Backend Needed: Building a Blazing Fast PNG to WebP Converter with Next.js & Canvas API

G S — Thu, 24 Sep 2026 09:16:42 +0000

If you've ever needed to shrink a bunch of PNG images for a website but didn't want the hassle of servers, uploads, or extra software, this tool was made for you. It converts your PNG files into the smaller, faster WebP format entirely within your browser, using nothing more than modern web technology that's already built into the page. That means no backend, no waiting on some far-off server to process your files, and no complicated setup on your end. It's a simple way to get smaller, web-ready images in seconds, whether you're a developer, a designer, or just someone trying to speed up their website.

Using the tool is refreshingly straightforward. Just open the page, then drag your PNG images into the upload area or click to choose them from your device. Within moments, you'll see each image converted to WebP format, along with a quick look at how much smaller the new file is. Once you're happy with the results, simply download the converted images and use them however you need, whether that's uploading to your website or saving them for later.

Behind the scenes, this tool is built using Next.js, a popular framework that helps developers build fast, modern websites, paired with something called the Canvas API, which is a built-in browser feature that can draw and manipulate images. Think of the Canvas API as an invisible artist's canvas that lives inside your browser, capable of taking an image, redrawing it, and saving it out in a different format. Because this all happens using tools your browser already has, there's no need to send your images anywhere else to get the job done. It's a clever use of technology that already exists, just put together in a way that makes life easier for anyone handling images online.

Skipping the backend entirely is a bigger deal than it might sound. Traditional converters usually require uploading your file to a server, waiting for it to be processed, and then downloading the result, which takes time and depends on that server being fast, available, and trustworthy. By doing everything inside the browser, this tool removes that entire step, so conversions happen almost instantly and don't rely on anyone else's system running smoothly. It also means there's far less that can go wrong, since there's no server to crash, slow down, or get overloaded with traffic.

This approach also brings a nice bonus: your files stay private the entire time. Since nothing is ever uploaded anywhere, there's no risk of your images being stored, logged, or accessed by anyone else during the process. For anyone working with sensitive photos, unreleased designs, or just files they'd rather keep to themselves, that peace of mind is a real advantage. You get all the convenience of a powerful conversion tool without any of the usual trust required when using an online service.

All together, this makes for a converter that's fast, free, private, and genuinely easy to use, even if you don't know the first thing about how it works under the hood. There's nothing to install, no accounts to create, and no technical knowledge required to get great results. Whether you're converting one image or dozens at a time, the experience stays smooth and quick throughout. For anyone who wants a better way to prepare images for the web, this is a simple, reliable tool that gets the job done without any of the usual headaches.

Understanding Client-Side Image Compression: A Complete Guide to In-Browser PNG to WebP Conversion

G S — Thu, 24 Sep 2026 09:12:20 +0000

Anyone who manages a website or shares images online eventually runs into the same headache: PNG files look great but take up way more space than they need to. Client-side image compression solves this by converting your PNGs into the WebP format directly inside your web browser, shrinking file sizes dramatically while keeping the image looking sharp. This is especially useful for bloggers, small business owners, and anyone building a website who wants faster load times without sacrificing image quality. Instead of relying on complicated software or sending files off to an unknown service, you get a fast, simple solution that works right where you already are.

Getting started takes only a minute. Open the converter in your browser, then either drag and drop your PNG files into the upload area or click to browse and select them from your device. The tool immediately processes the images and shows you a side-by-side comparison of the original size versus the new, compressed WebP version. From there, you just hit download to save your newly compressed images, ready to use wherever you need them.

The term "client-side" simply means the conversion happens on your own device, using your browser's built-in tools, rather than on a remote server somewhere else. This is different from many online converters, which require uploading your file to a company's servers, waiting for it to process, and then downloading the result back. With client-side compression, that upload-and-wait cycle disappears entirely, since your browser is doing all the heavy lifting locally. The result feels less like using a website and more like using a lightweight app that just happens to live in your browser tab.

One of the biggest advantages of this approach is how much control and privacy it gives you over your own files. Because your images never leave your device, there's no risk of them being stored, logged, or seen by anyone else during the conversion process. This is particularly reassuring if you're working with personal photos, unreleased product images, or anything else you'd rather keep private. You get the same high-quality compression results as a server-based tool, minus the trust required to hand your files over to someone else.

WebP itself is worth understanding too, since it's the format doing the real work behind the scenes. It was designed specifically to produce smaller file sizes than PNG or JPEG while maintaining similar or better visual quality, which is exactly why so many websites have switched to using it. Smaller image files mean web pages load faster, which improves the experience for visitors and can even help with search engine rankings. Combining WebP's efficiency with a client-side conversion process gives you the best of both worlds: better performance for your website and complete privacy for your files.

Altogether, this makes for a compression method that's fast, free, secure, and refreshingly simple to use. There's no installation, no account creation, and no complicated settings to figure out before you get results. Whether you're compressing a handful of images or working through a large batch, the process stays quick and consistent every time. For anyone looking to speed up their website or simply save storage space without compromising on image quality or privacy, this kind of tool is hard to beat.

Stop Uploading Huge PNGs: Building a 100% Privacy-First, Zero-Server WebP Converter

G S — Thu, 24 Sep 2026 09:06:12 +0000

If you've ever tried to upload a screenshot or a photo to your website and watched the page grind to a halt, you already know the problem: PNG files are big, and big files slow everything down. A WebP converter solves this by shrinking your images into a smaller, web-friendly format without making them look blurry or pixelated. What makes this particular tool special is that it does all of that work right inside your browser, so your images never actually leave your computer. That matters if you're working with private photos, client files, or anything you'd rather not send off to some unknown server just to resize a picture.

Using it couldn't be simpler. First, open the tool in your browser and drag your PNG file (or a batch of them) into the upload box, or just click to select files from your computer. The tool instantly converts them to WebP format right there on the page, and you'll see a preview along with the new, smaller file size. Once you're happy with the result, just click download and save the converted file wherever you like. There's no waiting around for uploads or downloads to a remote server, because none of that ever happens.

The "zero-server" part of this tool is what really sets it apart from most converters you'll find online. Instead of sending your file to a company's servers for processing, everything happens locally using your browser's own built-in capabilities. This means the tool works even if your internet connection is spotty, since nothing actually needs to be transmitted once the page has loaded. It also means there's no queue, no waiting for a server to free up, and no risk of your file getting stuck mid-upload.

Privacy is the heart of why this tool was built the way it was. Every day, people unknowingly upload sensitive images, business documents, or personal photos to random online converters without a second thought about where those files go or how long they're stored. With a zero-server approach, that entire risk disappears, because there's simply no server to store, log, or misuse your data. You get the exact same conversion result, just without the trust exercise.

Beyond privacy, this approach happens to make the tool faster too. Since your file doesn't have to travel across the internet to a server and back, conversions happen almost instantly, even with larger images. There's also no dependency on server capacity or traffic, so the tool performs the same whether you're the only person using it or one of thousands doing so at the same moment. Speed and privacy end up going hand in hand here, which isn't something you can say about most online tools.

Put simply, this WebP converter gives you everything a good tool should: it's fast, completely free, incredibly easy to use, and doesn't ask you to trust a stranger's server with your files. Anyone who regularly deals with images, whether for a blog, an online store, or just tidying up personal photos, will notice the difference immediately. There's no software to install, no account to create, and no learning curve to climb. It's simply a faster, safer way to handle a problem nearly everyone runs into sooner or later.

My Dog Ate Chocolate at 2AM and Every Tool Was Buried Under Ads, So I Built an Instant Next.js Vet Calculator

G S — Mon, 14 Sep 2026 14:53:16 +0000

The Night I Actually Needed This Tool

My dog got into a bag of baking chocolate. Not "stole a cookie" chocolate — 100% unsweetened baker's chocolate, the worst possible kind. I had maybe fifteen minutes before I needed to decide: emergency vet now, or watch-and-wait.

I Googled "dog chocolate toxicity calculator" at midnight and got exactly what you'd expect from that search in 2026:

A pop-under ad that opened a second tab the instant the page loaded
A "sponsored pet insurance quote" modal blocking the input fields
A calculator that required me to accept cookies from 40 vendors before it would even render
Numbers that appeared, then jumped as three more ad units loaded above them — I copied down the wrong mg/kg value because the page reflowed mid-read
Zero indication of where my dog's number sat relative to actual clinical thresholds — just a raw number with no context I got the number I needed from a static reference chart in a browser tab I'd opened separately, did the arithmetic myself, and called the emergency vet. My dog was fine. The website's UX was not.

A few days later, still annoyed, I built the tool that should have existed: HypeCalc's Dog Chocolate Toxicity Calculator — no ads, no layout shift, no cookie wall between a panicking pet owner and a number that matters. This post is the engineering behind it: the actual toxicology formula, the typed calculation core, and the architecture decisions that make it render correctly the first time, every time — because for this particular tool, "first time" is the only time that counts.

The Domain Problem: This Math Has to Be Right, Not Just Fast

Unlike a lot of utility calculators, this one has real stakes attached to correctness. Theobromine poisoning in dogs is dose-dependent, weight-dependent, and chocolate-type-dependent, and clinical decisions get made off the output. That constraint shaped every engineering choice below.

The Core Toxicology

Dogs metabolize theobromine (and, to a lesser extent, caffeine) far slower than humans do — it can take upwards of 17 hours to clear half the ingested dose. As it accumulates, it overstimulates the central nervous system and stresses the cardiovascular system. The clinical dose-response, expressed in mg of theobromine per kg of body weight, is well established:

< 20 mg/kg        → Mild GI upset, low risk
20 – 39.9 mg/kg    → Mild-to-moderate toxicity, vomiting, restlessness
40 – 59.9 mg/kg    → Cardiotoxic range, elevated heart rate, tremors
≥ 60 mg/kg         → Critical, seizure/lethality risk

The Formula

Total Theobromine (mg) = Ounces Consumed × mg Theobromine per Ounce (by chocolate type)
Dog Weight (kg)         = Dog Weight (lbs) × 0.453592
Dose (mg/kg)             = Total Theobromine (mg) / Dog Weight (kg)

The variable that trips people up isn't the arithmetic — it's the theobromine-per-ounce constant, which swings by nearly 3000x across chocolate types:

Chocolate Type	Theobromine (mg/oz)
White chocolate	~0.25
Milk chocolate	~60
Semi-sweet / dark (50%)	~150
Dark chocolate (70–85%)	~260
Baker's unsweetened	~400
Dry cocoa powder	~750

This is why a calculator that just asks "how many ounces" and ignores chocolate type isn't a calculator — it's a coin flip. Two ounces of white chocolate and two ounces of dry cocoa powder are not remotely the same emergency.

The TypeScript Core: A Lookup Table, Not a Magic Number

Because the per-ounce constant is the single highest-leverage variable in this whole tool, it gets its own typed table instead of being buried as a literal inside a formula. This is the difference between a calculator you can silently get wrong and one where the correct value is impossible to omit:

// lib/calculateChocolateToxicity.ts

export type ChocolateType =
  | "white"
  | "milk"
  | "semiSweet"
  | "dark"
  | "bakers"
  | "cocoaPowder";

const THEOBROMINE_MG_PER_OUNCE: Record<ChocolateType, number> = {
  white: 0.25,
  milk: 60,
  semiSweet: 150,
  dark: 260,
  bakers: 400,
  cocoaPowder: 750,
};

export type ToxicitySeverity =
  | "negligible"
  | "mild"
  | "moderate"
  | "cardiotoxic"
  | "critical";

export interface ToxicityInput {
  dogWeightLbs: number;
  chocolateType: ChocolateType;
  ouncesConsumed: number;
}

export interface ToxicityResult {
  totalTheobromineMg: number;
  dogWeightKg: number;
  doseMgPerKg: number;
  severity: ToxicitySeverity;
  requiresEmergencyVet: boolean;
}

const LBS_TO_KG = 0.453592;

function classifySeverity(doseMgPerKg: number): ToxicitySeverity {
  if (doseMgPerKg < 20) return "negligible";
  if (doseMgPerKg < 40) return "mild";
  if (doseMgPerKg < 60) return "cardiotoxic" as ToxicitySeverity; // see note below
  return "critical";
}

export function calculateChocolateToxicity({
  dogWeightLbs,
  chocolateType,
  ouncesConsumed,
}: ToxicityInput): ToxicityResult {
  if (dogWeightLbs <= 0 || ouncesConsumed < 0) {
    throw new Error("Dog weight must be positive and ounces cannot be negative.");
  }

  const mgPerOunce = THEOBROMINE_MG_PER_OUNCE[chocolateType];
  const totalTheobromineMg = ouncesConsumed * mgPerOunce;
  const dogWeightKg = dogWeightLbs * LBS_TO_KG;
  const doseMgPerKg = totalTheobromineMg / dogWeightKg;

  const severity = classifySeverity(doseMgPerKg);

  return {
    totalTheobromineMg: Number(totalTheobromineMg.toFixed(1)),
    dogWeightKg: Number(dogWeightKg.toFixed(2)),
    doseMgPerKg: Number(doseMgPerKg.toFixed(2)),
    severity,
    requiresEmergencyVet: doseMgPerKg >= 20,
  };
}

(The severity classifier in the excerpt above collapses two clinical bands for brevity — the production version returns a distinct "moderate" tier between 20–40 mg/kg and "cardiotoxic" between 40–60 mg/kg, matching the four-tier chart in the live tool.)

Two decisions worth explaining:

Record<ChocolateType, number> instead of a switch statement. TypeScript's exhaustiveness checking means adding a new ChocolateType without adding its corresponding constant is a compile error, not a runtime surprise. For a tool where an omitted case means silently wrong math, that's not a style preference — it's a correctness guarantee.
requiresEmergencyVet computed alongside the number, not left for the UI to infer. The 20 mg/kg emergency threshold is domain logic, not presentation logic. Keeping it in the calculation layer means the UI can't accidentally implement a slightly different threshold than the backend, the docs, or a future API consumer.

The Client Component: No Ambiguity in the Result

The UI mirrors the calculation's structure directly — dropdown for type (so the theobromine constant is never in the user's hands), two numeric fields, and a result panel whose color and copy are driven entirely by the typed severity value, not a re-derived threshold check in JSX.

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

import { useMemo, useState } from "react";
import {
  calculateChocolateToxicity,
  type ChocolateType,
  type ToxicityResult,
} from "@/lib/calculateChocolateToxicity";

const CHOCOLATE_OPTIONS: { value: ChocolateType; label: string }[] = [
  { value: "white", label: "White Chocolate" },
  { value: "milk", label: "Milk Chocolate" },
  { value: "semiSweet", label: "Semi-Sweet (50%)" },
  { value: "dark", label: "Dark Chocolate (70–85%)" },
  { value: "bakers", label: "Baker's Unsweetened" },
  { value: "cocoaPowder", label: "Dry Cocoa Powder" },
];

const SEVERITY_STYLES: Record<ToxicityResult["severity"], string> = {
  negligible: "bg-emerald-50 text-emerald-800 border-emerald-200",
  mild: "bg-yellow-50 text-yellow-900 border-yellow-200",
  moderate: "bg-orange-50 text-orange-900 border-orange-200",
  cardiotoxic: "bg-orange-50 text-orange-900 border-orange-200",
  critical: "bg-rose-50 text-rose-900 border-rose-300",
};

export default function CalculatorForm() {
  const [weightLbs, setWeightLbs] = useState(30);
  const [chocolateType, setChocolateType] = useState<ChocolateType>("dark");
  const [ounces, setOunces] = useState(2);

  const result: ToxicityResult | null = useMemo(() => {
    if (weightLbs <= 0 || ounces < 0) return null;
    return calculateChocolateToxicity({
      dogWeightLbs: weightLbs,
      chocolateType,
      ouncesConsumed: ounces,
    });
  }, [weightLbs, chocolateType, ounces]);

  return (
    <div className="space-y-4">
      <label className="flex flex-col gap-1 text-sm font-medium text-zinc-700">
        Dog Weight (lbs)
        <input
          type="number"
          value={weightLbs}
          onChange={(e) => setWeightLbs(Number(e.target.value))}
          className="rounded-lg border border-zinc-300 px-3 py-2 outline-none focus:border-indigo-500"
        />
      </label>

      <label className="flex flex-col gap-1 text-sm font-medium text-zinc-700">
        Chocolate Type
        <select
          value={chocolateType}
          onChange={(e) => setChocolateType(e.target.value as ChocolateType)}
          className="rounded-lg border border-zinc-300 px-3 py-2 outline-none focus:border-indigo-500"
        >
          {CHOCOLATE_OPTIONS.map((opt) => (
            <option key={opt.value} value={opt.value}>
              {opt.label}
            </option>
          ))}
        </select>
      </label>

      <label className="flex flex-col gap-1 text-sm font-medium text-zinc-700">
        Ounces Consumed
        <input
          type="number"
          step="0.25"
          value={ounces}
          onChange={(e) => setOunces(Number(e.target.value))}
          className="rounded-lg border border-zinc-300 px-3 py-2 outline-none focus:border-indigo-500"
        />
      </label>

      {result && (
        <div
          className={`rounded-xl border p-4 text-sm font-medium ${SEVERITY_STYLES[result.severity]}`}
        >
          <div className="flex justify-between">
            <span>Estimated dose</span>
            <span className="font-mono">{result.doseMgPerKg} mg/kg</span>
          </div>
          {result.requiresEmergencyVet && (
            <p className="mt-2 font-semibold">
              ⚠ This dose falls at or above the 20 mg/kg threshold — contact an
              emergency vet or animal poison control now.
            </p>
          )}
        </div>
      )}
    </div>
  );
}

The result panel deliberately does not say "you're fine" at any severity level below the threshold — it states the number and, only above threshold, adds an explicit action. Under-promising and pointing people toward a professional is the correct default for a tool like this, not a UX nicety.

Why the Server Component Shell Matters Here

The page.tsx this component lives inside isn't just a wrapper — it's doing real work that a client-only SPA version of this tool couldn't do as well:

JSON-LD schemas rendered server-side (BreadcrumbList, SoftwareApplication, FAQPage) mean search engines and AI answer engines can parse the page's structure and FAQ content without executing a single line of client JS. For an emergency-use tool, showing up correctly in a zero-click search result is a feature, not just SEO — someone panicking at 1am benefits from getting the answer band directly in the search snippet.
The reference content (toxicity chart, emergency protocol, FAQ) ships as static server-rendered HTML, so it's visible and indexable immediately, with the interactive calculator hydrating separately in the sticky sidebar. Neither blocks the other.
Zero third-party scripts anywhere in the tree means there's nothing that can shift the calculator's position mid-read the way the pop-under-laden competitor did to me at 2am. The input fields are exactly where they render, every time, which matters enormously more here than on a typical marketing page.

See the Actual Tool

Everything above — the typed theobromine table, the memoized form, the schema-annotated server shell — is live:

HypeCalc Dog Chocolate Toxicity Calculator →

Open the network tab. There's nothing to block, because there's nothing third-party running.

Let's Argue About This

Where's the ethical line for "emergency-adjacent" utility tools? Is a client-side calculator like this even the right medium for something with real health stakes, or should tools like this always force a "this is not a substitute for professional advice" gate before showing a number?
Record<Type, number> lookup tables vs. a switch statement vs. a small class per variant — for a constant table this size, where's the actual complexity threshold where you'd reach for something heavier than a plain object?
How much SEO/schema machinery is "worth it" in a Next.js page component before it starts hurting readability of the component itself? This file mixes JSON-LD generation with JSX render — would you extract that, and where? If you've built a tool where a wrong number has real consequences, I'd genuinely like to hear how you handled the UX around "give the user a clear answer" vs. "don't let them treat a website as a substitute for a professional."

I Rebuilt the Aquarium Gravel Calculator with Next.js Because Every Fish Site Buries the Math Under SEO Filler

G S — Sun, 13 Sep 2026 11:05:07 +0000

The Problem: Density Math Hidden Behind 2,000 Words of Filler

I was setting up a 55-gallon planted tank and needed one number: how many pounds of substrate do I need for a 2-inch bed?

Every result on page one made me do one of these:

Scroll past a "Top 10 Best Aquarium Substrates 2024" listicle to find an actual input field
Use a calculator that only accepted gallons, silently assuming a standard tank shape that didn't match my footprint
Get a single flat number with no distinction between sand, gravel, and aqua soil — three materials with wildly different densities that produce wildly different weights for the same depth
Watch a sticky video ad cover the result the instant it rendered The actual physics here is genuinely simple: volume times density. It's the kind of calculation that belongs in a 40-line pure function, not underneath an ad-supported content farm.

So I built the Aquarium Substrate Calculator as part of the HypeCalc suite — and this time I want to walk through not just the math, but a genuinely useful architectural pattern I ended up leaning on hard: keeping a Next.js page simultaneously fast for humans, legible to search engines, and completely decoupled from the calculation logic itself.

The Math: Why "Pounds Per Gallon" Is a Bad Rule of Thumb

Most existing calculators just multiply gallons by a flat constant. That's wrong, because density varies enormously by material:

Material	Bulk Density	Density Factor (lbs/in³)
Fine Sand / Crushed Coral	~100 lbs/cu ft	0.0578
Natural Pea Gravel	~95 lbs/cu ft	0.0550
Planted Tank Aqua Soil	~55 lbs/cu ft	0.0318

Sand packs tighter than gravel (less pore space between grains), and porous baked-clay aqua soil is dramatically lighter than either. A calculator that ignores this and just says "1.5 lbs per gallon" is off by nearly 2x for aqua soil users — which matters when you're ordering $40 bags of the stuff.

The Actual Formula

Instead of gallons, the correct approach works from tank footprint (the part of the physics that's actually invariant):

Substrate Weight (lbs) = Length (in) × Width (in) × Depth (in) × Density Factor (lbs/in³)

And for anyone who wants metric:

Volume (L) = [Length (in) × Width (in) × Depth (in)] / 61.024

Worked Example: A Standard 20-Gallon Tank

A 20-gallon high tank has a 24" × 12" footprint. Target a 2-inch pea gravel bed:

Base area: 24 × 12 = 288 sq in
Total volume: 288 × 2 = 576 cubic inches
Gravel weight: 576 × 0.0550 = 31.68 lbs → round up to two 20-lb bags
Volume in liters: 576 / 61.024 = 9.44 L That's the entire calculation. No 2,000-word preamble required.

The TypeScript Core: Density as Data, Not a Magic Number

Same architectural principle as every calculator in this series — the math lives in a pure, framework-agnostic function, and material density is modeled as data, not hardcoded per-call:

// lib/calculateSubstrate.ts

export type SubstrateMaterial = "sand" | "gravel" | "aquaSoil";

interface MaterialProfile {
  label: string;
  densityLbsPerCubicInch: number;
}

const MATERIAL_DENSITIES: Record<SubstrateMaterial, MaterialProfile> = {
  sand: { label: "Fine Sand / Crushed Coral", densityLbsPerCubicInch: 0.0578 },
  gravel: { label: "Natural Pea Gravel", densityLbsPerCubicInch: 0.055 },
  aquaSoil: { label: "Planted Tank Aqua Soil", densityLbsPerCubicInch: 0.0318 },
};

export interface SubstrateInput {
  lengthInches: number;
  widthInches: number;
  depthInches: number;
  material: SubstrateMaterial;
}

export interface SubstrateResult {
  material: string;
  volumeCubicInches: number;
  volumeLiters: number;
  weightLbs: number;
  weightKg: number;
  estimatedBags: {
    twentyLb: number;
    tenKg: number;
  };
}

const LBS_TO_KG = 0.453592;
const CUBIC_INCHES_TO_LITERS = 61.024;

export function calculateSubstrate({
  lengthInches,
  widthInches,
  depthInches,
  material,
}: SubstrateInput): SubstrateResult {
  if (lengthInches <= 0 || widthInches <= 0 || depthInches <= 0) {
    throw new Error("Tank dimensions must be positive numbers.");
  }

  const profile = MATERIAL_DENSITIES[material];
  const volumeCubicInches = lengthInches * widthInches * depthInches;
  const weightLbs = volumeCubicInches * profile.densityLbsPerCubicInch;
  const volumeLiters = volumeCubicInches / CUBIC_INCHES_TO_LITERS;
  const weightKg = weightLbs * LBS_TO_KG;

  return {
    material: profile.label,
    volumeCubicInches: Number(volumeCubicInches.toFixed(2)),
    volumeLiters: Number(volumeLiters.toFixed(2)),
    weightLbs: Number(weightLbs.toFixed(2)),
    weightKg: Number(weightKg.toFixed(2)),
    estimatedBags: {
      twentyLb: Math.ceil(weightLbs / 20),
      tenKg: Math.ceil(weightKg / 10),
    },
  };
}

Modeling MATERIAL_DENSITIES as a lookup table rather than an if/else chain means adding crushed coral for reef tanks or laterite for heavy root feeders later is a one-line addition, not a logic rewrite — and the object shape gives you exhaustiveness checking for free the moment you add a new SubstrateMaterial union member.

The Client Component: Material Switch, Instant Recalc

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

import { useMemo, useState } from "react";
import {
  calculateSubstrate,
  type SubstrateMaterial,
  type SubstrateResult,
} from "@/lib/calculateSubstrate";

const MATERIAL_OPTIONS: { value: SubstrateMaterial; label: string }[] = [
  { value: "sand", label: "Fine Sand" },
  { value: "gravel", label: "Pea Gravel" },
  { value: "aquaSoil", label: "Aqua Soil" },
];

export default function CalculatorForm() {
  const [length, setLength] = useState(24);
  const [width, setWidth] = useState(12);
  const [depth, setDepth] = useState(2);
  const [material, setMaterial] = useState<SubstrateMaterial>("gravel");

  const result: SubstrateResult | null = useMemo(() => {
    if (length <= 0 || width <= 0 || depth <= 0) return null;
    return calculateSubstrate({
      lengthInches: length,
      widthInches: width,
      depthInches: depth,
      material,
    });
  }, [length, width, depth, material]);

  return (
    <div className="space-y-5">
      <div className="grid grid-cols-3 gap-3">
        <NumberField label="Length (in)" value={length} onChange={setLength} />
        <NumberField label="Width (in)" value={width} onChange={setWidth} />
        <NumberField label="Depth (in)" value={depth} onChange={setDepth} />
      </div>

      <label className="flex flex-col gap-1 text-sm font-medium text-zinc-700">
        Material
        <select
          value={material}
          onChange={(e) => setMaterial(e.target.value as SubstrateMaterial)}
          className="rounded-lg border border-zinc-300 bg-white px-3 py-2 text-zinc-900 outline-none focus:border-indigo-500"
        >
          {MATERIAL_OPTIONS.map((opt) => (
            <option key={opt.value} value={opt.value}>
              {opt.label}
            </option>
          ))}
        </select>
      </label>

      {result && (
        <div className="rounded-xl border border-zinc-200 bg-zinc-50 p-4 text-sm">
          <Row label="Material" value={result.material} />
          <Row label="Volume" value={`${result.volumeLiters} L`} />
          <Row label="Weight" value={`${result.weightLbs} lbs / ${result.weightKg} kg`} />
          <Row
            label="Estimated Bags"
            value={`${result.estimatedBags.twentyLb} × 20lb bags`}
          />
        </div>
      )}
    </div>
  );
}

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

function Row({ label, value }: { label: string; value: string }) {
  return (
    <div className="flex items-center justify-between py-1">
      <span className="text-zinc-500">{label}</span>
      <span className="font-mono font-medium text-zinc-900">{value}</span>
    </div>
  );
}

Switching material recomputes calculateSubstrate through the same useMemo — no separate effect, no manual re-fetch, no loading state, because there's nothing asynchronous to wait on. Client-side derived state doesn't need machinery borrowed from server-state patterns.

The Underrated Part: Making a Fast Page Findable

Here's the piece that doesn't get talked about enough in "I built a fast calculator" posts: speed alone doesn't win search traffic if the page can't be understood by crawlers and answer engines. So the page ships three JSON-LD schemas alongside the calculator itself, generated at build/request time from the same content that's rendered for humans — not duplicated copy that can drift out of sync:

// page.tsx (excerpt)
const faqSchema = {
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How many pounds of substrate per gallon of water?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The general rule of thumb is 1 to 1.5 pounds of substrate per gallon of water for a standard 1.5 to 2-inch bed..."
      }
    }
    // ...
  ]
};

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

A few decisions worth calling out here:

The SoftwareApplication schema intentionally omits fake aggregateRating fields. It's tempting to fabricate a 4.9-star rating to win a rich snippet, but that's the kind of structured-data spam Google actively penalizes — and it's just dishonest. The schema only asserts what's true: it's free, it's a utility app, here's what it does.
FAQ schema content is a 1:1 match with the visible on-page FAQ section, not a separate hidden payload. Search engines increasingly cross-check that structured data matches rendered content; divergence between the two is a spam signal, and duplicating content also just means two places to keep in sync by hand.
Metadata lives in the Next.js Metadata export, not <Head> tags scattered through the component tree, so title/description ownership stays in exactly one place per route. None of this touches Core Web Vitals directly, but it's the difference between "technically fast page" and "page a human actually finds when they search how much gravel do I need for a 55 gallon tank."

Where This Lands on Web Vitals

Same story as the rest of the HypeCalc suite: no ad slots means no layout shift, no third-party scripts means no render-blocking main-thread contention, and derived-state calculation means no server round-trip for a result that's cheap to compute client-side.

Metric	Typical Pet/Aquarium Utility Sites	HypeCalc
Cumulative Layout Shift	0.2+ (ad units + comment widgets)	0
JS shipped for the interactive tool	500KB–1.5MB	Tens of KB
Recalculation on input change	Often full page reflow via jQuery	Sub-millisecond, memoized
Structured data accuracy	Frequently stale/duplicated	Generated from the same content tree

Go Poke at It

The calculator, the schema, and the full content layout described above are live: HypeCalc Aquarium Substrate Calculator →

Switch materials, check the Lighthouse score, view source on the JSON-LD if you're curious how it's structured.

Discussion

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

Where's the real line between "helpful structured data" and "SEO manipulation"? I stripped fake ratings out on principle, but I'm curious how far others think is fair game.
Is co-locating long-form SEO content next to an interactive tool (rather than a pure app-only calculator) a reasonable trade-off, or does it inevitably start creeping back toward the content-farm pattern I was trying to escape?
What's a calculation you've seen buried under unnecessary UI or content bloat that really should just be a clean typed function and an input field?

I Reverse-Engineered Why Flooring Sites Tell You "Just Buy 10% Extra" — And Built a Calculator That Actually Does the Math

G S — Sat, 12 Sep 2026 06:28:03 +0000

"Just Order 10% Extra" Is Bad Advice, and Every Flooring Site Repeats It Anyway

I was quoting a herringbone tile job and did what everyone does: googled "how much extra tile do I need." Every result gave the same lazy, copy-pasted answer — "order 10% extra to be safe."

That number is fine for a straight grid. It is dangerously wrong for herringbone.

Here's why: in a standard running-bond layout, the offcut from the end of one row becomes the starter piece for the next row. Waste stays low — 8–10% covers you. But herringbone and chevron patterns meet every wall at a 45-degree angle, which means every single perimeter tile becomes a triangular cut that can't be reused anywhere else in the room. Grain direction, factory bevels, and pre-mitered chevron ends make most of that scrap permanently unusable. Order 10% extra on a herringbone floor and you will run out mid-install — and the replacement box you order next week almost never matches the dye lot of the first one.

So I built the calculator I actually needed: one that treats waste factor as a function of pattern complexity, not a flat number someone guessed once and every site since has copied.

This is the engineering breakdown of the Herringbone & Chevron Tile Waste Calculator — the real math behind pattern-specific waste factors, the carton-rounding logic that keeps you from short-ordering, and (because this one shipped as a real production page, not a toy) the programmatic SEO architecture — JSON-LD schemas, FAQ markup, breadcrumbs — that makes the page itself discoverable, not just functional.

The Math: Waste Factor Isn't a Constant, It's a Lookup

The core insight the "just add 10%" advice misses is that waste factor scales with how many perimeter collisions your pattern generates. I benchmarked this against real installer data and landed on a pattern-to-waste-factor table:

Layout Pattern	Waste Factor	Why
Standard Grid / Running Bond	8–10%	End cuts reused as next-row starters
45° Herringbone	15–20%	Perimeter diagonal cuts, non-reusable
Chevron (point-to-point)	18–22%	Pre-mitered ends, directional alignment loss
Angled layout + obstacles	20–25%	Drains, niches, pipe penetrations

Once you know the waste factor, the actual formula is simple — the value was in not hardcoding a single number:

Total Square Feet Needed = (Room Length × Room Width) × (1 + Waste Factor)
Cartons to Order = ⌈ Total Square Feet Needed / Square Feet Per Carton ⌉

That ceiling function matters more than it looks. Never round down, and never round to the nearest whole number — round up, always. Tile dye lots vary between manufacturing runs, so a "just order one more box next week" plan often means a visibly mismatched batch showing up on your floor. The math needs to protect the user from that mistake by default, not just report a number and let them do the rounding themselves.

Worked example: a 120 sq ft bathroom floor, herringbone pattern (18% waste), 14.5 sq ft per carton:

120 × 1.18 = 141.6 sq ft required
141.6 / 14.5 = 9.76 → round up → 10 cartons (145 sq ft)

The TypeScript Core: Pattern-Aware, Not Hardcoded

Same architectural principle as every calculator I build: the math is a pure function, fully typed, with zero React or DOM dependency. This one's slightly more interesting than a plain formula because the waste factor itself is a lookup keyed on pattern complexity:

// lib/calculateTileWaste.ts

export type TilePattern =
  | "grid"
  | "herringbone"
  | "chevron"
  | "angled-complex";

export interface TileWasteInput {
  roomLengthFt: number;
  roomWidthFt: number;
  sqFtPerCarton: number;
  pattern: TilePattern;
  /** Optional override if the user knows their exact waste allowance */
  customWasteFactor?: number;
}

export interface TileWasteResult {
  rawSquareFeet: number;
  wasteFactor: number;
  totalSquareFeetNeeded: number;
  cartonsToOrder: number;
  totalSquareFeetOrdered: number;
  overageSquareFeet: number;
}

const PATTERN_WASTE_FACTORS: Record<TilePattern, number> = {
  grid: 0.09,
  herringbone: 0.18,
  chevron: 0.2,
  "angled-complex": 0.225,
};

export function calculateTileWaste({
  roomLengthFt,
  roomWidthFt,
  sqFtPerCarton,
  pattern,
  customWasteFactor,
}: TileWasteInput): TileWasteResult {
  if (roomLengthFt <= 0 || roomWidthFt <= 0 || sqFtPerCarton <= 0) {
    throw new Error("Room dimensions and carton size must be positive.");
  }

  const wasteFactor = customWasteFactor ?? PATTERN_WASTE_FACTORS[pattern];
  const rawSquareFeet = roomLengthFt * roomWidthFt;
  const totalSquareFeetNeeded = rawSquareFeet * (1 + wasteFactor);
  const cartonsToOrder = Math.ceil(totalSquareFeetNeeded / sqFtPerCarton);
  const totalSquareFeetOrdered = cartonsToOrder * sqFtPerCarton;

  return {
    rawSquareFeet: Number(rawSquareFeet.toFixed(2)),
    wasteFactor,
    totalSquareFeetNeeded: Number(totalSquareFeetNeeded.toFixed(2)),
    cartonsToOrder,
    totalSquareFeetOrdered: Number(totalSquareFeetOrdered.toFixed(2)),
    overageSquareFeet: Number(
      (totalSquareFeetOrdered - rawSquareFeet).toFixed(2)
    ),
  };
}

The customWasteFactor escape hatch matters — a pro installer who's measured their own scrap rate on past jobs shouldn't be locked into a lookup table designed for the general case. Default to good math, but never trap an expert user who knows better.

The Client Component: Live Recalculation, Ceiling Function Front and Center

// CalculatorForm.tsx
"use client";

import { useMemo, useState } from "react";
import {
  calculateTileWaste,
  type TilePattern,
  type TileWasteResult,
} from "@/lib/calculateTileWaste";

const PATTERN_LABELS: Record<TilePattern, string> = {
  grid: "Standard Grid",
  herringbone: "45° Herringbone",
  chevron: "Chevron",
  "angled-complex": "Angled + Obstacles",
};

export default function CalculatorForm() {
  const [roomLengthFt, setRoomLengthFt] = useState(12);
  const [roomWidthFt, setRoomWidthFt] = useState(10);
  const [sqFtPerCarton, setSqFtPerCarton] = useState(14.5);
  const [pattern, setPattern] = useState<TilePattern>("herringbone");

  const result: TileWasteResult | null = useMemo(() => {
    if (roomLengthFt <= 0 || roomWidthFt <= 0 || sqFtPerCarton <= 0) {
      return null;
    }
    return calculateTileWaste({
      roomLengthFt,
      roomWidthFt,
      sqFtPerCarton,
      pattern,
    });
  }, [roomLengthFt, roomWidthFt, sqFtPerCarton, pattern]);

  return (
    <div className="flex flex-col gap-4">
      <label className="flex flex-col gap-1 text-sm font-medium text-zinc-700">
        Room Length (ft)
        <input
          type="number"
          value={roomLengthFt}
          onChange={(e) => setRoomLengthFt(Number(e.target.value))}
          className="rounded-lg border border-zinc-200 px-3 py-2 outline-none focus:border-indigo-500"
        />
      </label>

      <label className="flex flex-col gap-1 text-sm font-medium text-zinc-700">
        Room Width (ft)
        <input
          type="number"
          value={roomWidthFt}
          onChange={(e) => setRoomWidthFt(Number(e.target.value))}
          className="rounded-lg border border-zinc-200 px-3 py-2 outline-none focus:border-indigo-500"
        />
      </label>

      <label className="flex flex-col gap-1 text-sm font-medium text-zinc-700">
        Carton Coverage (sq ft)
        <input
          type="number"
          value={sqFtPerCarton}
          onChange={(e) => setSqFtPerCarton(Number(e.target.value))}
          className="rounded-lg border border-zinc-200 px-3 py-2 outline-none focus:border-indigo-500"
        />
      </label>

      <label className="flex flex-col gap-1 text-sm font-medium text-zinc-700">
        Layout Pattern
        <select
          value={pattern}
          onChange={(e) => setPattern(e.target.value as TilePattern)}
          className="rounded-lg border border-zinc-200 px-3 py-2 outline-none focus:border-indigo-500"
        >
          {Object.entries(PATTERN_LABELS).map(([value, label]) => (
            <option key={value} value={value}>
              {label}
            </option>
          ))}
        </select>
      </label>

      {result && (
        <div className="mt-2 space-y-2 rounded-xl bg-indigo-50 p-4 text-sm">
          <Row label="Waste Factor" value={`${(result.wasteFactor * 100).toFixed(0)}%`} />
          <Row label="Raw Square Footage" value={`${result.rawSquareFeet} sq ft`} />
          <Row label="Total Needed (with waste)" value={`${result.totalSquareFeetNeeded} sq ft`} />
          <Row label="Cartons to Order" value={result.cartonsToOrder} />
          <Row label="Total Ordered" value={`${result.totalSquareFeetOrdered} sq ft`} />
          <Row label="Overage Buffer" value={`${result.overageSquareFeet} sq ft`} />
        </div>
      )}
    </div>
  );
}

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

Switching the pattern dropdown instantly re-derives waste factor, total square footage, and carton count — all client-side, all synchronous, no loading spinner because there's nothing to wait on.

The Part Most "Just Ship the Component" Tutorials Skip: Making the Page Findable

A fast, correct calculator that nobody finds is a portfolio piece, not a tool. The production page pairs the calculation logic above with a programmatic SEO layer that most React tutorials never touch — three JSON-LD schemas injected directly into the page:

const faqSchema = {
  "@context": "https://schema.org",
  "@type": "FAQPage",
  mainEntity: [
    {
      "@type": "Question",
      name: "How much waste should I add for herringbone tile?",
      acceptedAnswer: {
        "@type": "Answer",
        text: "Plan for a 15% to 20% waste factor on standard rectangular rooms...",
      },
    },
    // ...
  ],
};

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

Three things worth calling out here, because they're easy to get wrong:

The FAQ schema is a 1:1 mirror of the visible on-page FAQ content, word for word. Schema markup that doesn't match what's rendered on the page is a common way to get flagged by search engines for cloaking — the JSON-LD isn't a place to stuff extra keywords the user never sees.
The SoftwareApplication schema deliberately omits a fake aggregateRating. It's tempting to bolt on a "ratingValue": "4.9" block because rich snippets with star ratings get higher CTR — but a rating with no actual review data behind it is fabricated structured data, and it's exactly the kind of thing that gets a listing penalized once caught.
Breadcrumb schema is generated from the same breadcrumbItems array that renders the visible breadcrumb UI — one source of truth, so the structured data can't silently drift out of sync with what's on the page after a future edit. This is the unglamorous half of building tools people can actually find: the calculation logic gets you a good tool, the schema layer gets you found by someone typing "how much extra tile for herringbone" into a search bar at 11pm.

Why This Beats the Legacy Flooring Calculator Sites

	Legacy Flooring Sites	This Build
Waste factor	Flat "10% for everything"	Pattern-aware lookup, 8–25%
Rounding	Often silently truncates	Explicit ceiling function, always rounds up
Structured data	Missing, or fabricated ratings	Accurate JSON-LD, 1:1 with visible content
Recalculation	Full page reload or laggy jQuery	Instant client-side `useMemo`
Third-party scripts	Ad networks, trackers, popups	Zero

See the Full Page in Production

Every schema, every formula, every input above is live right now: Herringbone & Chevron Tile Waste Calculator →

View source, check the JSON-LD in the <head>, and run it through Lighthouse — the SEO score matters here just as much as the performance score.

Discussion

A few things I want the community's actual take on:

Where's the ethical line on structured data? Mirroring visible FAQ content into schema feels legitimate to me — is there a point where "helping search engines understand your page" tips into manipulation?
Should calculation defaults ever be opinionated (like a pattern-specific waste table), or should tools always demand the user supply every input themselves? I lean toward smart defaults with an override — where do you land?
Have you shipped programmatic SEO into a React/Next.js app, and did it actually move organic traffic, or was it wasted effort compared to just writing good content? Tell me I'm wrong about the schema approach in the comments — I want to hear the counterargument.

I Kept Getting Lied to by Solar Battery Calculators, So I Built One That Actually Respects Battery Chemistry

G S — Fri, 11 Sep 2026 03:58:01 +0000

The Lie Every Solar Calculator Tells You

I was sizing a battery bank for an off-grid cabin build, and every calculator I found had the same silent bug: they treated Amp-hours as Amp-hours, full stop. Type in "100Ah" and it just multiplied by voltage and called it a day.

That's not how batteries work. Not even close.

A 100Ah LiFePO4 battery and a 100Ah lead-acid AGM battery are not interchangeable numbers — one gives you roughly 90% usable capacity, the other caps out around 50% before you start killing the plates. Feed both into a calculator that ignores chemistry and you'll walk away thinking you can run a fridge overnight on a battery that'll trip your inverter's low-voltage cutoff by 2 AM.

On top of that, most of these tools:

Ignore inverter round-trip efficiency entirely (you lose 5–15% converting DC to AC — that's not optional, it's physics)
Treat Depth of Discharge as a footnote instead of the thing that determines whether your battery lasts 300 cycles or 5,000
Bury the actual result behind ad units, so you're doing life-safety-adjacent math next to an autoplay video for gutter guards So I built the Solar Battery Bank Sizing Calculator — a tool that takes chemistry, efficiency, and autonomy seriously, ships zero ads, and gets you a real Ah/kWh number you can actually build against.

This post is the engineering breakdown: the actual sizing math, the TypeScript core that implements it, and the architectural decisions that keep it instant.

The Engineering: Why "Just Multiply Ah by Volts" Is Wrong

Sizing a battery bank correctly means answering one real question: how much usable energy do I need to store to survive N days without sun? Everything below builds toward that number.

1. Daily AC Demand → DC Demand (Inverter Loss)

Your appliances draw AC power, but batteries store DC. Every watt has to pass through an inverter, and that conversion isn't free:

dcDemandWh = dailyAcLoadWh / inverterEfficiency   // typically 0.85–0.95

Skip this step and you'll undersize by 5–15% before you've even touched the battery math.

2. Autonomy Scaling

"Days of autonomy" is how many cloudy days your bank needs to carry you through without any solar input at all:

autonomyDemandWh = dcDemandWh × daysOfAutonomy

3. Depth of Discharge (the number that actually separates chemistries)

You never draw a battery down to 0% — you draw it down to its safe DoD floor, because going past that either damages the cells (lead-acid) or trips the BMS (lithium):

DoD_LiFePO4 ≈ 0.85   // usable ~80-90%
DoD_AGM     ≈ 0.50   // usable ~50% max, or the plates sulfate

grossEnergyWh = autonomyDemandWh / depthOfDischarge

This single divisor is why a lead-acid bank has to be built at roughly double the nominal capacity of a lithium bank to deliver the same usable energy. Most naive calculators skip this entirely and just report nameplate Ah.

4. Temperature Derating (optional but real)

Battery capacity drops in cold weather — lithium chemistry loses meaningful capacity below freezing. A temperature factor lets the tool stay honest in cold climates instead of quietly overpromising:

adjustedEnergyWh = grossEnergyWh / temperatureFactor   // 1.0 in ideal conditions, lower in cold

5. Amp-Hour Conversion at Bank Voltage

Finally, convert the energy requirement into the number you actually shop for — total Amp-hours at your chosen bank voltage:

bankCapacityAh = adjustedEnergyWh / bankVoltage   // 12V, 24V, or 48V

Worked Example (matches the calculator's own copy)

3,000W array × 4.5 peak sun hours = 13,500 Wh/day generated
÷ 0.90 inverter efficiency = 15,000 Wh gross DC demand
÷ 0.85 DoD (LiFePO4, 1 day autonomy) = 17,647 Wh (17.65 kWh)
÷ 48V bank voltage = 367.6 Ah at 48V That's the number that actually tells you how many batteries to buy — not a nameplate figure that quietly assumes 100% DoD and a lossless inverter.

The TypeScript Core: Chemistry as a First-Class Type

Same architectural rule as every calculator in this suite: the math has zero knowledge of React. It's a pure function, fully typed, chemistry-aware by construction rather than by a stray if statement buried in a component.

// lib/calculateSolarBatteryBank.ts

export type BatteryChemistry = "lifepo4" | "agm" | "flooded";

export interface SolarBatteryInput {
  dailyAcLoadWh: number;
  inverterEfficiency?: number;      // default 0.90
  daysOfAutonomy?: number;          // default 1
  chemistry: BatteryChemistry;
  bankVoltage: 12 | 24 | 48;
  temperatureFactor?: number;       // default 1.0 (no derating)
}

export interface SolarBatteryResult {
  dcDemandWh: number;
  autonomyDemandWh: number;
  grossEnergyWh: number;
  adjustedEnergyWh: number;
  bankCapacityAh: number;
  bankCapacityKWh: number;
  depthOfDischarge: number;
  recommendedBatteryCount: (singleBatteryAh: number) => number;
}

const DOD_BY_CHEMISTRY: Record<BatteryChemistry, number> = {
  lifepo4: 0.85,
  agm: 0.5,
  flooded: 0.5,
};

export function calculateSolarBatteryBank({
  dailyAcLoadWh,
  inverterEfficiency = 0.9,
  daysOfAutonomy = 1,
  chemistry,
  bankVoltage,
  temperatureFactor = 1.0,
}: SolarBatteryInput): SolarBatteryResult {
  if (dailyAcLoadWh <= 0) {
    throw new Error("Daily AC load must be a positive number.");
  }
  if (inverterEfficiency <= 0 || inverterEfficiency > 1) {
    throw new Error("Inverter efficiency must be between 0 and 1.");
  }

  const depthOfDischarge = DOD_BY_CHEMISTRY[chemistry];

  const dcDemandWh = dailyAcLoadWh / inverterEfficiency;
  const autonomyDemandWh = dcDemandWh * daysOfAutonomy;
  const grossEnergyWh = autonomyDemandWh / depthOfDischarge;
  const adjustedEnergyWh = grossEnergyWh / temperatureFactor;

  const bankCapacityAh = adjustedEnergyWh / bankVoltage;
  const bankCapacityKWh = adjustedEnergyWh / 1000;

  return {
    dcDemandWh: Number(dcDemandWh.toFixed(1)),
    autonomyDemandWh: Number(autonomyDemandWh.toFixed(1)),
    grossEnergyWh: Number(grossEnergyWh.toFixed(1)),
    adjustedEnergyWh: Number(adjustedEnergyWh.toFixed(1)),
    bankCapacityAh: Number(bankCapacityAh.toFixed(1)),
    bankCapacityKWh: Number(bankCapacityKWh.toFixed(2)),
    depthOfDischarge,
    recommendedBatteryCount: (singleBatteryAh: number) =>
      Math.ceil(bankCapacityAh / singleBatteryAh),
  };
}

Why recommendedBatteryCount is a closure instead of a fixed field: the result object shouldn't need to know a specific battery SKU's Ah rating to exist. Callers pass in whatever battery they're pricing out — "how many of this 100Ah unit do I need?" — without forcing a recompute of the whole chain. It's a cheap, honest way to keep the pure calculation decoupled from a UI dropdown of battery models.

The Client Component: Chemistry-Aware, Still Zero-Lag

// CalculatorForm.tsx
"use client";

import { useMemo, useState } from "react";
import {
  calculateSolarBatteryBank,
  type BatteryChemistry,
} from "@/lib/calculateSolarBatteryBank";

const BANK_VOLTAGES = [12, 24, 48] as const;

export default function CalculatorForm() {
  const [dailyLoad, setDailyLoad] = useState(2000); // Wh/day
  const [autonomy, setAutonomy] = useState(1);
  const [chemistry, setChemistry] = useState<BatteryChemistry>("lifepo4");
  const [voltage, setVoltage] = useState<(typeof BANK_VOLTAGES)[number]>(24);

  const result = useMemo(() => {
    if (dailyLoad <= 0) return null;
    return calculateSolarBatteryBank({
      dailyAcLoadWh: dailyLoad,
      daysOfAutonomy: autonomy,
      chemistry,
      bankVoltage: voltage,
    });
  }, [dailyLoad, autonomy, chemistry, voltage]);

  return (
    <div className="space-y-4">
      <label className="flex flex-col gap-1 text-sm text-zinc-600">
        Daily AC Load (Wh)
        <input
          type="number"
          value={dailyLoad}
          onChange={(e) => setDailyLoad(Number(e.target.value))}
          className="rounded-lg border border-zinc-300 px-3 py-2 outline-none focus:border-indigo-500"
        />
      </label>

      <label className="flex flex-col gap-1 text-sm text-zinc-600">
        Days of Autonomy
        <input
          type="number"
          min={1}
          max={5}
          value={autonomy}
          onChange={(e) => setAutonomy(Number(e.target.value))}
          className="rounded-lg border border-zinc-300 px-3 py-2 outline-none focus:border-indigo-500"
        />
      </label>

      <label className="flex flex-col gap-1 text-sm text-zinc-600">
        Battery Chemistry
        <select
          value={chemistry}
          onChange={(e) => setChemistry(e.target.value as BatteryChemistry)}
          className="rounded-lg border border-zinc-300 px-3 py-2 outline-none focus:border-indigo-500"
        >
          <option value="lifepo4">LiFePO4 (Lithium)</option>
          <option value="agm">AGM (Lead-Acid)</option>
          <option value="flooded">Flooded Lead-Acid</option>
        </select>
      </label>

      <label className="flex flex-col gap-1 text-sm text-zinc-600">
        Bank Voltage
        <select
          value={voltage}
          onChange={(e) =>
            setVoltage(Number(e.target.value) as (typeof BANK_VOLTAGES)[number])
          }
          className="rounded-lg border border-zinc-300 px-3 py-2 outline-none focus:border-indigo-500"
        >
          {BANK_VOLTAGES.map((v) => (
            <option key={v} value={v}>
              {v}V
            </option>
          ))}
        </select>
      </label>

      {result && (
        <div className="mt-4 space-y-2 rounded-xl border border-indigo-200 bg-indigo-50 p-4 text-sm">
          <Row label="Required Capacity" value={`${result.bankCapacityAh} Ah`} />
          <Row label="Energy Storage" value={`${result.bankCapacityKWh} kWh`} />
          <Row
            label="Usable DoD"
            value={`${(result.depthOfDischarge * 100).toFixed(0)}%`}
          />
          <Row
            label="100Ah Batteries Needed"
            value={result.recommendedBatteryCount(100)}
          />
        </div>
      )}
    </div>
  );
}

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

The select for chemistry is deliberately not a boolean toggle. It's tempting to ship "Lithium vs. Lead-Acid" as a switch, but flooded and AGM lead-acid have different maintenance and discharge realities worth keeping distinct in the type — BatteryChemistry already models that correctly, so the UI just has to not throw it away.

Performance: What "No Ad Bloat" Actually Buys You Here

The content column in the live page carries genuine FAQ and reference material — that's intentional, it's what people are actually searching for ("how many amp hours do I need to power a refrigerator overnight"). The difference from a legacy site isn't less content, it's what's sitting next to that content:

	Typical Solar Calculator Sites	HypeCalc
Ad slots injected into layout	8–15	0
Sticky calculator sidebar	Fights with sticky ad units	Sticky, uncontested
Recalculation on input change	Often a full page reload or server round-trip	Sub-millisecond, `useMemo`-driven
JSON-LD / SEO schema	Present, but loaded behind ad-tech JS	Inlined server-side, zero client cost
Time to first meaningful result	Several seconds, ad-dependent	Instant on interaction

The StickyWrapper around the calculator card isn't fighting a sticky sidebar ad for scroll real estate, because there isn't one. That's the whole trick — a sticky, always-visible calculator is a much better UX than a modal or footer form, but it only works if you're not also trying to stick an ad next to it.

Try It on Real Numbers

The full sizing flow — chemistry-aware DoD, inverter losses, autonomy scaling, live Ah/kWh output — is running in production right now:

HypeCalc Solar Battery Bank Calculator →

Plug in your own daily load and watch the LiFePO4 vs. AGM numbers diverge in real time — it's a genuinely useful way to see why chemistry choice isn't cosmetic.

Discussion

Three things I want this community's take on:

Where do you draw the line on "pure calculation function"? I kept recommendedBatteryCount as a closure on the result rather than a separate exported function — was that the right call, or am I overcomplicating a tiny utility?
Domain-specific calculators live or die on getting the underlying physics right, not just the UI. How much domain research do you do before writing the first line of a calculator/tool like this — and has a subtle domain mistake ever slipped past your tests?
Sticky sidebars vs. inline results — for a content-heavy SEO page like this one, would you keep the calculator sticky in the viewport, or is that pattern getting too common to stand out anymore? Curious where people land — especially if you've built anything in the solar/energy space and hit modeling edge cases I didn't cover here (partial shading, charge controller losses, etc.).

I Kept Wasting $80 Bottles of Epoxy on Bad Math, So I Built a Deep Pour Resin Calculator With Next.js + TypeScript

G S — Tue, 08 Sep 2026 08:55:06 +0000

The $80 Mistake That Started This

I was pouring a river table. Live edge walnut slabs, a resin "river" down the middle, the whole Pinterest-core woodworking project.

I estimated the resin volume by eyeballing it against a five-gallon bucket. I was wrong by almost 40%. Deep pour epoxy isn't cheap — I'm talking $70–$90 per gallon for a real slow-cure formula — and I either had to eat the cost of a wasted batch or scramble to mix a second one mid-pour, which risks a visible seam line in the cured resin forever.

So I went looking for a calculator. What I found was the now-familiar genre of construction-utility site:

A giant hero image of a finished river table, because SEO wants "engagement," not math
1,400 words of blog filler before the actual input fields
A "mix ratio calculator" that only supported one brand's proprietary ratio
No wood displacement handling at all — just raw mold volume, which overestimates resin need by 30–70% depending on your slab coverage
Ads stacked so aggressively the input fields shifted position while I was mid-typing I closed the tab and did what I did with the Stair Calculator a few months back: built the thing properly, myself, with real volumetric chemistry and zero ad noise.

This is the breakdown of the Deep Pour Epoxy Resin Calculator — the actual displacement math, the mix-ratio logic, and the Next.js architecture behind it.

The Problem Legacy Calculators Get Wrong: Wood Isn't Water

Most epoxy calculators treat your mold like an empty box: Length × Width × Depth = resin needed. That's correct for a bare silicone mold. It's badly wrong for a river table, because a huge percentage of that "volume" is actually solid wood slab, not liquid resin.

Skip that correction and you'll either massively overbuy resin, or — worse — underestimate and run out mid-pour on a piece you can't easily top off without a visible cure line.

Here's the full derivation, the way a woodworker actually reasons through it:

1. Gross Mold Volume

Start with the raw container dimensions in inches:

grossVolume = length × width × pourDepth

For a circular mold (a lot of coasters and clock blanks use these):

grossVolume = π × (diameter / 2)² × pourDepth

2. Wood Displacement Subtraction

This is the step every basic calculator skips. River tables have wood slabs occupying a real percentage of the mold — commonly 30–75% depending on how "open" the river channel is:

netVolume = grossVolume × (1 - woodDisplacementPercent / 100)

Skip this and you've computed the volume of an empty mold, not the volume of resin you actually need.

3. The Safety Buffer

Cup residue, mold leveling error, and slab-grain absorption all eat into your poured volume. A 5% buffer is the industry-standard hedge:

bufferedVolume = netVolume × 1.05

4. Unit Conversion

Cubic inches aren't how anyone buys resin. Convert to the units on the bottle:

gallons  = bufferedVolume / 231
fluidOz  = bufferedVolume / 1.80469
liters   = bufferedVolume / 61.0237

5. Mix Ratio Split

Deep pour epoxy is almost always 2:1 (resin:hardener) by volume — very different from the 1:1 ratio used for thin tabletop coats:

partA (resin)    = bufferedVolume × (2 / 3)
partB (hardener) = bufferedVolume × (1 / 3)

Get this ratio wrong and the epoxy either stays permanently tacky or cures cloudy — there's no "close enough" with a two-part chemical reaction.

The TypeScript Core: Same Discipline as the Stair Calculator

Just like the stringer-length math in the stair tool, this logic has zero business living inside a component. It's pure, deterministic, and testable in isolation:

// lib/calculateEpoxyResin.ts

export type MoldShape = "rectangular" | "circular";
export type MixRatio = "2:1" | "1:1";

export interface EpoxyInput {
  shape: MoldShape;
  lengthInches?: number;   // required for rectangular
  widthInches?: number;    // required for rectangular
  diameterInches?: number; // required for circular
  pourDepthInches: number;
  woodDisplacementPercent?: number; // 0 for empty molds, e.g. coasters
  mixRatio?: MixRatio;              // defaults to 2:1 (deep pour standard)
  safetyBufferPercent?: number;     // defaults to 5
}

export interface EpoxyResult {
  grossVolumeCubicInches: number;
  netVolumeCubicInches: number;
  bufferedVolumeCubicInches: number;
  gallons: number;
  fluidOunces: number;
  liters: number;
  partAOunces: number; // resin
  partBOunces: number; // hardener
  isSafeSinglePourDepth: boolean; // true if depth <= 4"
}

const CUBIC_INCHES_PER_GALLON = 231;
const CUBIC_INCHES_PER_FLUID_OZ = 1.80469;
const CUBIC_INCHES_PER_LITER = 61.0237;
const MAX_SAFE_SINGLE_POUR_INCHES = 4;

export function calculateEpoxyResin({
  shape,
  lengthInches,
  widthInches,
  diameterInches,
  pourDepthInches,
  woodDisplacementPercent = 0,
  mixRatio = "2:1",
  safetyBufferPercent = 5,
}: EpoxyInput): EpoxyResult {
  if (pourDepthInches <= 0) {
    throw new Error("Pour depth must be a positive number.");
  }

  const grossVolumeCubicInches =
    shape === "circular"
      ? Math.PI * (diameterInches! / 2) ** 2 * pourDepthInches
      : lengthInches! * widthInches! * pourDepthInches;

  if (!Number.isFinite(grossVolumeCubicInches) || grossVolumeCubicInches <= 0) {
    throw new Error("Invalid mold dimensions.");
  }

  const netVolumeCubicInches =
    grossVolumeCubicInches * (1 - woodDisplacementPercent / 100);

  const bufferedVolumeCubicInches =
    netVolumeCubicInches * (1 + safetyBufferPercent / 100);

  const fluidOunces = bufferedVolumeCubicInches / CUBIC_INCHES_PER_FLUID_OZ;

  const [partRatio, hardenerRatio] =
    mixRatio === "2:1" ? [2, 1] : [1, 1];
  const totalParts = partRatio + hardenerRatio;

  return {
    grossVolumeCubicInches: Number(grossVolumeCubicInches.toFixed(2)),
    netVolumeCubicInches: Number(netVolumeCubicInches.toFixed(2)),
    bufferedVolumeCubicInches: Number(bufferedVolumeCubicInches.toFixed(2)),
    gallons: Number((bufferedVolumeCubicInches / CUBIC_INCHES_PER_GALLON).toFixed(3)),
    fluidOunces: Number(fluidOunces.toFixed(1)),
    liters: Number((bufferedVolumeCubicInches / CUBIC_INCHES_PER_LITER).toFixed(3)),
    partAOunces: Number(((fluidOunces * partRatio) / totalParts).toFixed(1)),
    partBOunces: Number(((fluidOunces * hardenerRatio) / totalParts).toFixed(1)),
    isSafeSinglePourDepth: pourDepthInches <= MAX_SAFE_SINGLE_POUR_INCHES,
  };
}

Same architectural bet as before: the moment a calculation has real-world stakes — money, safety, wasted material — it earns its own pure function, decoupled from render cycles, decoupled from framework churn, unit-testable without mocking a single DOM node.

The Client Component: Instant Feedback, No Debounce Needed

Woodworkers adjusting slab displacement percentage or pour depth need to see the gallon count update as they type — this is a "how much do I need to buy" decision, and hesitation in the UI reads as untrustworthy math.

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

import { useMemo, useState } from "react";
import {
  calculateEpoxyResin,
  type EpoxyResult,
  type MixRatio,
} from "@/lib/calculateEpoxyResin";

export default function CalculatorForm() {
  const [length, setLength] = useState(60);
  const [width, setWidth] = useState(30);
  const [pourDepth, setPourDepth] = useState(2);
  const [woodDisplacement, setWoodDisplacement] = useState(40);
  const [mixRatio, setMixRatio] = useState<MixRatio>("2:1");

  const result: EpoxyResult | null = useMemo(() => {
    try {
      return calculateEpoxyResin({
        shape: "rectangular",
        lengthInches: length,
        widthInches: width,
        pourDepthInches: pourDepth,
        woodDisplacementPercent: woodDisplacement,
        mixRatio,
      });
    } catch {
      return null;
    }
  }, [length, width, pourDepth, woodDisplacement, mixRatio]);

  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">
        <NumberField label="Mold Length (in)" value={length} onChange={setLength} />
        <NumberField label="Mold Width (in)" value={width} onChange={setWidth} />
        <NumberField label="Pour Depth (in)" value={pourDepth} onChange={setPourDepth} />
        <NumberField
          label="Wood Displacement (%)"
          value={woodDisplacement}
          onChange={setWoodDisplacement}
        />
      </div>

      <div className="mt-4">
        <label className="mb-1 block text-sm font-medium text-zinc-600">
          Mix Ratio
        </label>
        <select
          value={mixRatio}
          onChange={(e) => setMixRatio(e.target.value as MixRatio)}
          className="w-full rounded-lg border border-zinc-300 px-3 py-2 text-zinc-900"
        >
          <option value="2:1">2:1 — Deep Pour (standard)</option>
          <option value="1:1">1:1 — Tabletop / Coating</option>
        </select>
      </div>

      {result && (
        <div className="mt-6 space-y-2 rounded-xl bg-indigo-50 p-4">
          <Row label="Resin Needed" value={`${result.gallons} gal (${result.fluidOunces} oz)`} />
          <Row label="Part A (Resin)" value={`${result.partAOunces} oz`} />
          <Row label="Part B (Hardener)" value={`${result.partBOunces} oz`} />
          <div
            className={`mt-2 rounded-lg px-3 py-2 text-sm font-medium ${
              result.isSafeSinglePourDepth
                ? "bg-emerald-100 text-emerald-700"
                : "bg-red-100 text-red-700"
            }`}
          >
            {result.isSafeSinglePourDepth
              ? "✓ Safe for a single deep pour"
              : "⚠ Exceeds 4\" — split into multiple pours"}
          </div>
        </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 text-zinc-900"
      />
    </label>
  );
}

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

Two decisions worth flagging for anyone building similar tools:

try/catch inside useMemo, not form validation gymnastics. Invalid geometry (zero or negative dimensions) throws inside the pure function, and the memo just returns null — no separate error-state machine needed for a two-input-shape calculator.
The compliance warning reuses the exact same pattern as the stair calculator's IRC check. Once you've built one "live safety threshold" indicator, it becomes a reusable mental model — and eventually a shared component — across every calculator in the suite.

The Part Most Case Studies Skip: SEO Architecture That Doesn't Cost Performance

The epoxy calculator page ships three JSON-LD schemas (Breadcrumb, SoftwareApplication, FAQPage) alongside a genuinely long-form content column — formulas, a worked example, a wood-displacement reference table, six FAQ entries mapped 1:1 into schema.

Normally, "SEO content + schema" is exactly what causes the layout bloat and CLS I complained about at the start of this post. The difference here is architectural, not aesthetic:

JSON-LD renders as inert <script> tags, not DOM nodes — zero layout impact, zero render cost, pure crawler signal.
The calculator is sticky-positioned in its own column, so the SEO content scrolling underneath it never shifts the input fields the user is actively typing into.
No content is client-fetched. The FAQ text, the worked example, the formula blocks — all of it is static JSX shipped at build time, not a skeleton-loader waiting on an API call. You can rank for "deep pour epoxy resin to hardener ratio calculator 2 to 1" and keep a 100/100 Lighthouse score — the two goals aren't actually in tension. The tension only shows up when SEO content gets bolted on via injected ad-network widgets instead of authored as first-party static markup.

Try It on a Real Project

Every formula above — displacement subtraction, mix-ratio splitting, the 4" single-pour safety check — is running live, not mocked:

HypeCalc Deep Pour Epoxy Resin Calculator →

Plug in your own river table dimensions. If the gallon number doesn't match what your resin brand's own site tells you, that's a bug report I genuinely want.

Let's Talk

Where's the actual line between "helpful SEO content" and "content that exists purely to push the useful tool below the fold"? I tried to keep every paragraph on this page load-bearing — did I succeed, or is 1,400 words still too many before the input fields?
Should utility calculators like this even carry JSON-LD/schema markup, or does optimizing for search discoverability quietly reintroduce the same incentives that bloated the sites we're all mad at?
What's a calculation in your own field (woodworking, electrical, plumbing, whatever) that every online calculator gets subtly wrong the way generic epoxy calculators ignore wood displacement? I'm collecting ideas for the next tool in the suite.

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?