DEV Community: StarKnight

Waymark: a trail guide you listen to, written by Gemma 4 in your browser

StarKnight — Mon, 05 Oct 2026 22:35:41 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Most trail apps ask you to look at them. At a junction you take the phone out, wake the screen and find the blue dot, and for that moment you are looking at a map instead of the trail. This week's theme asks for builds where the screen is the shortest part of the experience, so I built a trail guide that you listen to.

Waymark turns a real trail into a short spoken guide. You pick a trail, or open a GPX file, and Waymark works out the facts from open data: where the junctions are and which way to go at each one, where the climbs start and how steep they are, where the water, bridges, steps and viewpoints are, and how long the walk should take. Gemma 4 E2B, an open-weight model running inside the browser, writes one or two plain sentences for each of those waymarks and a short briefing for the whole walk.

Before you leave, a 3D model of the real terrain previews the walk in about a minute, with every cue shown where it will be spoken. Then you send the guide to your phone and put the phone in your pocket. Pocket mode keeps the screen dark, follows GPS and speaks each cue when you reach that waymark, for example: "Continue straight onto Mist Trail. John Muir Trail on the right is not your route." On a two-hour walk, you look at the screen for about a minute.

It is for walkers and hikers on trails they do not know well, and for anyone who would rather keep their eyes on the path. A group can share one link.

Demo

Live app: https://starknightt.github.io/waymark/

Things to try:

Pick a demo trail. Mist Trail (Yosemite, USA), Lake Agnes Trail (Banff, Canada), Galu Devi to Triund (Himachal Pradesh, India) and the Pen y Fan and Corn Du circular walk (Wales, UK). Their guides were written by Gemma 4 E2B in Chrome and are saved with the site, so nothing large is downloaded.
Preview the walk. The camera flies along the route and slows at each waymark. Tick "Read the cues aloud" to hear the guide.
Show the facts behind each cue. Each cue then lists the facts it was checked against, and what the checker changed, if anything.
Walk it with your phone. Scan the QR code, then press "Try a simulated walk". It replays the route at eight times walking speed and speaks each cue as the simulated walker reaches it. "Start walk" uses real GPS.
Write a guide yourself. On a desktop with Chrome or Edge, press "Write it again on this device" on any demo trail, or "Make a guide for a trail" to search for a mapped route, paste an OpenStreetMap route link or open a GPX file. The first time, the browser downloads the model (2.0 GB) and keeps it for next time.

The phone view during a simulated walk. Each cue is also shown as text when it is spoken:

Gemma writing a guide for the Triund trail in the browser, with nothing mocked (sped up 2 times):

Each cue next to the facts it came from:

Code

StarKnightt / waymark

A trail guide you listen to. Gemma 4 runs in your browser and writes spoken cues for real trails from open map data.

Waymark

A trail guide you listen to. Pick a real trail. Waymark builds the facts from OpenStreetMap and open elevation data, and Gemma 4 E2B, running in your browser on WebGPU, writes a short spoken cue for every junction, climb and landmark. A 3D model of the real terrain previews the walk in about a minute. Then the phone goes in your pocket: it keeps the screen dark and speaks each cue when you reach that waymark.

Live: https://starknightt.github.io/waymark/

Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 1 (Touch Grass). The repository was started on October 5, 2026, inside the challenge window.

What it does

Four demo trails that open instantly: Mist Trail (Yosemite, USA), Lake Agnes Trail (Banff, Canada), Galu Devi to Triund (Himachal Pradesh, India) and the Pen y Fan and Corn Du circular walk (Wales, UK). Their guides were written by Gemma 4 E2B in Chrome…

View on GitHub

TypeScript, Vite, Three.js and LiteRT-LM, under the MIT license. All of the code was written during the challenge window, starting on October 5.

How I Built It

Facts first, then the model

A spoken guide is worse than useless if it says left when the path goes right, and a 2B model cannot do geometry. So the work is split. Code builds the facts:

Junctions come from the OpenStreetMap path network. Wherever other paths meet the route, Waymark measures the bearing of every branch over about 22 m and decides whether the route turns left or right, keeps left or right at a fork, or continues straight, and which of the other ways are not the route. When two ways leave on the same side, it says which one to take.
Climbs and descents come from open elevation tiles: sections steeper than 7% that gain at least 40 m, with their length, gain, average grade and top elevation.
Landmarks near the path: drinking water, springs, waterfalls, viewpoints, summits, huts, bridges, flights of steps, lakes that come into view, and where the path enters or leaves woodland.
Walking time uses Tobler's hiking function on the elevation profile.

These are merged into waymarks, between 5 and 22 on the twelve test trails, each a short list of facts. The start, the finish and every junction where the route turns or moves onto a different path are marked as required. This is what Gemma sees for one waymark on the Mist Trail, wrapped here to fit:

w8 (REQUIRED): junction: continue straight onto "Mist Trail";
  "John Muir Trail" on the right is not your route

Gemma 4 E2B in the browser

Runtime: the JavaScript API of LiteRT-LM from Google AI Edge, on WebGPU. The model file is gemma-4-E2B-it-web.litertlm (2.0 GB). The browser downloads it once into its private file storage (OPFS), and after that it loads in a few seconds (2.3 s on my PC).
One constrained tool call: write_guide({ cues: [{ waymark, text }], briefing }). The waymark field is an enum of the real waymark IDs, so the model cannot invent a waymark, and constrained decoding guarantees the call can be parsed.
Rules in the prompt: use only the facts listed for that waymark, give directions exactly as written, one or two short sentences, and a cue for every required waymark.
Cost of a guide: about 1,400 prompt tokens and 700 output tokens, 18 seconds on my PC's RTX 4060.

A checker that knows what each number means

Every cue is checked against the facts of its own waymark before it is saved:

Numbers must exist in the facts with the same meaning. The words around a number decide its role: "gains 70 m" is a gain, "topping out at 1,980 m" is an elevation and "the next 450 m" is a length. Numbers written as words, such as "an hour and a half", are checked as well.
Names must exist on the route, including names in other scripts.
Directions must match the junction. A wrong side is swapped, an invented turn is removed, and a turn that went missing is restored from the facts. When a waymark holds two junctions close together, both turns are allowed, in order.
Features: a summit, waterfall or bridge can only be mentioned where the facts mention one.

A sentence that fails is removed. If nothing safe is left, the cue is rebuilt from the facts. The checker has 35 unit cases that run in Chrome, and most of them come from real mistakes.

What went wrong along the way

One call instead of many. My first design asked Gemma to call add_cue once per waymark and set_briefing once. It called set_briefing and stopped, in every test. A single write_guide call with an array fixed it.
Every number was right and the sentence was wrong. "Gain 730 meters in 1.5 km." Both numbers were in the facts: 730 m was the length of the climb and 1.5 km was its distance from the start. A checker that only looks for numbers passed it. That is why numbers now carry a role, and why the prompt no longer includes each waymark's distance from the start.
My first checker was wrong more often than the model. In its first full run over 12 trails it changed 12 cues. Four of those changes were right. Five turned a correct cue into a wrong one: on the Dipsea Trail, two junctions 40 m apart share a waymark ("turn left onto Hazel Avenue, then right onto Hale Lane"), and the checker "corrected" the second turn to match the first. Three more removed correct sentences, such as "Find the Sharma store on your right", rejected because "Find the Sharma" looked like an unknown place. Each of these is now a unit case.
Phrases copied between waymarks. Gemma sometimes repeated "the path straight ahead is not your route" at a junction with no such path. The checker now requires every side path it mentions to be listed in that junction's facts.
Map data needs care. I had mapped OpenStreetMap's wetland areas to water, so the bogs around Pen y Fan were drawn as lakes, and the Merced River's water area produced "a lake comes into view on your right" on the Mist Trail. Forest areas also run over 3,000 m ridges, so the 3D view applies a treeline estimated from latitude.
A colour space bug. THREE.Color converts colours to linear light, so my tree placement compared sRGB pixels with linear values and matched nothing. Every mountain was bare until I read the hex value directly.
Map servers. From my network only one of the three public Overpass servers answered, and slowly. The demo trails are built ahead of time from the OpenStreetMap API, the app tries the three servers in turn, and if none answers it still builds a guide from elevation alone.

