DEV Community: Isaiah Kim

Soft Money Journal, Still Mornings, Using It Up and Why Your Brain Does That

Isaiah Kim — Mon, 07 Sep 2026 23:06:03 +0000

People can open four archives here, each keeping a different kind of everyday record.

Four archives

These pages turn short films and videos into written archives. Readers get journal entries, morning readings, inventories, and explanations for familiar mental experiences.

Soft Money Journal


	Soft Money Journal is a written archive about the ten minutes, the notebook, and the order things get paid in. It is for readers who want a quiet record of money habits, with journal entries and a letter signup instead of advice or amounts.

softmoney.kynth.studio

Still Mornings


	Still Mornings keeps the words from slow morning videos. It is for readers who want a quiet morning page, with the written reading, its hook, and a frame from the morning.

stillmornings.kynth.studio

Using It Up


	Using It Up is a publication about finishing what you already own. It is for readers who want to keep, mend, and use things to the last of them, with entries about repairs, abandoned carts, and buying less.

usingitup.kynth.studio

Why Your Brain Does That


	Why Your Brain Does That is an index of things your brain does and why doing them makes sense. It is for readers who want a name and explanation for familiar experiences, with short entries that explain what is happening and what changes on Monday.

whyyourbrain.kynth.studio

Send us someone who needs something built. $150, fixed, for every client you send whose work goes ahead. One link, no tiers, no portal. Get your link.

One shipped product, taken apart, once a month. What it does, what it cost to build, what the pipeline behind it looks like, and what the numbers did, read off the repository and the live site, not written from memory. Join the list.

Claude Code subagents fail 2.8x more often than skills

Isaiah Kim — Sun, 06 Sep 2026 00:14:08 +0000

Publish a subagent with no description line and nobody's Claude Code will ever hand it a task. Your file sits in the repository looking correct, it parses, it installs, and the one sentence the agent reads to decide when to delegate is absent, so there is nothing to route on.

That failure is silent by construction. A run that never selects a subagent does not error. It does the work inline, finishes, and reports that it finished. The self-report is accurate about the outcome and says nothing about the file you spent an afternoon writing.

What the census found

On 2026-08-14 I read every Claude Code skill, subagent, plugin and marketplace repository that could be found on GitHub and skills, from source, and checked one thing: whether an agent runtime could register the file at all. Not whether it is good, not whether it is popular. 445,348 artefacts, of which 43,199 fail, 9.7 percent.

The aggregate hides the finding. Subagents fail at 21.9 percent, skills at 7.9 percent, and the gap is 2.8 times.

Kind	Read from source	Failing	Rate	`name` required	`description` required
Subagent	71,430	15,669	21.9%	Yes	Yes
Skill	347,382	27,398	7.9%	No, falls back to the directory name	Recommended
Plugin	20,212	33	0.16%	Not a frontmatter question, `plugin.json` must parse	Not specified
Marketplace	6,324	99	1.6%	Not a frontmatter question, the manifest must list at least one plugin	Not specified

The failure causes, counted across all four kinds: 38,183 files whose settings block does not parse, 4,119 subagent files with no name, 1,799 subagent files with no description. A file can carry more than one, so those do not sum to the total.

The same careless file is a working skill and a dead subagent

The reason subagents fail three times harder is not that the people writing them are worse. It is a difference between two pages of documentation.

Anthropic's subagent reference says "Only name and description are required" and marks both Required: Yes. The skills reference says "All fields are optional. Only description is recommended", marks name Required: No, and defaults it to the directory name. So one hurried block of settings at the top of a markdown file loads cleanly as a skill and dies as a subagent, and the author has no way to tell which of the two they wrote unless they read both pages.

That asymmetry is the whole 2.8x. It is a specification difference, not a culture difference.

A verdict that rests on someone else's sentence

Here is the part that made me change how the index stores its own rules. The pass or fail decision is exactly this, from src/data/census.json:

{
  "always": ["broken-frontmatter", "broken-manifest", "empty-marketplace"],
  "subagent_only": ["no-name", "no-description"],
  "note": "works=false is exactly these flags and nothing else. Every other flag is a score deduction, not a load verdict."
}

no-name and no-description sit under subagent_only for one reason: two sentences on claude say so. If Anthropic revises either page, 15,669 subagent failures stop being failures and the headline number moves, without a line of my code changing.

So both sentences are stored in the product's claim register with a probe, which is the literal substring that has to still be present on the page. ops/qa/facts-gate.mjs --verify refetches both references and fails when a probe stops matching. Two dates are kept apart on purpose: asOf is the day a person read the source, lastVerified is the day a machine last confirmed the probe is still there, and --stamp may only move the second one. An HTTP 200 is not somebody having read the rule. Both probes last matched on 2026-09-04.

What I changed

I stopped treating a measured number as the thing that decays and started treating the rule underneath it as the thing that decays. The figures on the census page are my own measurements, so the only thing that can make them wrong is a bug in the export. The definition of "works" belongs to somebody else's documentation, and that is now the part with a probe on it and a gate that fails when it moves.

Toolproof publishes nine indexes that read AI agent tooling from source and record what they find, with the method for each one stated on the page. The census is free, CC-BY-4.0, and every figure above comes out of it.

A subagent with no description line never gets picked, so the rule that decides that is now stored with a probe and rechecked.

https://toolproof.kynth.studio/dv

DoseTrace: a $99 DSCSA binder for small pharmacies

Isaiah Kim — Mon, 24 Aug 2026 14:26:13 +0000

DoseTrace builds flat-fee DSCSA readiness binders for independent pharmacies: the written record around the serialization data, not another platform. Its own tagline is "the DSCSA record an inspector actually reads."

It is for the owner or pharmacist-in-charge of a small pharmacy, one store or a handful, who buys from two or three wholesalers and has no compliance officer. The person whose whole DSCSA plan right now is that the wholesaler probably handles it.

What you actually receive

Nine documents, prepared for your pharmacy, each one its own PDF, delivered as a zip:

A binder index, carrying your name, address, state licence and the date it was prepared.
The exemption determination: what your status is, the basis for it, and what changes at the sunset.
The trading-partner verification log: every supplier you buy from, one row each, dated and evidenced.
Three standard operating procedures: incoming product inspection, suspect and illegitimate product including the 24-hour FDA notification clock, and saleable returns.
A tracing response runbook: the path from a request landing to an answer going out, inside 24 hours.
A training attestation, one line per licensed staff member, signed against the SOP revision date on the binder.
A records retention plan: six years, per wholesaler, naming where each record actually lives.

The price is $99, charged once. No subscription, nothing renews, nothing to cancel.

The flat fee is a bet about the deadline

The reason the fee is flat is written into the site's own FAQ: "Because the deadline could move. A subscription priced against a date that shifts is how you end up owing refunds."

