DEV Community: owen

Skip Is a Range: Honest Scoring for an Incomplete 100-Item Checklist

owen — Thu, 08 Oct 2026 09:12:16 +0000

In my previous post, I wrote about preserving null in a 1–5 quiz instead of silently turning a skipped statement into zero. The implementation kept answers in React memory and made sharing an explicit user action.

The next checklist created a different version of the same modeling problem.

The Rice Purity Test on KinkWeave has 100 yes/no items. The page is 18+ and some prompts are sensitive, but the engineering question is ordinary: what should the result mean when a person skips an item or has not reached it yet?

The tempting implementation is 100 - yesCount. It is also wrong for an incomplete attempt. With ten unanswered items, that number assumes all ten answers are “No.” The interface would be displaying certainty the data does not contain.

I decided that an incomplete binary checklist should return an interval.

Preserve two kinds of missingness

The answer type has three explicit values:

export type RiceAnswer = 'yes' | 'no' | 'skip';
export type RiceAnswers = Record<number, RiceAnswer>;

An unanswered item is not a fourth stored value. It is an absent key. That distinction lets the interface say whether somebody deliberately chose Skip or simply left an item untouched. Both remain unresolved for scoring, but they are not identical interaction states.

The scoring function counts all four cases and refuses to manufacture a definite score:

export function scoreRice(bank: RiceBank, answers: RiceAnswers) {
  validateRiceBank(bank);

  let yes = 0, no = 0, skipped = 0, unanswered = 0;
  for (const q of bank.questions) {
    const answer = answers[q.id];
    if (answer === 'yes') yes++;
    else if (answer === 'no') no++;
    else if (answer === 'skip') skipped++;
    else unanswered++;
  }

  const unresolved = skipped + unanswered;
  return {
    yes, no, skipped, unanswered, unresolved,
    complete: unresolved === 0,
    score: unresolved === 0 ? 100 - yes : null,
    min: 100 - yes - unresolved,
    max: 100 - yes,
  };
}

The upper bound assumes every unresolved item would be No, so none of them lowers 100 - yes. The lower bound assumes every unresolved item would be Yes, so each one lowers it by one.

For example, suppose one item is Yes, one is No, one is explicitly skipped, and 97 are unanswered. The only honest result is 1–99 / 100. The code does not call either endpoint the score. score stays null, and the share text says the result is incomplete and “not a definite score.”

This is a small type-level choice with a visible product consequence: uncertainty survives all the way to the UI.

Reset should restore absence

Changing an answer introduces another easy bug. If Reset assigns No, the control looks cleared while the score still contains an invented answer.

The reducer instead deletes the key. The same reducer also invalidates the current result and any prepared share state whenever an answer changes:

case 'answer': {
  const answers = { ...state.answers };
  if (action.value === 'unanswered') delete answers[action.id];
  else answers[action.id] = action.value;

  return {
    ...state,
    answers,
    phase: 'questions',
    sharePreview: false,
    shareConfirmed: false,
    copyStatus: 'idle',
    revision: state.revision + 1,
  };
}

That revision counter handles a less obvious race. Copying to the clipboard is asynchronous. A person can start a copy, change an answer, and then receive the old promise callback. The reducer accepts copied and copy-failed only when the callback revision still matches the current state, the result screen is active, the share preview is open, confirmation is still present, and a copy is actually in flight.

So a late callback cannot label a changed result as copied. Sharing also requires a preview followed by explicit confirmation; it is not a one-click side effect of viewing the result.

Validate the content contract at both boundaries

A score is only comparable when the input bank has the expected shape and edition. The validator requires exactly 100 questions, IDs 1 through 100 in order, non-empty reviewed text, and no duplicate text after trimming, whitespace normalization, and lowercasing. It also distinguishes the development fixture from the reviewed traditional bank.

if (!Array.isArray(bank.questions) || bank.questions.length !== 100) {
  throw new Error('Unreviewed or unsupported question bank');
}

const texts = new Set<string>();
for (const [index, q] of bank.questions.entries()) {
  if (q.id !== index + 1 || !q.text.trim()) {
    throw new Error('Invalid question manifest');
  }
  const text = q.text.trim().replace(/\s+/g, ' ').toLowerCase();
  if (texts.has(text)) throw new Error('Duplicate question');
  texts.add(text);
}

The server-side loader validates the installed JSON and checks its pinned version and scoring mode. The API returns that fixed bank with private, no-store caching. The client validates the response again and accepts only the expected traditional edition and version. This is deliberate duplication: the server protects deployment integrity, while the client protects the state transition that begins an attempt.