Results

Twelve trails in seven countries, Chrome on an RTX 4060 desktop GPU, greedy decoding. The second column asks for the same guide as JSON in plain text, without constrained decoding.

	One constrained tool call (shipped)	JSON in plain text
Cues written by Gemma	180	180
Passed every check unchanged	171	170
Changed by the checker	9 (8 of them on Mount Takao)	10
Required waymarks covered	120 of 120	120 of 120
Output that could not be used	0	0
Time per guide	18.2 s	11.4 s
Decoding speed	44 tokens/s	80 tokens/s

Eight of the nine changes were on Mount Takao, where Gemma translated or romanised Japanese path names, for example "Takao Mountain Line" for 高尾山線. The checker replaced them with the names on the map and kept the turns.

The result I did not expect: Gemma 4 E2B followed the JSON format in plain text on every trail, so constrained decoding mainly bought certainty, at a cost of about 45% of the decoding speed. I kept it, because a guide for a trail nobody has tested must always parse. Most of the accuracy came from the facts and the checker rather than from the decoding method.

Two more checks. On the live site, in a fresh browser, the first guide took about 10 minutes, nearly all of it the 2.0 GB download on my connection; writing the guide itself took about 20 seconds. All 62 cues of the four demo guides were also checked line by line against their source facts during development. After the checker, none of them gives a wrong turn, distance or climb, though a few read awkwardly, such as "There is a bridge, Mist Trail.", where the bridge is mapped as part of the Mist Trail. One mistake the checker cannot see is in a briefing: the Pen y Fan briefing says the walk reaches the summit of Pen y Fan, while the map data puts the summit 250 m from the route.

What it cannot do yet

It is not a navigation or safety device. Carry a map and check conditions.
Writing a guide needs WebGPU and about 2 GB of storage, so in practice a desktop or laptop. Any phone can play the guide.
The cues are only as good as the map. An unmapped junction is missed, and English voices read names in other scripts, such as 高尾山線 on Mount Takao, poorly.
The elevation data has a resolution of roughly 10 to 30 m, so sharp summits read lower than their true height.
On a phone the page has to stay open with the screen awake for GPS and speech to keep working. Waymark keeps the screen dark to save power.

Why Does Open Innovation Matter?

Where you walk, and when, is personal. In January 2018, Strava's public heatmap of its users' activity revealed the locations and patrol routes of military bases. A trail plan says where you will be and when you will be away from home. With an open model running in the browser, the route, the guide and your position never go to an AI provider.

It has to work without signal. Trails are often where coverage fails. The guide is written before you leave and fits in a link of about 1.5 KB, so on the trail the phone needs neither a network nor a model.

I could control how the model writes, not only what I ask it. Constrained decoding with my own schema, where the only valid waymarks are the real ones, and a 12-trail evaluation that I could re-run as often as I liked, at no cost. Most of the mistakes described above were found by those repeated runs. With a paid API I would have run the evaluation less often and found fewer of them.

It is open all the way down. OpenStreetMap data, open elevation tiles, an Apache-2.0 model, an Apache-2.0 runtime and MIT code. Anyone can host Waymark as static files, swap in another model, or adjust the facts for the trails where they live.

The trade-off is a 2.0 GB first download and a desktop GPU to write guides. A larger hosted model would write more varied sentences, but for spoken directions being right matters more than style, and that comes from the facts and the checker, which work the same way with an open model on my own machine.

Prize Categories

Best Use of Gemma. Gemma 4 E2B is the only model in Waymark, and it runs entirely in the browser through LiteRT-LM on WebGPU. It writes every spoken cue and every briefing through a constrained tool call whose schema only allows real waymarks. Every demo guide on the site was written by it, and "Write it again on this device" runs it live.

Thanks for reading. If you try Waymark on a trail near you, I would like to hear how the cues held up.

I built my grandmother a tiny island that keeps track of her day, with Gemma running inside the browser

StarKnight — Sun, 04 Oct 2026 11:15:53 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built this for my grandmother.