The deadline then moved. On 6 August 2026 FDA issued a new exemption letter granting small business dispensers a further year, running from 27 November 2026 to 27 November 2027. Its stated reason is that the assessment of small dispensers required by the statute is not finished. In the same letter FDA says the extension is "not intended to provide, and should not be viewed as providing, a justification for delaying efforts by small business dispensers to implement the enhanced drug distribution security requirements".

Here is the part that matters for anyone building against a government source. FDA replaced that letter at the same media URL, serving a different document, with no redirect and no new id. A check that confirms the URL still returns 200 learns nothing at all. So the product keeps a register of every dated claim it makes, and each row records the byte length and now a sha256 of the PDF it was read from, so the next check is a comparison rather than a re-reading. The current letter is 331,269 bytes; the one it replaced was 321,074.

What the free checker decides before you pay

The front page has an exemption checker. It takes six answers, stores nothing, and needs no account. Two traps it exists to catch, both of which flip the verdict:

The 25-employee threshold counts full-time pharmacists and technicians across the corporate entity that owns the pharmacy, not per store. A three-store owner who counts one location routinely believes they qualify. And "full-time" is the IRS test FDA cites: 30 or more hours a week on average, or 130 a month, so part-time staff below that line do not count at all.

The second one is newer and it changed the shape of the question. FDA takes the headcount on a fixed day, and for the extra year that day is 27 November 2026, which has not happened yet. The tool used to answer "were you under the line on a day that has passed." It now has to answer "will you be under the line on a day that has not," so every qualifying verdict says out loud that it is a reading of where you stand today rather than a status already fixed. Hiring past 25 licensed staff before that date puts you outside the second exemption.

The three things the generator refuses to build

The binder generator will not produce a document it should not produce. From ops/src/pack.mjs:

// ---- GATE 2: no trading partners -------------------------------------------------
const wholesalers = Array.isArray(intake.wholesalers) ? intake.wholesalers.filter((w) => w && w.name) : [];
if (!wholesalers.length) {
  throw new Error(
    'no wholesalers in intake - a trading-partner verification log with zero partners evidences nothing. Get the supplier list before generating.',
  );
}

// ---- GATE 3: over the threshold is a judgment document ---------------------------
if (fte > FTE_THRESHOLD && !reviewPath) {
  throw new Error(
    `NotConfigured: ${fte} licensed FTE is over the ${FTE_THRESHOLD} threshold, so this pharmacy was never a small dispenser. That determination is a judgment about their past posture - it needs a hand-written review before anything ships.`,
  );
}

The third gate blocks after the sunset date: the entire binder is written in the voice of a determination you are carrying into a deadline, and after that deadline the framing is wrong, so it stops rather than hand a pharmacy a document that misdescribes its own status.

The over-threshold gate is the one I would defend hardest. A pharmacy above 25 licensed staff was never a small dispenser, which means the enhanced requirements have applied to it the whole time. Writing that down is a judgment about somebody's past compliance posture, and no template gets to make it. It needs a person, and nothing auto-drafts and nothing auto-sends.

What it is not

DoseTrace is not a track-and-trace platform and does not move serialization files. Your wholesalers already do that.

That distinction is harder to see than it should be, because the category is sold under three letters that cover two different halves. Nine vendor domains were being cited for this buyer's questions; all nine were fetched on 23 August 2026 before a word was written about them. Five are not selling to an independent pharmacy at all. ConsortiEX says so in its own meta description, naming health systems and hospitals. RxERP's audience menu lists wholesalers, distributors and government, and a dispenser is not on it. Tecsys' home page contains zero occurrences of "DSCSA" and zero of "pharmac". Pulse by NABP is not a vendor at all. RedSail, parent of PioneerRx and PrimeRx, answers DSCSA by reselling: its own menu reads "DSCSA Compliance Solutions, LSPedia's Pharmacy Pro and InfiniTrak."

Neither of those two publishes a price.

And across both FDA exemption letters, the word "software" appears once, as a technology and software assessment FDA itself has to commission. The statutory language quoted at the pharmacy is "systems and processes." The processes half is the binder, and it is $99, once.

Run the free exemption check first. It will tell you whether any of this reaches your pharmacy before you spend anything.

https://dosetrace.kynth.studio/dv

I turned on error tracking. Most of it was Outlook.

Isaiah Kim — Mon, 17 Aug 2026 14:27:01 +0000

A weekly report landed on August 17th telling me my sites had thrown 363 exceptions, up 156 percent from the week before, with crash-free sessions at 94.29 percent. That is the kind of number that reorganises a day. Something is broken badly enough that roughly one visit in eighteen hits it, and I have no idea which page.

333 of those 363 were not my code. Not a subtle bug in my code, not a dependency of my code. Two browser artifacts and a dev server.

What was actually in there

The products involved have nothing to do with each other. AgentWire is a curation lane for agentic developer tooling, MCP servers and coding-agent harnesses, and its site is a 1:1 reflection of what the accounts actually posted. KitGrade is a directory of SaaS starter kits scored from measured facts, where every kit is labelled hands-on or documented and the label records whether the kit was cloned onto a machine and built. Different data, different stacks underneath, different everything. The only thing they share is the analytics snippet.

327 of the 363 were this string:

Non-Error promise rejection captured with value: Object Not Found Matching Id:N,
MethodName:update, ParamCount:4

That is not from any code I wrote. It comes from the wrapper Microsoft puts around links opened out of Outlook, running inside the page it just opened. Which is why it fired on AgentWire and KitGrade and everything else at the same moment: an error that appears simultaneously across products sharing no code is not coming from any of them. That simultaneity is the only tell you get, and you only get it if you have more than one site reporting into the same place.

6 more were ResizeObserver loop completed with undelivered notifications, which is the notice a browser emits when a layout observer runs long. Nothing is on fire. Nobody sees anything.

The remaining 30 were mine, in the least useful sense. They were a dev server on http://localhost:3737 reporting compile errors into the production project while I was mid-edit: PAD_X is not defined, SelectedWork is not defined. Errors I had already fixed before the report was written, filed alongside real ones.

The part that generalises

Turning on browser exception capture is one boolean now. In posthog-js, which I am on at 1.407.5, it is capture_exceptions: true next to the pageview settings. You add a line, you deploy, and a week later you have a health metric.

The metric is wrong out of the box, and it is wrong in the direction that costs you the most. It reads worse than reality, so the first thing it makes you do is go looking for a crash that is not there. Then, once you have learned that the report is noise, it reads as noise forever, and the first real one arrives in a mail that looks exactly like the previous four.

The dev server half is worth its own sentence. The project key lives in the client bundle, so it is the same key on localhost, on a preview URL and in production. Every environment reports into one place unless you tell it not to.

The gate

posthog-js has a before_send hook that runs in the browser and drops the event when you return null. I put the filter there rather than in the dashboard, because a dropped event costs nothing and a filtered one still has to be sent, stored and then excluded from every view forever after.