Clearing during load is a state transition, not just a button

The question bank is fetched only after Start. That creates another race: a person can click Cancel loading or Clear while the request is in flight. Aborting the request is useful, but I did not make correctness depend on abort winning the race.

const request = useRef<AbortController | null>(null);
const generation = useRef(0);

const clear = useCallback(() => {
  generation.current++;
  request.current?.abort();
  request.current = null;
  setLoading(false);
  setError(false);
  analyticsCtl.clearAttempt();
  rawDispatch({ type: 'clear' });
}, [analyticsCtl]);

const controller = new AbortController();
request.current = controller;
const currentGeneration = generation.current;
const response = await fetch('/api/rice-questions', {
  cache: 'no-store',
  signal: controller.signal,
});

const bank: unknown = await response.json();
validateRiceBank(bank);
if (currentGeneration === generation.current) {
  rawDispatch({ type: 'start', bank });
}

Clear increments a generation and aborts the active controller. Even if a response has already crossed the network boundary, its captured generation is stale, so it cannot repopulate the cleared session.

The same principle appears in the event journal. Events come from a closed allowlist, contain only the event name, test identifier, and bank version, and are recorded at most once per attempt. There are no answer IDs, timings, or counts in those event objects. An incomplete result view also does not become a completion event.

Tests should attack the uncertainty

The most valuable tests are not only the happy endpoints of 100 and 0. They assert that an empty attempt returns 0–100 with score: null; a mixed partial attempt returns the expected range; Reset removes the key; and an old clipboard revision cannot emit a successful copy event.

Those tests encode the product promise more directly than a snapshot can: missing data remains missing, and stale asynchronous work cannot rewrite the meaning of the current state.

The broader lesson for me is that incomplete input is not an error to hide. Sometimes it is the most accurate state the application has. On a binary checklist, preserving that state means returning bounds instead of pretending to know a point.

Where else have you found that a range, set, or explicit unknown was a better result than a convenient single number?

How I built six self-discovery quizzes around a Next.js registry

owen — Thu, 08 Oct 2026 08:16:07 +0000

Loretypes is a small site with six self-discovery quizzes: Aura Color, Archetype, Moral Alignment, Past Life, Color Season, and Spirit Animal. They're meant for self-reflection and fun, not diagnosis. Past Life is openly fictional storytelling, and Color Season asks which color combinations you enjoy rather than looking at your face or skin.

From an engineering point of view, the interesting part is that the six quizzes share most of their plumbing (routing, submission, storage, share links, images, SEO) while their scoring rules and result screens differ. The Archetype quiz scores bipolar dimensions; the Aura quiz sums answers across seven energy dimensions and maps them to one of eight colors, with White as the result when they're balanced. This post walks through how the codebase holds those together, and where the shared abstraction deliberately stops.

One registry, many routes

Everything starts in lib/tests/registry.ts:

export const testRegistry = [
  auraColorDefinition,
  archetypeDefinition,
  moralAlignmentDefinition,
  pastLifeDefinition,
  colorSeasonDefinition,
  spiritAnimalDefinition,
] as const satisfies readonly TestDefinition[];

validateRegistry([...testRegistry]);

export function getTestByCluster(cluster: string): TestDefinition | undefined {
  return testRegistry.find((definition) => definition.cluster === cluster);
}

Each definition lives in lib/tests/definitions/ and implements the TestDefinition interface from lib/tests/types.ts: questions, answer scale, scoring configuration, result types, SEO copy, theme tokens, a visualization id, an OG template id, a version, and a key for saving drafts in the browser. A quiz has two identifiers: a slug used by the API and storage, and a cluster used in URLs. They can differ: Moral Alignment's slug is moral-alignment, while its URL is /alignment/.

validateRegistry runs when the module loads, so a bad definition fails early. It rejects reserved route segments, duplicate slugs, and route segments that collide across quizzes.

The App Router pages are thin consumers of that registry. The quiz landing page at app/[cluster]/page.tsx enumerates its routes straight from it:

export function generateStaticParams() {
  return testRegistry.map((definition) => ({ cluster: definition.cluster }));
}

export const dynamicParams = false;

The same definition supplies that page's metadata and its FAQ structured data. The saved-result page uses it to resolve result copy, and the image route uses its OG template id to pick a renderer.