Because of her age, she can't remember a lot of things these days, and keeping track of her daily routine, such as when to take which medicine, has become hard for her. I wanted to give her something calm and simple that shows her day and what is left to do.

Little World is a daily routine tracker shown as a small 3D island. You describe the routine in plain English. Gemma, an open model running inside the browser, turns the description into a schedule. Each task appears on the rim of the island at its time of day, and the sun and moon move across the sky with the real clock, so the current time and the next task are visible at a glance.

This is the example routine I used during development. It is made up, not hers:

Thyroid tablet, 50 mcg, when I wake up, on an empty stomach.
Blood pressure tablet, Amlodipine 5 mg, after breakfast.
Metformin 500 mg before lunch and before dinner.
Eye drops in both eyes at 4 PM.
Calcium tablet after dinner, not with the thyroid tablet.
A 20 minute walk at 6 PM.

When a task is due, its marker lights up and a reminder appears. Pressing Done marks it complete. The Ask tab answers questions such as "What's next?" or "Did I take my eye drops?" using only the routine that was entered.

The routine never leaves the device. There is no account, no server and no analytics, and after the first load the app works offline. For something as personal as a medicine list, that was a firm requirement.

Little World is not a medical tool, and the app says so. It only repeats what it was told. When I asked "Can I take calcium with my thyroid tablet?", it answered that it could not see that in its notes and that I should check with a doctor or pharmacist, which is the behavior I wanted.

Showing it to my grandmother

I showed Little World to my grandmother. Her reaction was "oh wow, this is so good". Then she said "you made something for me", and she was genuinely pleased.

Designed for an older user

After that, I focused on making it easier to use for someone her age:

"What do I do now?" A single button opens a full-screen view with one task in very large type, one large "I've done it" button with an undo option, and the next few tasks below. It can be set as the default screen.
Spoken reminders. Reminders can be read aloud with the browser's built-in speech synthesis, so no external voice service is involved. If a task is still not done, the reminder repeats after 20 and 40 minutes.
Setup by a family member. Gemma needs a computer with a capable GPU, but the person using the routine does not. A family member can enter the routine on a computer, select "Send to another device", and share the QR code or link. The routine is encoded in the part of the link after the #, which browsers do not send to a server. Opening the link on a phone or tablet shows the routine and asks for confirmation before using it.
Readability. Larger text throughout, buttons at least 48 pixels tall, labels that stay readable against the daytime sky, and task states written as words ("Now", "Waiting", "Done") rather than shown only by color. A reduced-motion setting turns on automatically when the device requests it.

Demo

Live app: https://starknightt.github.io/little-world/

"Try the demo island" works on any device, including phones. It loads a routine that Gemma already parsed, so nothing is downloaded. From there, "What do I do now?" opens the large view and "Send to another device" shows the QR code.
"Describe my own routine" requires desktop Chrome or another browser with WebGPU. Gemma 2 2B is downloaded once (about 1.4 GB) and stored by the browser. After that it loads in a few seconds and works offline.

The clip below shows the real model with nothing mocked: I enter a routine, Gemma parses it, I review the preview and save it, then ask two questions. The GIF runs at 2.5x speed; the 27-second video runs at 1.25x.

The same routine at night, and on a phone:

Code

StarKnightt / little-world

A daily routine tracker on a small 3D island. Gemma runs in the browser through WebGPU, and nothing leaves the device.

Little World

A daily routine tracker shown as a small 3D island. Describe a routine in plain English ("Thyroid tablet when I wake up, Metformin before lunch and dinner, eye drops at 4 PM"). Gemma, running entirely in the browser, turns it into a validated schedule. Each task is placed on the rim of the island at its time of day, and the sun and moon follow the real clock. Mark a task as done when it is complete. Ask "What's next?" and Gemma answers using only the routine.

Nothing leaves your device. No account, no server, no analytics. After the first load it works offline.

Live: https://starknightt.github.io/little-world/ (open ?demo for the instant demo, no download)

Day	Night	Phone

Big view	Family setup

Not medical advice. Little World only repeats what you told it. It does not know about medicines, doses or interactions, and it is told to send those…

View on GitHub