before_send: (event) => {
  if (!event || event.event !== '$exception') return event;
  try {
    const host = window.location.host.split(':')[0].toLowerCase();
    if (host === 'localhost' || host.endsWith('.localhost') || /^[\d.]+$/.test(host) || host.endsWith('.vercel.app')) return null;
    const v = JSON.stringify(event.properties?.$exception_values ?? '');
    if (/Object Not Found Matching Id:\d+/.test(v)) return null;
    if (/ResizeObserver loop/.test(v)) return null;
  } catch {
    // a noise gate must never be the thing that breaks a page
  }
  return event;
},

Three details in there I would keep if I wrote it again.

The first line checks event.event !== '$exception' and returns early. before_send sees everything, including pageviews and clicks, so a filter written loosely here quietly eats your entire analytics feed instead of your error feed.

The host check drops localhost, any .localhost subdomain, bare IP addresses and preview deployments. That is the environment split I did not get for free.

And the catch is the one I care about most. This function runs inside the page, on every event, before anything is sent. If it throws, it throws in front of the visitor. A filter that exists to protect a dashboard is not allowed to be the reason a page stops working, so it fails open and lets the event through.

The two regexes are the least durable part of this. They match strings that a browser vendor can change without telling anyone, and when that happens the noise comes back and I will have to read a digest carefully to notice. I would rather that than a filter loose enough to swallow something real.

The number I get now is 30 exceptions smaller and it is entirely mine. That is the point of the exercise: not a better crash rate, a crash rate that is about my software.

https://agentwire.kynth.studio/?utm_source=founder-devto&utm_medium=social

I shipped a download that iOS turned into a navigation

Isaiah Kim — Fri, 14 Aug 2026 14:51:58 +0000

I read a session from an iPhone where the visitor pressed an export button four times, and $pageleave fired about 150 milliseconds after each press, with a reset page when they came back. Those four departures were the export itself.

WebKit does not honour the download attribute on a blob: URL. On iOS and iPadOS, where every browser is WebKit underneath regardless of what it says on the icon, a.download pointed at a blob is ignored and the click becomes a navigation to that blob. The page unloads. Whatever state produced the file goes with it.

That pattern is everywhere in my code, so I went and fixed the place where it costs the most.

What the page was holding

PartsProof is a Cyber Resilience Act tool I'm building under Kynth, and its free surface is an SBOM generator. You give it a public GitHub repo and an email, and it returns a CycloneDX 1.5 document you can download.

The work behind that is not cheap. src/app/api/sbom/route.ts resolves the repo and its default branch, pulls the full recursive tree, filters that down to dependency manifests, then fetches and parses up to thirty of them. MAX_MANIFESTS is 30, so the whole run is as many as thirty-two GitHub round-trips before a single component is counted.

Because it takes real time, the route streams NDJSON and fires a stage as each piece finishes, with the measured elapsed per stage. The five ids live in one file, src/lib/stages.ts, with a note on top I put there for myself:

/* ⛔ Adding a label here does not create a stage. A stage exists when the route fires it. */
export type StageId = "repo" | "tree" | "manifests" | "bom" | "lead";

So on a phone, the sequence was: wait through thirty-two round-trips, watch five stages report, get told how many distinct components came back, press download, and land on a blob viewer with the whole result gone. Pressing back gives you an empty form. The only way to see the number again is to run all of it again.

The branch, and the iPad that says it is a Mac

The fix in src/components/Lookup.tsx is small. On WebKit mobile, stop pretending the anchor is a download and let it be what WebKit is going to make it anyway: a navigation, but into its own tab, where the document opens with a share sheet instead of destroying the page that produced it.

const ua = typeof navigator === 'undefined' ? '' : navigator.userAgent || '';
const webkitMobile =
  /iP(hone|od|ad)/.test(ua) ||
  (navigator.platform === 'MacIntel' && navigator.maxTouchPoints > 1);
if (webkitMobile) {
  aEl.target = '_blank'; aEl.rel = 'noopener';
}
document.body.appendChild(aEl); aEl.click(); aEl.remove();

The second clause of that test is the one I would have missed. An iPad running iPadOS reports navigator.platform as MacIntel and sends a desktop user agent string with no iPad in it, so the regex alone reads it as a laptop and leaves it broken. maxTouchPoints > 1 is what separates the iPad from an actual MacIntel machine, and a Mac with a trackpad reports 0. It is a sniff, and I do not love that it is a sniff, but there is no feature query for "this browser ignores an attribute".

I also considered the File System Access API and skipping the anchor entirely. Safari does not implement showSaveFilePicker, so the fallback path is this same anchor, and adding a branch that only ever runs on the browsers already working buys nothing.

Revoking on the next line

The other half of that commit is a bug that had been sitting there the whole time and would have been much harder to see.

document.body.appendChild(aEl); aEl.click(); aEl.remove();
URL.revokeObjectURL(url);   // ← this

click() starts a save. It does not finish one. Revoking the object URL on the very next statement pulls the blob out from under a transfer that has only just been handed to the browser. On desktop with a small JSON body it wins the race essentially always, which is exactly why it survives review: it looks like tidy cleanup and it behaves like tidy cleanup right up until the document is large or the device is slow or the save goes through a share sheet.

It now reads:

// Revoking on the next line races the save the click just started; give it a window.
setTimeout(() => URL.revokeObjectURL(url), 60_000);

Sixty seconds of one blob held in memory is not a leak worth optimising against a file that sometimes does not arrive.

Saying "downloaded" when nothing downloaded

There was one more thing wrong, and it took a second pass to notice. The success message was a single template string:

setSbomMsg(`downloaded ${repoName}-sbom.cdx.json.`);

On the WebKit path that sentence is false. Nothing landed in a downloads folder. The document opened in its own tab and is waiting for the reader to press Share. Telling someone a file was saved when it was not is the specific failure this panel exists to avoid, since the whole product is about producing a document you can hand to somebody.

setSbomMsg(
  webkitMobile
    ? `${repoName}-sbom.cdx.json opened in a new tab — use Share to save it.`
    : `downloaded ${repoName}-sbom.cdx.json.`,
);

The branch that changes behaviour and the branch that describes it have to be the same branch. Fixing the navigation without fixing the sentence would have left the tool confidently reporting a save on the one platform where it never performs one.

None of this showed up in a build, a type check, or any gate I run against the deployed page. Blob downloads are one of the last things in a web app that no automated check I have will exercise, because the interesting part happens after the click, in the browser's own plumbing, on a platform I was not testing on. The telemetry found it, and it found it as four unexplained departures rather than as an error.

https://partsproof.kynth.studio/?utm_source=founder-devto&utm_medium=social

I built a Playwright gate that cried wolf 889 times