That said, this isn't "drop in a config file and get a new quiz." Definitions contain functions (for example mapVisualizationScores), and the landing page explicitly branches into a specialized React experience per quiz. The registry connects content and infrastructure; it doesn't remove quiz-specific UI work.

One runner, scoring on the server

All six quiz experiences render the same QuizRunner component (components/quiz/quiz-runner.tsx). When you answer the last question, it posts only the answer array:

const response = await fetch(`/api/tests/${definition.slug}/results/`, {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: JSON.stringify({ answers: finalAnswers }),
  signal: controller.signal,
});

The handler in app/api/tests/[slug]/results/route.ts caps the body at 4 KB, applies a rate limit to result creation, looks up the definition by slug, and then calls processSubmission. The browser never tells the server which result it got. validateSubmission checks that answers is an array of exactly questionCount integers within the quiz's allowed range, and the server computes the result itself.

Scoring dispatch is a small strategy table in lib/scoring/engine.ts:

export function scoreAnswers(definition: TestDefinition, answers: number[]): ResultPayload {
  const runner = strategyRegistry[definition.scoring.type];
  if (!runner) {
    throw new Error(`Scoring strategy is not implemented: ${definition.scoring.type}`);
  }
  return runner(definition, answers);
}

Four strategies are implemented: dimensional sum, bipolar dimensions, an alignment axis grid, and a seasonal profile. The strategy table is typed as a Partial record, which is honest: one strategy name in the type union (weighted-type) has no runner yet, and the engine throws instead of guessing.

The alignment strategy shows how simple the arithmetic can be. In lib/scoring/strategies/axis-grid.ts, each 1–5 answer is centered on 3 and multiplied by the question's direction:

// Simplified: the question-kind check is omitted.
definition.questions.forEach((question, index) => {
  const contribution = (answers[index] - 3) * question.direction;
  if (question.axis === "lawChaos") lawChaos += contribution;
  else goodEvil += contribution;
});
const cell = cellFromAxes(lawChaos, goodEvil);

Dimensional scoring works differently. It sums answers per dimension, breaks ties by a configured order, and can return a "balanced" result when the spread between dimensions is small. The quizzes share an endpoint, not a formula.

A share link points to a stored, versioned result

After scoring, saveResultWithRetry in lib/results.ts stores a record with a 12-character lowercase alphanumeric share id (nanoid with a custom alphabet), plus the test slug, test version, scored payload, creation time, and an expiry that new records set to null. The raw answer array isn't part of that record.

On an id collision, the save loop tries a fresh id, up to five attempts, and rethrows any other storage error. The store, id factory, and clock are all injectable, which matters for testing (more below).

Storing the version is only useful if reads respect it. lib/tests/result-version.ts maps a stored record back to the definition it was scored with. Archetype keeps an explicit archived 0.2.0 definition, so old results keep rendering with the copy and types they were created with. A small read-only adapter also translates an older payload shape into the current field names, without rewriting the stored data:

// Explicit archive, never a fallback to whichever definition is current.
const archetypeVersions: Record<string, TestDefinition> = { "0.2.0": v020 };

Not every quiz has a frozen archive yet. Alignment, Past Life, and Color Season have explicit version maps, Spirit Animal accepts only its current version, and Aura falls through to the current definition. The point is that each quiz has an explicit read policy, rather than a version field nobody checks.

The result page, app/[cluster]/r/[shareId]/page.tsx, validates the id format, loads the record, resolves the definition for its version, and picks the right result component. An unknown id or incompatible version ends in a 404.

Static pages, dynamic results, and metadata

Content routes are statically generated. The landing page, the detail index and type pages, and the learn articles all export generateStaticParams derived from the registry, with dynamicParams = false, so unknown slugs 404 instead of rendering on demand. The parameter lists aren't a blind cross product. A definition can turn detail pages off with detailPages: false, and Past Life currently has no type pages or learn articles.

Saved results are the opposite: there can be any number of them, so the result page looks records up by id rather than enumerating them. The result image and poster routes declare runtime = "nodejs" and dynamic = "force-dynamic", and so does the sitemap.

Metadata is centralized in lib/seo/metadata.ts, which builds titles, descriptions, canonical URLs, Open Graph, and Twitter cards. Landing pages and articles point at pre-rendered static images. Result pages get a per-result image and are deliberately kept out of the index:

return {
  title,
  description,
  alternates: { canonical },
  robots: { index: false, follow: true },
  openGraph: { title, description, url: canonical, images: [image] },
  twitter: { card: "summary_large_image", title, description, images: [image] },
};