Built with Vite, TypeScript, Three.js, WebLLM and zod, under the MIT license. All code in the repository was written during the challenge weekend, starting October 4.

How I Built It

Stack

Gemma 2 2B (gemma-2-2b-it-q4f16_1-MLC), Google's open-weight model, quantized to 4 bits.
WebLLM from MLC, which runs the model on the GPU through WebGPU. It runs in a Web Worker so the 3D scene stays responsive while the model is working.
Three.js for the island, with a custom sky shader, bloom and HTML labels that avoid overlapping each other.
zod to validate every routine before it is saved, and vite-plugin-pwa for offline support.

Pipeline

routine text
  → Gemma 2 2B, constrained by a grammar
  → JSON, one object per task: quoted source text, name, dose, time anchor, food rule, icon
  → quote check (plain code)
  → zod validation (one retry if it fails)
  → time anchors converted to clock times
  → editable preview
  → saved routine

Key decisions

1. A grammar instead of asking for JSON. WebLLM can constrain decoding to a grammar. I wrote a small EBNF grammar for the exact routine format with fixed separators, so the model chooses only the content, never the structure. With it, every output in my test set was valid JSON.

2. The model chooses a meaning, and code computes the time. My first version asked Gemma for an hour and a minute, and it often returned 0:00 for "after breakfast". Now the model chooses from a fixed list of anchors (on_waking, after_breakfast, before_lunch, bedtime and a few others), and code converts them to times such as 8:30, 12:30 and 22:00. The model returns a clock time only when the text contains one, such as "at 4 PM". The food rule is derived from the anchor as well, so "before lunch" cannot become "after food".

3. Quote first, then verify. For each task the model must also copy the exact source text into a said field. A short function then checks that quote with regular expressions. If the quote names exactly one time or food rule and the model chose something else, the quote takes precedence. A quote such as "before lunch and before dinner" is split into two tasks, and a dose containing a number that does not appear in the source text is removed. This check produced the largest accuracy improvement, in about 100 lines of code.

Before anything is saved, the user sees a preview in which every time can be edited and every task can be removed. A 2B model will sometimes be wrong, so the person always has the final say.

Questions follow the same principle. Code first computes the facts: what is done, what is waiting and for how long, and what is next. Gemma only phrases those facts as a short answer, and it is instructed not to give medical advice.

Results

I wrote 20 test routines with known correct answers. They cover medicines, insulin, an inhaler, eye drops, plant care, feeding a pet, explicit clock times and descriptive wording such as "the white tablet with breakfast, the pink tablet at bedtime". I scored Gemma on all of them in headless Chrome on my PC's RTX 4060.

Gemma 2 2B	Valid JSON	Correct task count	Correct times	Correct food rule
Free text, no grammar	14/20 (17/20 after one retry)	13/20	38/54	16/21
Grammar, model alone	20/20	n/a	36/54	11/21
Grammar + quote check (shipped)	20/20	17/20	47/54 (87%)	17/21

Download: 1.4 GB, once, in 42 parts. On the live site, the first run including the download took about 7.7 minutes on my connection. After that, loading from the browser cache takes about 4 to 6 seconds.
Speed: about 40 to 55 tokens per second for generation and 500 to 700 tokens per second for reading the prompt. Short routines take 4 to 6 seconds. The six-line example above is 688 tokens in and 330 out, about 8 seconds.
Questions: answers take about 1.5 to 3 seconds.
Offline: on the live site with a fresh browser profile, I downloaded the model, created a routine, disconnected the network and reloaded. The app loaded from its own cache (0.9 MB), Gemma loaded from the browser cache, and a new routine was created in about 12 seconds.
First paint: under one second on the live site at desktop and phone sizes. The CSS is inlined into the page.
Automated checks: a headless test opens the live site at desktop and phone sizes, covers the large view, the share link round trip and a browser without WebGPU, and fails on any console error. All 28 checks pass.

What did not work