Isaiah Kim — Tue, 11 Aug 2026 14:28:35 +0000

On August 2nd I shipped a landing page whose headline was in the DOM at the right size, the right colour and the right position, and invisible. StoreReady's data-animate="17g0wbg" resolved against motion data from a different capture, so the h1 held its start frame, opacity 0.001, permanently. Every gate I had passed the build.

They passed because they all read source. icons-gate greps the icon set, mark-gate greps the lockup, workbench check hashes the vendored files. All of them are decidable without a renderer, and there is no string to grep for a pixel that never got painted.

So I wrote one that never reads a file. ops/qa/render-gate.mjs in the workbench repo takes a URL, drives real Chrome, and asks six questions a screenshot answers: effective opacity down the whole ancestor chain, WCAG against the computed background, horizontal scroll from 320 to 1920, control labels breaking to a second line, headline and CTA above the fold at 1280x800, and content trapped past the start edge of its own scroll container. Each product's scripts/deploy.sh runs it after the deploy, against the live host, and a failure is hard.

The first sweep reported 889 invisible elements

Essentially all of them were scroll-reveal sections below the fold, sitting at opacity 0 because nothing had asked them to appear yet. A gate that cries wolf 889 times is not a gate.

The part I want to keep from that run is why I did not see it coming. My own shell's entrance runtime reveals on mount rather than on intersection, so the sites already on it scored honestly by accident, which is the worst way to be right. Pointing the same measurement at pages with intersection-driven reveals is what exposed the model.

The fix is that the gate judges only what is on screen. It walks the page, probes at each stop, and merges by element plus text keeping the best reading of each one. An element off-screen at opacity 0 is not a defect. An element in front of the reader at opacity 0 is the StoreReady bug. One scroll position cannot tell those apart.

Per-stop settle is 750ms, long enough for a reveal to finish rather than merely to start. At 320ms it kept catching FetchDue's sections at opacity 0.061, mid-fade, which reads as a defect and is not one.

Two ways the walk still lied

The first was arithmetic. The stops stepped a fixed 0.75 viewport down from the top and then took .slice(0, 14) for the time budget, so on anything taller than about 9,450px at a 900px viewport the sweep just stopped and everything below was never judged at all.

const h = Math.max(document.body.scrollHeight, document.documentElement.scrollHeight);
const MAX = 14; // 14 stops at 750ms is the time budget
const step = Math.max(Math.round(innerHeight * 0.75), Math.ceil(h / MAX));
const out = [];
for (let y = 0; y < h; y += step) out.push(y);

Spreading the same budget over the real height means density degrades on a very long page instead of coverage vanishing. A missed defect in the last third is worse than a coarser walk.

The second is the interesting one. On a long page an element can be in front of the reader at exactly one stop. If that stop catches it entering at the bottom edge, or partway through a stagger, then the best-reading merge has only the bad reading to keep. The finding looks real, reproduces across runs, and describes nothing anyone would ever see. On QuorumFile that condemned three cells of a seventeen-row table, all three at opacity 1 the moment you scroll to them.

Look at it again, on purpose

Anything the walk condemns now gets one more measurement, taken deliberately.

const condemned = text.filter((t) => t.opacity < OPACITY_FLOOR && !t.decorative && !t.clipped);
for (const t of condemned) {
  await page.evaluate((top) => scrollTo(0, Math.max(0, top - innerHeight / 2)), t.top);
  await page.waitForTimeout(1400);
  const fresh = await page.evaluate(probeText);
  const better = fresh.find((f) => f.sel === t.sel && f.text === t.text && f.inFold);
  if (better && better.opacity > t.opacity) Object.assign(t, better, { pxRatio: undefined });
}

OPACITY_FLOOR is 0.08. Two details in there cost me something. Only condemned runs are re-measured, so a clean page pays nothing for this, which is what makes a 1400ms settle affordable at all. And the fresh reading replaces the stale one whole, rather than just its opacity. A reading taken while an element was at opacity 0 also carries the contrast it had against whatever was behind it, which is 1:1 because no ink was painted. Adopting the opacity alone clears the visibility finding and hands that dead 1:1 straight to the contrast check. One false finding becomes a different false finding.

A finding that survives being scrolled to and stared at for a second is the real bug. One that does not was never a bug.

What it caught

On August 8th, on a QuorumFile deploy, it failed on the pricing block's document preview: painted at opacity 0, and not marked decorative.

The cause was not in the pricing block. ScrollReveals collects auto-fade candidates from main.page > * and walks down, so any element added to any section inherits a 0-opacity start state whether it asked for one or not. Mine carried no data-reveal and got one anyway. The fix was to put it in the runtime's skip list next to .header, for the same reason the header is there.

const SKIP = ".header, .trail, .nav-list, .nav-dropdown-list, .sheet-overlay, .kd-artefact-link";

The gate cannot decide this on its own, and it does not try. My footers carry a brand wordmark at opacity 0.07, which is a watermark and correct. StoreReady's hero sat at 0.001, which was a bug and shipped. Measured, those are the same observation, so the rule is that text below the floor has to declare itself with aria-hidden="true" or it counts as a failure. A heading is never decoration.

I had opened that pricing block in a browser more than once before the deploy. The gate found it, I did not.

The early return that shipped a false all-clear

Isaiah Kim — Sun, 09 Aug 2026 14:25:28 +0000

I typed the word "construction" into my own lookup tool and it answered:

All 200 qualifying contracts under null have an approved Affidavit of Wages Paid on file.

Two things wrong in one sentence, and the more interesting one is that nothing had been checked against the affidavit file at all. The route had returned before it got there.

The product is HeldBack, a free retainage blocker check I'm building under Kynth. You give it a company name or a 9-digit UBI, and it reads two of Washington's published Socrata files live: the Statements of Intent a contractor files before a public works job, and the Affidavits of Wages Paid filed after. A job with an intent and no matching approved affidavit is a job whose retainage, capped at 5% under RCW 60.28.011, is likely still sitting with the awarding agency.

The floors are most of the logic

The naive version of this is a set difference: intents minus affidavits. That version is wrong in a way that destroys the product's credibility on first contact, because a job that started six months ago has no affidavit for the boring reason that the work isn't finished. Report that as frozen money and you've told a contractor something they know to be false about a job they remember clearly.

So src/app/api/lookup/route.ts filters before it compares:

const MIN_CONTRACT = 5000;
const MIN_AGE_MONTHS = 24;

const priced = intents.filter(
  (r) => Number(r.cntrct_amt) >= MIN_CONTRACT && !tooRecentOrUndated(r.expected_start_dt),
);

At or under $5,000 the affidavit is folded into the combined intent form and never appears separately, so those rows are false positives by construction. Undated rows can't be aged at all, so tooRecentOrUndated returns true for them and they drop out too.

Both floors are correct. The bug was what happens when they eat everything.