The sitemap is built from indexableClusterPaths, which leaves out individual results and filters Archetype type pages through a content-quality gate. robots.ts allows crawling and points to the sitemap. Indexing is then controlled per page: crawlers can follow a result link, but results don't compete with the content pages in search.

Share images are rendered on demand

Each result has an OG image at /[cluster]/og/[shareId].png. The route delegates to resultImageResponse in lib/result-image-route.ts, which validates the id, loads the record, resolves its versioned definition, and picks a renderer from lib/result-image/index.ts using the definition's OG template id. The renderers use ImageResponse from next/og.

A successful render returns a PNG with Cache-Control: public, max-age=31536000, immutable, which is safe because a stored result is never updated (the store interface only has create and find). A render failure returns a 500 with no-store, so a broken image doesn't get cached for a year. Nothing is written to storage; the PNG is regenerated from the saved payload when a cache misses it.

Posters are a separate, opt-in capability. Past Life has no poster. Aura renders a 1200×630 OG image, a 1080×1080 square poster, and a 1080×1920 story poster. Archetype and Alignment currently use one square layout for both poster routes.

Share buttons build their URLs with a tiny helper in lib/share-url.ts, which strips any query or hash and adds a channel marker:

export function buildShareUrl(origin: string, pathname: string, channel: ShareChannel) {
  const cleanPathname = pathname.split(/[?#]/, 1)[0];
  const url = new URL(cleanPathname, origin);
  url.searchParams.set("s", channel);
  return url.toString();
}

612 tests, mostly about contracts

The suite runs on Vitest. At the time of writing it's 72 test files and 612 tests. vitest.config.mts defaults to the Node environment. The files that need a DOM opt in with a // @vitest-environment jsdom comment at the top.

A few patterns do most of the work:

Registry tests build deliberately invalid definitions (reserved segments, duplicate slugs, colliding routes, inconsistent SEO) and assert that validateRegistry throws.
Persistence tests inject a fake store that throws duplicate-id errors, to check both "succeeds on a later attempt" and "gives up after five."
Server components rendered to strings. About a dozen test files await an async server component directly, pass the tree to renderToStaticMarkup, and assert on headings, links, accessible table markup, and JSON-LD, without a browser.
Golden HTML fixtures in tests/__fixtures__/. The homepage test renders <HomePage /> and compares the result with toBe against home-portal.html, byte for byte. The aura learn-article tests compare against their fixtures after stripping the shared footer, and separately assert one specific cross-link paragraph.

Two lessons

A version field needs a read policy. Writing testVersion into every record is easy. The hard part is deciding what happens when an old record is read after the copy or result types change. For Archetype, that meant keeping an explicit archive of the old definition and a read-only adapter for an earlier payload shape. Making the policy explicit per quiz (archive, exact match, or "current is fine") has been more useful than pretending every quiz is equally frozen.

Byte-for-byte fixtures are noisy on purpose. The homepage fixture fails on any markup change, including a new footer link. That sounds annoying, but it turns "did this change anything else on the page?" into a diff you review. When the change is intended, you regenerate the fixture in the same commit and the diff shows exactly what moved. For pages where only part of the markup matters, like the learn articles, stripping the shared footer first keeps the fixture focused on the content it's meant to protect.

I used AI assistance to help draft this post; the code and project are my own.

Building a quiz result page that refuses to be one label

owen — Sat, 19 Sep 2026 07:16:05 +0000

Most personality quizzes collapse you into a stamp, then hide the rest behind an email wall. I wanted the opposite: a short test, a complete result with no
account, and a page that still shows the scores around the leader.
That site is Loretypes. The homepage line is the product decision: your whole pattern, not one label.

What you can try

Three quizzes, 21–24 questions each:

Aura Color — eight colors, neighboring scores stay on the spectrum
Archetype — a leading type plus a supporting type
Moral Alignment — a nine-part chart and both axes If "aura" sounds like nonsense, start at Moral Alignment. Same scoring rules, no mysticism.

The result is the product

The interesting part is not the questions. It is what happens after submit.
The browser does not compute a type. It posts an answers array. The server validates length and range, runs one scoring strategy for that quiz, and stores the
payload. The client only gets a 12-character shareId.

  export const SHARE_ID_ALPHABET = "abcdefghijklmnopqrstuvwxyz0123456789";
  export const SHARE_ID_LENGTH = 12;


http
  POST /api/tests/aura-color/results/
  Content-Type: application/json

  { "answers": [/ 21 integers, 1-5 /] }

  → 201 { "shareId": "xxxxxxxxxxxx" }

  Same answers on a phone and a laptop have to match. That is why scoring is server-side. Share links are `/aura/r/{shareId}/` (and the same shape for the other
  quizzes). OG images are generated from the stored payload, so the preview is the reading you just got, not a generic card.
  Results do not expire. A shared link should still resolve later.
  ![Aura result with the full color spectrum visible](https://loretypes.com/aura/og/egorpo1ezeih.png)
  There are three scoring strategies behind that one POST:
  - `dimensional-sum` for Aura
  - `bipolar-dimensional` for Archetype
  - `axis-grid` for Alignment
  Each quiz has one published method. The result page is allowed to name a leader. It is not allowed to pretend the leader is the whole person.

## What I left out of the default path
  After Archetype, you can optionally generate a short reflection for a situation (teamwork, an ordinary day). It stays off until you ask. Original answers are
  not sent. The text is not written into the share URL. If that request fails, the scored result is still there.
  The about page says this is reflection, not an assessment. I would rather over-say that than dress a quiz up as science.
  Stack is ordinary: Next.js App Router, Postgres for results, Redis for create-result rate limits.

## What I want criticism on
  - Three quizzes on the home page: clear, or three products pretending to be one?
  - 21–24 items: already too long for a no-signup quiz?
  - Does the result page still feel like a stamp even with neighboring scores visible?
  - Should the optional reflection exist at all?
  [Try it](https://loretypes.com). No account. The full result is the point.

Skip is not zero: scoring a private quiz without a database

owen — Sat, 19 Sep 2026 07:14:08 +0000

I built a 30-question preference quiz for consenting adults. The product constraint was sharper than the topic: answers should not outlive the tab.
No account. No result URL. No localStorage. Refresh or close the tab, and the map is gone.
That sounds like a privacy-policy sentence. It is actually a state-management problem. This is how KinkWeave is wired.

What we refused to do

A lot of quizzes persist by accident:

Scores encoded in the query string, so the result is a shareable, indexable document
localStorage, so a shared laptop keeps last night’s answers
A “resume later” cookie that becomes a user record
Treating “skip” as 0, so silence looks like dislike We wanted a map someone could look at, copy by choice, and then destroy by closing a tab. The quiz still has to survive in-app navigation. Privacy, Terms, and the result page all need the same answers. A hard reset on every route change would make the product unusable.

One provider, memory only

The app is Next.js App Router. A client provider wraps the tree. Answers live in a reducer. Scoring is a useMemo over that state.

  const result = useMemo(() => {
    if (!state.completed || !state.questions) return null;
    try {
      return scoreQuiz(state.questions, state.answers);
    } catch {
      return null;
    }
  }, [state.completed, state.questions, state.answers]);

sessionStorage holds one boolean: the 18+ confirmation. It does not hold answers, scores, or a result name.
That split is load-bearing. Age confirmation should last for the browser session, or people get gated again on every internal link. Preference data should not.
If storage is blocked, the quiz errors on the age check and still does not fall back to writing answers somewhere else.
Same-tab routing keeps the provider alive, so Privacy and Terms do not wipe progress. A refresh unmounts the tree. That is the delete button.

Skip is `null`, not `0`

Each question is a 1–5 rating or an explicit skip.

  type Answer = 1 | 2 | 3 | 4 | 5 | null;

null means “this item is not in the math.” It is not a low score.
There are six axes and five questions each. An axis only gets a number when at least four answers are scored:

  score = round(100 * (sum - n) / (4 * n))

n is the count of scored answers on that axis. Skips are excluded from both sum and n. All 1s map to 0. All 5s map to 100. Fewer than four scored answers
→ score = null, and the result is a partial map. Missing scores are not drawn as zero on the radar.
“Unsure” is the scale midpoint (3) for arithmetic. A row of Unsure answers therefore lands on 50. The UI has to say that out loud, or people read 50 as
moderate interest. The number and the coverage line have to travel together: how many answered, how many skipped, how many Unsure.
If you ship any instrument with an optional item, decide this before you write the first reducer. The bug is not the formula. The bug is letting undefined
collapse into 0 because it is easier to chart.

Two axes, not one slider

Leadership and Surrender are separate. A high score on one does not subtract from the other.
That is a product rule, but it is also a data-model rule. A bipolar “dominant ↔ submissive” scale is simpler to plot and worse to answer. People can want both,
want neither, or want one today and not the other. Independent axes make the radar honest; they also make “highest axis wins” a weak identity label.
We only name a pattern when:

all six scores exist
one axis is uniquely highest
that high score is at least 60
the spread from min to max is at least 15 Otherwise the result is an Open Sketch. Ties, mild scores, and flat maps should not mint a personality type. The thresholds are editorial, not norms. The copy has to say that, or the chart will overclaim. ## Sharing without a result document The obvious “private but shareable” trick is to stuff scores into the URL. Then the link is the database. We do not do that. The public quiz link opens the introduction, not a stored result. It carries no scores and no tracking parameters. If someone wants a copy, they choose it: a text note with the summary and axis scores, or an image generated in the browser. Raw answers never go into that export. Once the note is on the clipboard or a PNG is on disk, it is outside the page. Closing the tab cannot unsay it. The UI has to say that before the copy button, not in a footer. ## What still leaves the machine “Nothing is stored” is a lie if you ignore infrastructure. The browser still requests pages, fonts, and the question bank. That quiz request has no answers. Hosting logs can still show that /api/questions was hit. Optional analytics, if the person allows it, measures start / progress / completion with fixed labels — not answers, not scores, not result names. Be precise in the privacy page. “Answers stay in this tab” is true. “The website has no logs” is not.

What I would repeat

Put the retention rule in the state shape. If skip is null, every scorer, chart, and export has to understand null.
Do not use the URL as a database for sensitive results. Shareable links are just public records with extra steps.
Keep session UX and preference data on different storage. Age-gate in sessionStorage; answers in memory.
Say what a middle score is. Midpoint math plus missing data will otherwise invent a personality. If you want to see the constraints in the UI, the quiz is at kinkweave.com. I am more interested in how other people model “prefer not to answer” than in whether the radar looks nice. How do you keep skip / unknown / unset from turning into zero in your own scoring code?

I built a tool that turns aurora data into a single decision: GO, MAYBE, or NO

owen — Fri, 28 Aug 2026 03:47:14 +0000

Every time a geomagnetic storm makes the news, the same thing happens in my household: someone asks "can we see the northern lights tonight?", and I open three tabs — a Kp index chart, a cloud forecast, and a light pollution map — and still can't give a straight answer.

The existing aurora tools are built by and for space-weather people. They show you the raw data: planetary K-index, aurora oval plots, solar wind speed. That's great if you know what "Bz = -12 nT" means for your driveway. Most people don't. Some sites go the other way and print invented precision like "73% chance of aurora tonight" — a number nobody can honestly produce.

So I built Aurora Tonight (aurora-tonight.com): enter your city or ZIP, get one of four answers — GO, MAYBE, NO, or UNKNOWN — plus the best viewing window, the main obstacle in plain language, and which direction to look.

The stack

Nothing exotic, and that was the point:

Next.js on Vercel. Forecast pages are served via ISR — the answer for a given city only changes as fast as the upstream data does, so per-request rendering was just burning invocations for identical bytes.
NOAA's aurora oval data for geomagnetic activity. This is the authoritative public source; I deliberately don't layer a proprietary "prediction" on top of it.
Open-Meteo for cloud cover snapshots. Clouds are the #1 reason a strong geomagnetic night is still a NO, and most aurora sites ignore them entirely.
Darkness, moonlight, and light pollution are computed or looked up server-side. Everything is cached at the edge; the whole site is static-ish and free to run, which is why the tool can be free with no signup.

The interesting design decision: what not to compute

The hardest part wasn't the data pipeline — it was deciding the output contract. Three rules I ended up with:

No fake percentages. The model's output is a categorical call, not a probability. If you can't defend "73%", don't print it. GO / MAYBE / NO maps to what a person actually does with the answer.
UNKNOWN is a first-class state. If the cached data snapshot is stale, the page says UNKNOWN instead of extrapolating a confident-looking guess from old data. This costs us some "always has an answer" slickness, and it's worth it.
The main obstacle is part of the answer. "NO" alone is useless. "NO — overcast until after 1am" tells you whether to set an alarm.

I wrote up the full scoring logic on the methodology page if you're curious how the calls are made — it documents exactly what goes into a GO versus a MAYBE.

Current scope and honest limitations

It covers 15+ indexed US states and cities — Fairbanks and Alaska down through mid-latitude places like Colorado, Ohio, and Chicago, where aurora is a rare-event question rather than a nightly one. Northern hemisphere, mid-to-high latitudes only. It won't tell you anything useful in Texas, and it says so.

If you're building anything in the "raw public data → plain-language decision" space, I'd genuinely like to hear how you handled the honesty-vs-slickness tradeoff. The temptation to print a number that looks more confident than the data deserves is real.

I built a roof calculator that does all the math in your browser — no server, no signup, no lead form

owen — Fri, 28 Aug 2026 02:49:17 +0000

Nearly every "roofing calculator" on the internet is a contractor lead form in disguise. You type in your measurements, hit calculate, and the answer is locked until you hand over your phone number. The math was never the product — your contact info was.

I'm a developer, not a roofer, but I wanted to see what happens if you build the opposite: PitchCalc, five roof-math calculators where the answer shows up in about ten seconds, all computation happens locally in your browser, and there is no backend to store anything.

The actual math is one triangle

Everything in residential roofing reduces to one right triangle: rise over run. The whole engine is a handful of lines:

const ratio = rise / run;

const pitch = `${rise}/12`;                        // X:12 notation (run is usually 12")
const degrees = Math.atan(ratio) * 180 / Math.PI;  // 6/12 → 26.6°
const slopePercent = ratio * 100;                  // 6/12 → 50%
const multiplier = Math.sqrt(1 + ratio * ratio);   // 6/12 → 1.118
const rafterLength = Math.sqrt(run ** 2 + rise ** 2);

From there it's just unit conventions:

Sloped roof area = footprint × multiplier
Roofing squares = area ÷ 100 (a "square" is 100 sq ft, the unit shingles are sold in)
Shingle bundles = ceil(squares × 3 × (1 + waste)) — three bundles per square, typically 10% waste

Five pages, one shared engine: roof pitch, roofing (area/squares/bundles), roof area, rafter, and shingles.

Local-first as a feature, not a limitation

The page says "Measurements stay in this browser" and means it literally: there is no database, no account system, no analytics event carrying your inputs anywhere. Results recompute on every keystroke, so there's no submit button at all.

One detail I like: the input state lives in the URL hash, so a calculation is shareable as a plain link — pitchcalc.com/#rise=6&run=12 opens with a 6/12 pitch preloaded. No encoding endpoint, no shortened URLs, just location.hash.

Trust through visible formulas

Every result panel prints the formula next to the number — √(1 + (rise ÷ run)²) right beside the multiplier value. If you don't trust the output you can check it with a pencil. That's also why the copy button produces something that reads like a takeoff sheet: the audience is a homeowner about to talk to a contractor, or an estimator checking numbers from a truck. The output had to survive being read aloud.

Stack notes

Next.js, fully static — the whole site is pre-rendered pages plus a small client-side engine
No form libraries or state management; controlled inputs and derived values
Print stylesheet treats the result panel as the document, not the page chrome

What I'd add next

Waste factors per roof complexity, valleys/hips geometry, metric units. If you do roof math by hand for something else, tell me in the comments — genuinely collecting the backlog.

Try it: pitchcalc.com — free, no signup, and it will never ask for your phone number.

There's no superscript "q" in Unicode — and other things I learned building a superscript generator

owen — Thu, 27 Aug 2026 09:16:55 +0000

Quick quiz: how do you write "x² + y³" in plain text, no HTML, no LaTeX?

 Easy, right? `²` and `³` are just characters. Now write "E = mcᵠ" — wait, that should be a superscript "q". Try to find it. I'll wait.

 You won't, because **Unicode has no superscript q**. When I built a [free superscript converter](https://literalkit.com/superscript-generator), this turned out to be the tip of

a very weird iceberg. Here's what I learned.

Superscripts aren't formatting — they're separate characters

 Most people assume superscript works like bold: take a character, apply a style. That's how `<sup>` works in HTML, and how rich text editors work.

 Unicode plain text doesn't have styles. Instead, every superscript character is its own pre-composed codepoint, donated to the standard by different communities at different

times:

 - `¹²³` live in **Latin-1 Supplement** (U+00B9, U+00B2, U+00B3) — they've been there since the 1980s.
 - `⁰ ⁴-⁹ ⁺ ⁻ ⁽ ⁾` live in the **Superscripts and Subscripts** block (U+2070–U+209F).
 - Superscript *letters* are scattered across **Phonetic Extensions** (U+1D2C–U+1D7F), because linguists needed them for phonetic transcription: `ᵃ ᵇ ᶜ ᵈ ᵉ ᶠ ᵍ ʰ ...`
 - And a few stragglers like `ˣ` (U+02E3) hide in **Spacing Modifier Letters**.

 So "convert text to superscript" really means "look up each character in a hand-built mapping table someone assembled from four different corners of the standard." There's no

algorithm. It's a scavenger hunt.

The honest-output problem

 Here's where it gets philosophically interesting. The mapping has holes:

 - **No superscript `q`.** It's the famous gap. Proposals exist, but as of today there's no official codepoint.
 - **Uppercase letters are incomplete** — you get `ᴬ ᴮ ᴰ ᴱ ᴳ ᴴ ᴵ ᴶ ᴷ ᴸ ᴹ ᴺ ᴼ ᴾ ᴿ ᵀ ᵁ ⱽ ᵂ`, but try spelling a full sentence in superscript caps and you'll hit walls fast.
 - Subscripts are even sparser: `ₐ ₑ ₕ ᵢ ⱼ ₖ ₗ ₘ ₙ ₒ ₚ ᵣ ₛ ₜ ᵤ ᵥ ₓ` — that's most of what exists.

 Most converters on the web quietly patch the holes with **lookalike characters** — a Greek letter here, a math alphanumeric symbol there. The output *looks* fine until someone

copies it into a screen reader, a search box, or a font that renders the substitute as tofu (□).

 I made a different call: when a character has no real superscript, the tool says so instead of faking it. It feels worse in the demo and better in real life — what you copy is

what you meant.

Styling plain text that survives copy-paste: a Unicode primer (and the tools I use)

owen — Wed, 05 Aug 2026 02:00:34 +0000

The problem: there is no "bold" in a bio

Here's a scenario you've probably hit: you want to emphasize something in an
Instagram bio, a Discord nickname, a Slack message, or a plain-text README —
and there's no formatting toolbar. No bold, no italic, no superscript button.

The reason is simple: these fields store plain text. Formatting isn't
data; it's a rendering layer applied by a rich-text editor. Take the editor
away and the formatting never existed.

The workaround that does travel with the text is Unicode.

Unicode already contains "styled" characters

Unicode isn't just a bigger ASCII. It includes entire blocks of letter
variants — most notably the Mathematical Alphanumeric Symbols block
(U+1D400–U+1D7FF), which encodes bold, italic, script, fraktur, double-struck,
monospace, and more as distinct characters:

x → 𝐱 (bold), 𝑥 (italic), 𝚡 (monospace)
A → 𝔸 (double-struck), 𝔄 (fraktur)
2 → ² (superscript, from a much older block)

Because these are real characters with their own codepoints, they survive
copy-paste into any plain-text field. That's the whole trick behind "font
generator" sites — no fonts are involved, just a codepoint lookup.

The catch: honest vs. fake conversion

There's a subtle quality problem most converters have. Coverage is uneven:
superscript has no lowercase b (Unicode simply never encoded one), italic
has no capital Q, and so on.

Many tools quietly paper over the gaps by borrowing lookalike characters
from unrelated scripts — a Greek letter here, a Cyrillic one there. It looks
fine until screen readers mangle it, search can't find it, or a font renders
it as tofu. A good converter instead:

converts what has a real mapping,
leaves the rest untouched,
and tells you which characters stayed unchanged.

The tools I settled on

I got tired of hand-searching codepoint tables, so I now use
LiteralKit — a free collection of 50+ focused
Unicode tools. Three things make it work for me as a developer:

Everything runs locally in the browser. No accounts, no uploads — your
text never leaves the page. Paste, convert, copy, done in seconds.

Honest output. It never substitutes lookalike characters. Unsupported
characters pass through unchanged, and the page discloses its coverage up
front. For a notation tool, that honesty matters more than a big feature list.

One tool per page, one job per tool. No popups, no multi-step funnels.
A few I keep bookmarked:

Superscript Generator — x², footnote-style notation for plain-text docs and READMEs
Fancy Text Generator — italic/bold/script/monospace Unicode styles for bios and profiles
Case Converter — boring, but I reach for it weekly

The full set (Wingdings and runic translators, symbol pickers, a symbol
identifier, and more) lives in the tool directory.

Takeaway

Styled plain text is just Unicode arithmetic — but doing that arithmetic by
hand is a waste of your time. Know the trick exists, know that coverage has
honest gaps, and let a tool that respects those gaps do the mapping.