Gemma 3 1B was my first choice. At 537 MB it is a much smaller download. In the WebLLM build I used, its sliding-window attention configuration either failed to load or, once forced, produced unusable output. Without the grammar it produced no valid routines in 3 test cases. With the grammar it produced valid JSON for all 5 cases, but none of the 11 times were correct. I switched to Gemma 2 2B, at the cost of a download nearly three times larger.
JSON schema mode looped in early tests. With a plain JSON schema, the small models sometimes generated whitespace until they reached the token limit. The custom grammar with fixed separators avoids this. In the final evaluation, schema mode was also valid for all 20 cases.
Times were the hardest part. Asking for hours and minutes directly produced many wrong times, often midnight. The anchor list plus the quote check brought it to 47 of 54.
The model still misses tasks. In the example routine above, Gemma leaves out the walk. I kept that in the demo deliberately, because it shows why the editable preview matters. During the offline test it also produced a dose of "500 mg" for a Vitamin D tablet whose dose I had not written, which is why the dose rule exists.
A bug in my own regular expressions. I generated part of the quote checker with a script that turned every \b (word boundary) into a literal backspace character. Nothing matched, and accuracy dropped until I found it.
Testing a 1.4 GB model is slow. Each test with a fresh browser profile includes an eight-minute download. A force-closed Chrome once left the model cache half-written, and the app then waited indefinitely while checking the GPU. That check now times out after 3 seconds.
Not every device can run the model. It needs WebGPU with 16-bit float support and a few GB of GPU memory, and I only verified it on my own GPU. Phones get the full app with the demo routine and can open a routine sent from a computer. When the model cannot run, the first screen says so and suggests that option.

Why Does Open Innovation Matter?

A daily routine, especially one with medicines in it, is private. It shows what a person is treated for, how often, and how consistently they keep up. My grandmother should not have to send that to a company's server to get a reminder or an answer to "Did I take the evening one?"

Because Gemma's weights are open, the whole model can run inside the page. The routine, the completed tasks and the questions stay in one browser on one device. There is no API key to leak, no usage bill, and no dependency on a service that could change its terms or shut down. Once loaded, it keeps working without a network connection.

Open weights also meant I could control how the model behaves, not only what I ask it. WebLLM let me constrain decoding with my own grammar, which raised JSON validity from 14 out of 20 to 20 out of 20. I could switch from Gemma 3 1B to Gemma 2 2B with a one-line change when the first did not work, and I could run the 20-case evaluation repeatedly on my own GPU at no cost. With a closed API, I would have been limited to adjusting the prompt.

The trade-off is a 1.4 GB first download and a WebGPU requirement. For a health routine I think that is the right trade, and smaller open models will reduce it further.

Prize Categories

Gemma: Gemma 2 2B runs entirely in the browser through WebLLM and WebGPU and is the core of the app. It turns a plain-language description into the routine and answers questions using only that routine.

I built a 163-page paycheck calculator that costs $0 a month to run

StarKnight — Thu, 02 Jul 2026 07:39:03 +0000

Earlier this month I shipped PayBrackets, a free calculator that tells Americans what they actually keep from their paycheck after federal tax, state tax, and Social Security take their cut. It covers all 50 states plus D.C., it has no database, no backend, no APIs, and my total running cost is the domain.

I want to walk through how it's built, because the interesting part isn't the code. It's how much you can get out of very little code if the data underneath is right.

Why a tax calculator, of all things

Every month, millions of people type things like "75000 after taxes texas" or "25 an hour is how much a year" into Google. I looked at what they find. Mostly it's ten-year-old calculators buried under popups, or freshly generated AI pages where the numbers are confidently wrong.

That gap felt workable for one person. Salaries and taxes are pure math. The rules are public. Nothing about it needs a server, an account system, or content writers. It needs someone to sit down, get the rules right once, and present them clearly.

So the whole plan was: encode the 2026 tax rules properly, build one calculation engine, and let that engine generate every page.

The unglamorous part was the whole ballgame

There's no tax API behind the site. The source of truth is a set of TypeScript files I wrote by hand, encoding the 2026 federal brackets from the IRS, the Social Security wage base from the SSA, and every state's brackets, deductions, exemptions, and phaseouts from Tax Foundation data. It looks like this:

{
  name: "California",
  slug: "california",
  kind: "graduated",
  topRate: 0.133,
  brackets: {
    single: [
      { rate: 0.01, threshold: 0 },
      { rate: 0.02, threshold: 11_079 },
      // ...8 more brackets up to 13.3% at $1M
    ],
  },
  standardDeduction: { single: 5_540, married: 11_080 },
  payrollTaxes: [{ name: "CA SDI", rate: 0.013 }], // uncapped since 2024
}

Doing this for 51 jurisdictions took me a full day, and it was the most valuable day of the project. States are genuinely weird. Maryland's counties add their own income tax on top of the state's. California's disability insurance tax lost its wage cap in 2024, so it applies to every dollar. Connecticut quietly claws back the benefit of its lower brackets once you earn enough. Nine states don't tax wages at all.

If I had modeled states as "one tax rate" like most quick calculators do, every single page would be wrong in a different way. And where I chose not to model something, like those Maryland county rates, the page says so in a visible note instead of pretending.

One engine, checked against reality

The heart of the site is embarrassingly small. Progressive taxes are just a walk over brackets:

export function marginalTax(taxable: number, brackets: Bracket[]): number {
  let tax = 0;
  for (let i = 0; i < brackets.length; i++) {
    const { rate, threshold } = brackets[i];
    if (taxable <= threshold) break;
    const ceiling = i + 1 < brackets.length ? brackets[i + 1].threshold : Infinity;
    tax += rate * (Math.min(taxable, ceiling) - threshold);
  }
  return tax;
}

Around that sits the composition: federal income tax after the standard deduction, Social Security up to the wage cap, Medicare plus the surtax on high earners, optional 401(k) deferrals, then the state layer with all its exceptions.

Before launch I wrote a small check script with hand-verified salaries. It runs the engine against numbers I worked out independently and fails loudly if anything drifts. A typo in a bracket threshold is invisible in a code review. In a paycheck for a specific salary, it screams.

163 pages from one route

The site is Next.js, fully static. All the calculator pages hang off a single dynamic route, and the slugs are literally the questions people search:

export function allProgrammaticSlugs(): string[] {
  return [
    ...STATES.map((s) => `${s.slug}-paycheck-calculator`),      // 51 pages
    ...HOURLY_RATES.map((r) => `${r}-an-hour-is-how-much-a-year`), // 61 pages
    ...SALARY_AMOUNTS.map((a) => `${a}-after-taxes`),           // 35 pages
  ];
}

At build time, each page computes its own numbers. The "$50,000 after taxes" page shows the exact take-home in all 51 jurisdictions. The Texas page shows what no state income tax is actually worth against California at the same salary. No two pages share their content, which is the difference between programmatic pages that help people and the thin templated stuff Google buries.

The build produces 163 static pages in about half a minute, and the interactive calculator runs the same engine in the browser. Your salary never leaves the page, which was important to me. Nobody should upload their income to a stranger's server to learn what they already earn.

The readers that aren't people

A growing share of these questions never reach Google. People ask ChatGPT or Perplexity instead. So the site treats AI crawlers as an audience of their own.

Every page opens with the question stated plainly and a two-sentence answer with real numbers, before any explanation. There's FAQ markup throughout, a methodology page naming every data source, and a robots.txt that explicitly welcomes the OpenAI, Anthropic, and Perplexity crawlers rather than blocking them.

The bet is simple. Assistants quote pages that are structured like clean answers with checkable numbers. If an assistant answers "what's $70k after taxes in Florida" by citing my site, that citation is the new referral traffic.

The launch video is also code

One more thing that amused me. I wanted a proper product video for the launch, the smooth animated kind startups pay studios for. I don't own After Effects, so I built the video in Remotion instead. Every scene is a React component, the dollar figures in the animation come from the same tax engine as the site, and the final MP4 renders from the command line.

There's something satisfying about a project where even the marketing assets compile.

Where it stands

The site has been live for a few weeks. It's indexing, impressions are climbing, and the first ad review is in progress. I deliberately have no revenue story to tell yet, and I'd rather say that than inflate it. Once there are real numbers, good or bad, I'll write the follow-up.

The site is paybrackets.com if you want to poke at it. Happy to go deeper on the tax data modeling, the static generation, or the video in the comments.