The return that skipped the comparison

if (priced.length === 0) {
  return NextResponse.json({ term, company: null, rows: [], searched: intents.length });
}

searched is the number the UI prints back. Everywhere else in the file it means "contracts we actually compared against the affidavit file". Here it meant "rows the first query returned", because at the moment I wrote the line those felt like the same quantity.

They're the same quantity right up until a search term is generic. The intents query is capped at $limit: '200', and a common word matches far more than 200 filings across the whole state, none of them one company. Nearly all of them fail the $5,000 floor or the 24-month floor. priced comes back empty, the route returns here, and the client is handed searched: 200 with an empty rows array. The panel reads that as 200 contracts checked and zero blocked.

The null in the sentence has the same root. Company name is resolved as priced[0]?.companyname, and on this path priced is empty.

The fix splits the count into two:

if (priced.length === 0) {
  /* `searched` IS THE QUALIFYING COUNT, NOT THE FILING COUNT, and this line used to return
   * `intents.length` for it. [...] `found` is the honest count for this case: filings
   * located, none of them judgeable. */
  return {
    payload: {
      term,
      company: intents[0]?.companyname ?? null,
      rows: [],
      searched: 0,
      found: intents.length,
      cleared: 0,
      totalHeld: 0,
    },
  };
}

searched: 0 is now literally true. Nothing was searched against the affidavit file.

Two branches for three outcomes

The other half was in src/components/HeroLookup.tsx, which had an empty state and a clear state and nothing else. Any result with rows.length === 0 fell into "nothing appears to be blocked". There was no way to express "we found filings and none of them can be judged yet", so that case borrowed the reassuring one.

{(result.found ?? 0) === 0
  ? 'No public works contracts found under that name.'
  : result.searched === 0
    ? 'Nothing here can be judged yet.'
    : 'Nothing appears to be blocked.'}

The middle branch explains itself in the body copy: every match is under $5,000 or started inside the last 24 months, a job that recent has no affidavit because the work is not finished, and search the exact legal entity name or the UBI to narrow it. That last part matters more than the correction does. The person who typed a generic term wanted an answer about a company, and now the panel tells them how to get one.

The same short-circuit, one component away

The wait panel streams NDJSON and fires a stage as each of the route's four real pieces of work finishes, with the measured elapsed printed per stage. On a real company that reads 587ms, 587ms, 756ms, 757ms, and the third line says "53 of 74 have an approved Affidavit on file". Two of the four stages are live network calls, which is where the seconds go.

The orb at the head of that panel spun forever on the short-circuit path, because it asked whether all four stages were done. On an early return two of them never fire, so the answer is permanently no, and the orb kept spinning next to a finished answer.

const running = steps.some((s) => s.state === "running");
const phase = idle ? "idle" : failed ? "failed" : running ? "running" : "done";

What the orb reports is whether anything is still happening, not whether every stage reported.

Neither of these turned up in reading. I found both by typing a word into the live thing and looking at the sentence it gave back, which is also the exact sentence a first-time visitor would be most likely to see, since a generic term is what you type before you know what the tool wants.

I paged a table with no ORDER BY and lost 2,797 rows

Isaiah Kim — Fri, 07 Aug 2026 14:24:14 +0000

I ran a verification pass over 22,313 rows, it reported 22,313 rows, and I read that number as proof it had checked all of them. It had checked about 19,500 and looked at some of those twice.

The product is BlockDex, an item-level index of public shadcn registries I'm building under Kynth. Every item page can render a Live preview — an iframe of the component's own docs page — under a caption that says this is the component running, not a screenshot of it. Nothing checked that claim. preview_url was a URL shape learned once per registry from a single sample item name, accepted on status === 200 && text.length > 500, then stamped onto every item in that registry.

Two things went wrong with that. The last docs pattern tried is {origin}/r/{name}, which on a large class of registries is the registry-item JSON route — the same route the install command reads. A 4KB JSON body clears a length test, the request sent accept: 'text/html,*/*' so the */* forced nothing, and an API route sends no X-Frame-Options, so the framability check returned true and marked that registry the most embeddable kind there is. One registry framed its own JSON and Chrome rendered its JSON viewer inside the panel. Separately, a shape learned from one item name does not hold for 7,794 items, so most of the rest resolved to the registry's 404.

I fetched all 22,313 stored preview URLs. 7,382 were not component pages: 4,704 hard 404s, 1,588 JSON documents, 691 soft 404s, 399 server errors.

The count that matched

ops/verify-previews.mjs pulls its work list through a paging helper that walks a table with limit/offset — 23 pages at a thousand rows each. The query had no ORDER BY.

An offset over an unordered query is not a stable window. Postgres is free to return the rows in a different order for each page, so between page 4 and page 5 a row can shift across the offset boundary and be handed to you twice while another row slides the other way and never arrives. The totals still add up, because you asked for 23 slices of a thousand and got them.

I found it the slow way. After the pass finished and wrote its updates, shadcn-io/area-interactive still had a Live preview panel mounted over a 404. Its row was in the set the paging skipped.

// ⛔ `order=id.asc` IS LOAD BEARING. `selectAll` pages with limit/offset, and an offset over a
// query with no ORDER BY is not a stable window — Postgres is free to return the rows in a
// different order for each of the 23 pages, so a row can arrive twice and another never arrive
// at all. The first full run pulled exactly 22,313 rows, which looked like complete coverage
// and was not.
const rows = await store.selectAll(
  'blockdex_items',
  `select=id,registry_slug,name,preview_url,preview_embeddable,docs_url,status&preview_url=not.is.null&order=id.asc${filter}`,
);

The second pass with the sort key found 17,728 rows still carrying a preview URL where 14,931 were expected, and unpublished 1,603 more. A third pass agreed with the second: 16,121 of 16,125 verified, the remaining four a transient 502.

The fan-out that wasn't doing anything

The same file had a second bug I'd have shrugged at if I hadn't been staring at it. Global concurrency is 40. The real limiter is a per-host cap of 3, which is what keeps a registry running on one small deployment from getting hammered. And rows come back from PostgREST grouped by registry.

shadcn-io is 7,794 contiguous rows on one host. So all 40 workers picked up shadcn.io items, 37 of them parked on that host's semaphore, and the other 127 hosts in the corpus sat idle. The run did 1,500 items in eleven minutes and was on course for about three hours.

const byHost = new Map();
for (const row of rows) {
  const host = URL.parse?.(row.preview_url)?.host ?? row.registry_slug;
  if (!byHost.has(host)) byHost.set(host, []);
  byHost.get(host).push(row);
}
const queues = [...byHost.values()];
const work = [];
for (let i = 0; work.length < rows.length; i++) {
  for (const q of queues) if (i < q.length) work.push(q[i]);
}

Round-robin by host, then hand that array to the pool. Wall clock becomes the slowest single host instead of the sum of all of them.

What counts as a missing page

The check itself, in ops/lib/preview.mjs, is deliberately narrow. My first version read the first 4KB of the body looking for not-found markers, and on a 400-URL sample it condemned two real, rendering component pages that happened to carry the string 404 in a nav and an inlined script. Deleting a working item from the index is the worse outcome, because a 404 that slips through is visible on the page and a missing item is not. So the test only reads <title>, which is the one place a framework's not-found page reliably announces itself — fumadocs writes "Component not found", Next writes "404".

A failure clears docs_url alongside preview_url, too. Downgrading a dead frame to a "See it running" link is the same claim in smaller type.

Final state: 11,502 items carry a verified Live preview, 2,369 a verified link, 45,343 neither, 8,985 unpublished. The order=id.asc has a comment sitting on top of it, because the version without it doesn't fail — it returns a number that matches the table.

I rewrote 1.2M Postgres rows a run to change nothing

Isaiah Kim — Wed, 05 Aug 2026 14:25:17 +0000

I went looking for why one Supabase project kept draining its Disk IO Budget, and the answer was a Python script rewriting 1,206,313 rows to change nothing.

The product is GoodStanding, a free EIN diagnostic I'm building under Kynth. You type in a nonprofit's EIN and it tells you whether that org is on the IRS Auto-Revocation List or on California's "May Not Operate or Solicit" list. The table behind it, gs_orgs, is fed by ops/src/ingest-registries.py, which pulls two files: the IRS bulk revocation zip, and the CA AG CSV that refreshes on the 1st and 3rd Wednesday.

Both feeds republish their entire corpus every cycle. A few thousand rows actually move. The ingest didn't know that, so every run it upserted all 1.2 million.

Measured against the stats reset on May 22, that one script was the largest consumer of disk IO on the whole project: 24,721 upsert statements, 10.2 GB read from disk, 3h17m of database time.

Fingerprint the row, not the feed

The obvious fix is to diff against what's already in the table, but reading 1.2M rows back to decide whether to write 1.2M rows is the same IO with extra steps. What made a cheaper option available is a property of this particular table: ingest-registries.py is the only writer to gs_orgs. Nothing else touches it. So a local record of what the script last wrote is authoritative, and no read is needed at all.

def fingerprint(row):
    """Stable 16-hex digest of the columns we actually write."""
    blob = '\x1f'.join('' if row.get(c) is None else str(row[c]) for c in COLUMNS)
    return hashlib.blake2b(blob.encode(), digest_size=8).hexdigest()

Hashing COLUMNS and not the parsed source record matters. The feeds carry fields the table doesn't store, and a whitespace change in one of those would otherwise flag a row as changed and buy back the write I'm trying to avoid.

The selection is then four lines:

fresh = {ein: fingerprint(r) for ein, r in merged.items()}
if args.full:
    rows = list(merged.values())
else:
    seen = load_fingerprints()
    rows = [r for ein, r in merged.items() if seen.get(ein) != fresh[ein]]

Two things about the cache file are deliberate. Missing it isn't an error — load_fingerprints() swallows FileNotFoundError and returns {}, every row mismatches, and you get a full rewrite. The degraded state is the old behaviour, which is slow and correct. And it's written once, after the last batch lands:

# Written only after every batch landed: a crash mid-run leaves the cache
# untouched so the next run retries the same rows.
save_fingerprints(fresh)

Saving per batch would have been the natural thing to write, and it's the version where a timeout halfway through convinces the next run that rows it never wrote are already durable.

Run against that day's corpus: 0 of 1,206,313 rows flagged as changed.

The indexes nobody had ever used

While I was in the stats I checked which indexes on gs_orgs had been scanned. Three had a scan count of zero: gs_orgs_name_trgm, gs_orgs_posting_idx, gs_orgs_ca_status_idx. Never once, and maintained on every one of those upserts.

gs_orgs_name_trgm is the one worth sitting with. Despite the name it wasn't a trigram index at all — it was a btree on lower(name) text_pattern_ops. The name search the app actually issues is in src/app/api/lookup/route.ts:65:

rows = await sb(`gs_orgs?name=ilike.*${encodeURIComponent(safe)}*&...&limit=8`);

Leading wildcard. A text_pattern_ops btree can serve a prefix match and nothing else, so that query had been sequential-scanning the whole table since the day it shipped, next to an index named as though it were handling it. Dropping all three took the table's index footprint from 198 MB to 72 MB.

The write was the smaller problem

The next day I made the bigger call, and it went the other way from where I started. The project had been moved onto its own Supabase instance for blast-radius isolation, at $10/month. For one product that isn't a trade worth making — so instead of paying to keep 1.2M rows somewhere safe, I asked what the product can actually do with them.

An org revoked in 2013 is looking at a full 1023 re-application. GoodStanding sells a reinstatement Cure Pack; that org isn't a buyer, and its row is heap, index and WAL on a database the rest of the estate shares. California is different — AB 488 blocks a listed org's donation pages regardless of how old the listing is.

def worth_keeping(r):
    if r.get('ca_reg_no') or r.get('ca_registry_status'):
        return True                      # CA-listed: AB 488 buyer at any age
    if r.get('reinstatement_date'):
        return False                     # back in good standing; "clear" is correct
    return (r.get('revocation_date') or '') >= keep_since \
        or (r.get('revocation_posting_date') or '') >= keep_since

331,377 rows of 1,206,313. 261 MB down to 81 MB, back on the shared database, and the outreach delta came through unchanged: 716 IRS postings in the last 45 days, 8,219 CA delinquent or suspended.

There's a trap in that, and it's the reason the comment block above worth_keeping is longer than the function. /api/lookup reads "no row" as clear — the table only ever holds orgs that are on a list, so absence is the good answer. Drop a still-revoked 2013 org and the tool tells that nonprofit it's fine.

So the cutoff is load-bearing on a claim in the UI, and the two are now written down together. GS_KEEP_REVOKED_SINCE defaults to 2020-01-01, the route file carries a retention warning at the top, and the clear-state copy in EinLookup.tsx says "No IRS auto-revocation posted since 2020" rather than the unqualified all-clear it used to say. Widening the cutoff means widening that sentence.

What I'd been treating as a performance problem had a correctness statement buried in it. The rows I was paying to rewrite twice a month were also the rows that decided what the product was allowed to promise, and I only found that by going looking for the disk IO.

unstable_cache stored my outage for a full hour

Isaiah Kim — Sun, 02 Aug 2026 14:22:41 +0000

I shipped a directory page that told visitors there were zero listings while rendering a grid of 48 of them. Fixed it. Then, about nine hours later, shipped a different bug with the exact same symptom, in the exact same function, for a completely unrelated reason.

The product is SkillWorks, a scored directory of Claude Code skills, subagents, plugins and marketplace repos I'm building under Kynth. It reads from Supabase over PostgREST, and it needs a lot of row counts: total listings, counts per kind, how many are broken, how many have tracked installs. Counting rows without pulling them is the one thing PostgREST makes genuinely cheap — ask for Prefer: count=exact with Range: 0-0 and the total comes back in the Content-Range response header. No rows in the body at all.

That header is where both bugs live.

The first zero: the header didn't survive the cache

Original version, in src/lib/db.ts:

async function countRows(table: string, query: string, col = 'id'): Promise<number> {
  const res = await fetch(`${URL}/rest/v1/${table}?${query}&select=${col}&limit=1`, {
    headers: { apikey: KEY, Authorization: `Bearer ${KEY}`, Prefer: 'count=exact', Range: '0-0' },
    next: { revalidate: REVALIDATE },
  });
  const range = res.headers.get('content-range');
  return range ? Number(range.split('/')[1]) || 0 : 0;
}

Next's fetch cache stores the response body. On a cache hit it hands you back a Response assembled with a synthetic header set, and content-range is not in it. So every cache hit read null and fell through to 0.

What kept this hidden for a while is that statically prerendered routes were fine. Their one fetch happens at build time and is always a miss, so the real header is right there. Only routes rendering at runtime hit the cache, and those were the ones shipping "0 indexed" next to a full grid. /marketplaces read "None of the 0 marketplaces".

The fix is to stop caching a thing whose value lives outside the cached payload. Make the fetch cache: 'no-store' and wrap the whole function in unstable_cache, which memoises the return value instead. Still one request an hour, but now what's stored is a parsed number, which survives being stored.

The second zero: a failed read stored as an answer

That was August 1st, early afternoon. That evening Supabase had an outage, and I watched /skills render "Search all 0 listings" above cards that looked completely normal.

The cards were fine because they come from Next's fetch cache and it still had them. The counts came through the new uncached path, hit a dead index, and returned 0 — which is the last line of the function above, doing exactly what it was written to do. And unstable_cache dutifully stored that 0 for the full REVALIDATE window, which is 3600 seconds.

That's the part that actually bothered me. The outage was maybe twenty minutes. The wrong number would have outlived it by forty. The database could be answering perfectly and the site would still be advertising zero listings, with no error, no degraded state, nothing to look at. A directory that confidently reports emptiness is worse off than one that's visibly broken, because nobody goes looking.

The || 0 was defensive code from the first bug that quietly became the second one. Returning a fallback and memoising a fallback are different operations, and one function was doing both.

Throw inside the cache, degrade outside it

const countRows = async (table: string, query: string, col = 'id'): Promise<number> => {
  try {
    return await unstable_cache(
      async () => {
        const res = await fetch(/* … */, { cache: 'no-store' });
        const range = res.headers.get('content-range');
        // THROW rather than return 0 when the index cannot be reached.
        // `unstable_cache` stores whatever the function RETURNS, for a full hour.
        if (!res.ok || !range) throw new Error(`count ${table}: ${res.status}`);
        const total = Number(range.split('/')[1]);
        if (!Number.isFinite(total)) throw new Error(`count ${table}: unparseable content-range`);
        return total;
      },
      ['count', table, query, col],
      { revalidate: REVALIDATE },
    )();
  } catch {
    // 0 is still what the caller gets — a directory page that 500s over a stat line is worse
    // than one that under-reports for a few seconds. The difference is this 0 is NOT cached.
    return 0;
  }
};

The caller still gets 0. A browse page shouldn't throw a 500 because a stat line in a search placeholder couldn't be computed. But the fallback now lives outside the memo, so nothing gets written, the next request re-reads, and the wrong number lasts exactly as long as the outage does and not one second longer.

The same weekend, in a different product, I hit the same shape from the other direction. ListRun has pages where the row is the page — a directory detail, a run, a paid receipt — and they all called a helper that returned null on any failed read, then called notFound(). Which means a slow database told a buyer their run does not exist, and on a cached render it baked that 404 in. The fix there was apiRequired in src/lib/site.ts: return null only on an actual 404 from the route, throw on anything else, so notFound() is always a statement about the row.

Both are the same mistake. A read that fails and a read that legitimately returns nothing produce the same value, and then something downstream — a cache, a router — treats that value as established fact and keeps it around. The failure gets laundered into data on the way out.

I've stopped trusting any fallback that sits inside a memo boundary. If a function can be wrong and can be stored, those two facts need to be separated by a throw.

Custom element FOUC: the rule that hid nothing

Isaiah Kim — Fri, 31 Jul 2026 14:21:44 +0000

I shipped a CSS rule that could not possibly do its job, looked at the page, saw the flash still happening, and spent longer than I want to admit tuning the wrong thing.

The product is Tearline, a small zero-dependency web component I'm building under Kynth. You wrap any HTML in one tag and it renders as a thermal receipt you can export as a PNG:

<tear-line barcode="047320260726">
  <h1>MERIDIAN</h1>
  <p>Coffee &amp; Provisions</p>
</tear-line>

Custom elements have a well-known ugly window. Until customElements.define runs, those children are just ordinary HTML sitting in the page: a bare <h1> and some <p>s in whatever the host's body font is, at a completely different height to the receipt that eventually replaces them. On a cold load that's visible long enough to read, and then the layout jumps.

The standard fix is :not(:defined). :defined only starts matching once the element upgrades, so hiding on :not(:defined) is exactly the window you want to cover.

Where I put it, and why that was wrong

I didn't want every consumer of the component to have to remember a stylesheet rule. So I had tearline.js inject it:

// src/tearline.js — what I shipped first
if (typeof document !== 'undefined' && !document.getElementById('tear-line-fouc')) {
  const s = document.createElement('style');
  s.id = 'tear-line-fouc';
  s.textContent = 'tear-line:not(:defined){visibility:hidden}';
  document.head.append(s);
}

customElements.define('tear-line', TearLine);

There was a second reason I liked this, and it's a real one: if the script never loads at all, the rule never lands either, so the content stays visible instead of being hidden forever by a stylesheet with nothing left to reveal it. Failure mode handled. Nice.

Except the whole thing is inert. That script running is the exact moment :not(:defined) stops matching. The rule and the definition arrive in the same tick, so the rule only ever exists after the window it was written to cover. It hid nothing during the only period that mattered.

I found this by throttling tearline.js to a 1.2s delay in devtools, which made the unstyled window long enough to actually stare at. Before that I'd been reading the rule, agreeing with the rule, and assuming the flash was coming from somewhere else.

The rule has to be present on the first frame

Which means it has to be in the page's stylesheet, not in the component. It's now in src/app/template.css:

.js tear-line:not(:defined) {
  visibility: hidden;
}

The .js prefix is how I keep the property I liked about self-injection. An inline script in <head> (src/app/layout.tsx:70) does one thing:

document.documentElement.classList.add('js')

It's inline and synchronous, so the class is on <html> before anything can match against it. If scripting is off or the bundle dies, the class is never stamped, the rule never applies, and you get the raw markup rather than a permanently blank box. Same guarantee, moved to a place that's actually there on the first paint.

This was the second time on this project I'd hit the same shape. The landing page's scroll reveals had it too: ScrollReveals was setting each element's hidden opacity from a useEffect, which runs after hydration, which is after the browser has already painted the server HTML fully visible. Every load was doing paint the whole page, blank the parts that reveal, fade them back in. No amount of tuning the IntersectionObserver fixes that, because the wrong frame has already been shown by the time the JS exists. Hidden state belongs in CSS; the runtime should only ever move things toward visible, which is a direction it can't be late for.

Hiding is only half of the flash

Once nothing was visible during the upgrade, the page still moved on arrival, because reserving zero space and then dropping in a full receipt is its own layout shift. Two more pieces:

.panel-result,
.tl-stage {
  min-height: 260px;
}

tear-line[data-ready] {
  animation: tl-arrive 0.4s cubic-bezier(0.22, 1, 0.36, 1) both;
}

260px is a guess. Being roughly right and stable beats being exactly right one frame late.

The data-ready attribute took one more correction. My first version set it at the top of the render path, and the receipt faded in half-drawn: paper present, tear and barcode not yet. The clip path and the barcode are both built from the same seeded stream and get applied later in the same method, so "ready" had to mean after all three:

// The host page fades in on [data-ready]. Set on the next frame, after the
// paper, the tear and the barcode are all in place.
if (!this.hasAttribute('data-ready')) {
  requestAnimationFrame(() => this.setAttribute('data-ready', ''));
}

The attribute is only set once, so re-renders (changing seed, changing width) don't re-trigger the entrance animation. And the whole thing is dropped under prefers-reduced-motion: reduce.

Verified the same way I found it: throttle the script to 1.2s, watch the whole pre-upgrade window. Hidden throughout, no unstyled text at any point, no shift when it arrives.

The part I'd keep from this: a rule whose job is to cover the window before a script runs cannot be delivered by that script. That sounds obvious written down. It did not look obvious in the diff, because the code was correct, well-commented, and answering a question about a completely different failure than the one I had.

Ranking a dashboard by funnel depth, not counts

Isaiah Kim — Mon, 27 Jul 2026 14:21:10 +0000

I had a metrics page that told me nothing. Page views per host, signups, a couple of Stripe lines, all rendered as cards in a grid. Every morning I'd look at it, feel vaguely informed, and then go build whatever I'd already decided to build the night before. That's the tell: if the dashboard never changes what you do next, it isn't a dashboard, it's decoration.

So I rewrote it around one question — how far do people actually get — and let that ordering decide what I see first.

The ordering is the product

Kynth Studios ships a lot of separate products on separate hosts: FetchDue chasing overdue invoices for agencies, BenchFile doing NYC Local Law 84 filings, CertScope determining CPSC scope per SKU, ParseRail for developers integrating against the API. They don't share a funnel shape in any interesting way, but they do share a funnel depth: someone lands, someone starts the demo, someone finishes the guided run, someone starts signup, someone finishes it, someone activates.

Depth is the only axis where those products are comparable. A traffic number tells me a host got attention. A depth number tells me where attention stopped.

So the model is a stage list plus a rollup per product:

// stages are ordered; index IS the depth
const STAGES = [
  'demo_start',
  'demo_complete',
  'signup_start',
  'signup_complete',
  'activated',
] as const

type Stage = (typeof STAGES)[number]

type ProductFunnel = {
  slug: string
  counts: Record<Stage, number>
}

// deepest stage a product has ANY reach into
function depth(f: ProductFunnel): number {
  for (let i = STAGES.length - 1; i >= 0; i--) {
    if (f.counts[STAGES[i]] > 0) return i
  }
  return -1
}

// the first stage that eats everything
function stall(f: ProductFunnel): Stage | null {
  for (let i = 1; i < STAGES.length; i++) {
    const prev = f.counts[STAGES[i - 1]]
    if (prev > 0 && f.counts[STAGES[i]] === 0) return STAGES[i]
  }
  return null
}

depth sorts the list. stall is the label on each row. Everything else on the page is subordinate to those two functions.

Vanity metrics are the ones with no stage below them

The rule I ended up with for what stays on the page: a metric earns its spot if there's a next stage it's supposed to feed. Page views feed demo starts. Demo starts feed completions. Completions feed signup starts.

Page views on their own feed nothing I control, so they came off. Same with a top-level "total events" number, which mostly moved when I deployed something. Anything that only ever goes up and never implies an action is a metric you can watch forever without learning anything.

The one that hurt to cut was a combined cross-product total. It looked healthy. It was healthy — it just averaged a product where people finish the demo together with one where nobody gets past the landing page, and the average was never the thing I needed to know. Now every row is per-product and the sort does the summarizing.

Keep the data engine away from the rendering

The part I'd do again on any dashboard: the thing that computes stages, predicates, sorts and rollups is framework-agnostic and knows nothing about React. It takes events, returns ProductFunnel[] sorted by depth. The components take that array and draw it.

That split has paid off more than once. When a number looks wrong, the first question is which half is wrong — and because the contract between them is a plain typed object, I can answer it by calling the rollup in a test and reading the output. A rendering bug costs nothing on the engine side. A rollup bug is visible without a browser.

It also means the same rollup feeds a morning summary that isn't a web page at all. Same functions, different renderer.

What the page actually looks like now

One list. Products sorted deepest-first, each row showing its stall stage and the counts on either side of it. FetchDue near the top because there's a one-click live demo with no signup form in front of it, so people reach the guided run. The compliance products — BenchFile, GoodStanding, DoseTrace — sit lower, because a done-for-you filing service has a different entry shape and the interesting stage is further along.

That ordering is doing real work. Last week it put a product at the bottom of the list whose landing page I thought was fine, with a stall at demo_start — plenty of people arriving, nobody starting. That's a specific bug in a specific place, which is more than the old grid ever gave me.

FetchDue has no customers yet and the dashboard says so; the honest zero is on the page next to a link to the live product and a recorded run. I'd rather look at a zero I can locate than a total I can't.

The bit I'd tell someone rebuilding theirs

Pick the axis before you pick the charts. I spent longer than I should have arranging cards, and none of that time mattered, because the layout question and the ranking question are different questions and only one of them changes what you build tomorrow.

Sorting by depth also has a property I didn't expect: the top of the list is the least urgent thing. The products getting people deepest need the least attention. Reading the page bottom-up is the actual workflow, which means the sort could arguably be reversed — I've left it deepest-first because I want the ceiling visible, and I go to the bottom on purpose.