DEV Community: Daniel Pertu

Three of our parallel workers were interrupted mid-file, and their unreviewed output shipped with 22 lines of edits

Daniel Pertu — Tue, 10 Nov 2026 09:37:45 +0000

Four days ago we shipped 50 pages, one per named assessment, as a trial. This weekend we did the other 281. The site now has 331 of them, one per test, across 56 vendors, at /games/<vendor>/<test>, and the live sitemap went from 530 URLs to 835.

The content is not the interesting part. The geometry is.

One file per vendor, because 31 branches had to land in one directory

All 331 pages come out of one registry, and that registry is 59 files in a directory with an index that does nothing but concatenate them:

/**
 * Every per-test page, one content file per provider.
 *
 * One file per provider (two for TestGorilla) so that the workers filling them
 * in never edit the same file. Everything that needs to know about these pages
 * (the routes, the sitemap, the provider hubs' link lists, the guard test)
 * reads from here.
 */
export const TEST_PAGES: TestPageEntry[] = [
  ...acerTestPages,
  ...alvaLabsTestPages,
  ...amberjackTestPages,
  ...
];

59 files, 40,183 lines, 2.38 MB of TypeScript. The index adds one import line and one spread line per file, which means two branches working on two vendors produce a conflict only in the import block, where git resolves both sides cleanly because they are different lines in alphabetical order. 18 named branches, 10 unnamed worktree branches and 3 recovery branches merged into the integration branch over an evening, and the conflicts were all in that index.

This is a rule we arrived at the hard way: if parallel work has to touch a shared file, make the shared file a list of one-line entries. Anything richer, and you spend the evening resolving.

Three workers were interrupted, and we committed their work anyway

Partway through, three of the workers stopped mid-file. Not failed, not finished: interrupted. The run that recovered them made three commits with the same message, in the same second:

4abfafa2 WIP: interrupted game-pages worker (unreviewed, unfinished)
  lib/games/test-pages/faa-atsa.ts | 815 +++++++++++++++++++++++-
dd57670e WIP: interrupted game-pages worker (unreviewed, unfinished)
  lib/games/test-pages/criteria.ts         | 497 ++++++++-------
  lib/games/test-pages/revelian.ts         | 323 +++++++-----
  lib/games/test-pages/test-partnership.ts | 593 ++++++++++--------
c743dac2 WIP: interrupted game-pages worker (unreviewed, unfinished)
  lib/games/test-pages/harver.ts | 1054 ++++++++++++++++++++++++++-

The commit message is the whole technique. A dirty worktree from an interrupted job is a thing you are afraid to touch, and so is a branch whose state nobody can describe. A commit that says "unreviewed, unfinished" in its subject line is neither: it is a checkpoint you can diff, review, fix, or throw away, and nothing silently merges it while you are not looking.

The part I did not expect: all three were nearly shippable. Measured from the WIP commits to today's main, those five files took 22 insertions and 20 deletions between them to go live. faa-atsa.ts needed exactly one changed line out of 815.

That is not an argument that unreviewed output is fine. It is an argument for committing it before you judge it, because the alternative, on the night, is deleting 2,000 lines you would have kept.

331 route files, all exactly ten lines

Every page's route file is this, and there are 331 of them:

import { TestPageShell, testPageMetadata } from '@/components/games/TestPageShell';
import { requireTestPage } from '@/lib/games/test-pages';

const entry = requireTestPage('aon', 'gapchallenge');

export const metadata = testPageMetadata(entry);

export default function Page() {
  return <TestPageShell entry={entry} />;
}

Normalise away the two string arguments and all 331 files hash to the same value. That is deliberate, and requireTestPage is the reason it works: it throws rather than returning undefined, so a typo in a route file is a build failure and not a page that renders an empty shell in production.

A dynamic [test] segment would have been fewer files. We had one, for the /tests cluster, and deleted it last week. Static folders make the route space enumerable, which is what the guard test needs and what the next section is about.

The failures a content registry has, and the near miss

 * Nothing renders these pages until someone visits them, so the mistakes that
 * matter are invisible in review: a registry entry with no route folder (no
 * page, but a sitemap URL that 404s), a folder with no entry (a build that
 * throws), a game id from another provider, a title that blows the length
 * budget, or a path that robots.txt blocks because a game route happens to be
 * its prefix.

That last one nearly happened. Our robots.txt is 850 lines, of which 780 are plain Disallow prefixes, and 372 of those are the individual practice game routes that sit directly under /games/. Eight of the new page slugs are byte-identical to one of those disallowed ids:

/games/arctic-shores/analysis
/games/arctic-shores/arrows
/games/arctic-shores/balance
/games/arctic-shores/order
/games/arctic-shores/patterns
/games/arctic-shores/team-sales
/games/arctic-shores/tickets
/games/arctic-shores/token-search

Disallow: /games/balance does not prefix-match /games/arctic-shores/balance, so all eight are crawlable. They are safe entirely because of which segment the word sits in. One rule written as /*balance instead and eight pages quietly leave the index, which is why the test runs the real robots() export over the real route list rather than trusting anybody's reading of it:

const blocker = plainPrefixes.find((prefix) => route.startsWith(prefix));
expect(blocker, `${route} is blocked by "${blocker}"`).toBeUndefined();

The other check worth copying is the one for internal links. Each entry has a related list, 855 links across the set, and the test resolves each href to a folder on disk and asserts a page.tsx exists. Writing a link to a page a parallel branch has not created yet is the single most common mistake in this kind of round.

The ledger

Counts I pulled out of the registry by importing it rather than grepping it, because regex counting over TypeScript has lied to me twice:

331 pages over 56 vendors, 2 to 17 pages each, median 6
1,971 source URLs, 804 of them distinct, over 208 hosts. The biggest single host is a web archive with 99
one page rests on one source, another rests on 22
1,857 fact rows, 1,649 sections, 1,277 FAQs, 197,861 words
1,943 keywords, 1,934 distinct, so nine collisions in all
every metaTitle between 33 and 48 characters, every description between 124 and 158, enforced rather than trimmed
359 references to practice games, 358 distinct, which leaves 14 of our 372 games with no page of their own and 15 pages covering more than one game, because some vendors sell levels of a test that candidates search for as one thing

See it

/games/aon/gapchallenge is one of them; the index of a vendor's set is its hub, for instance /games/arctic-shores.

The contrast worth checking yourself is what happens when you make a path up. Ask for /games/aon/zzz and you get a real 404 with noindex, follow, because that URL space is 331 static folders and nothing else. Ask for /games/zzz, one segment up, and you get 200 with the title "Game Not Found" and two conflicting robots tags in the same document, because that space has a dynamic segment which reads the session and commits its head before the body can decide the game does not exist. Same site, two URL spaces, and only one of them tells a crawler the truth. The one-segment case is on the fix list and the folders are the reason the new one never had the problem.

The machine-readable summary of the whole library is at cogniprep.app/llms.txt, which is generated now rather than typed, and its first line will tell you the same 372 and 56 this post does.

We built a buy-everything pass, deleted it 26 minutes later, and the thing that replaced it needed no new table

Daniel Pertu — Tue, 10 Nov 2026 09:34:52 +0000

At 19:34 one evening last weekend we merged an All Access pass: one payment for every provider on sale plus the premium feature set, priced per region, open to every discount programme. 26 files, 2,029 insertions. A 279-line checkout route, a 240-line pricing card, 463 lines of tests, a rebuilt pricing page, a new clause in the terms.

At 20:01 it was deleted. 39 files, 828 insertions against 1,413 deletions: the route, the card, the pricing module, the tests, the purchase intent, every type, and both the terms and FAQ wording.

It never reached production. Both merges happened inside a feature branch, and that branch reached main as a single commit a day later, so no deployed state ever contained it. I checked rather than assuming, because "we shipped and reverted" and "we never shipped" are different stories and only one of them is true here: walk main's first-parent chain, ask git cat-file -e <commit>:app/api/all-access/checkout/route.ts at each step, and the file is in none of them.

The reason for the delete was commercial, not technical: a pass that bundles everything prices our most motivated customer at a discount and teaches everyone else to wait for the bundle. What the owner wanted instead was a reason to come back.

The replacement is a row in a table that already existed

Every paid purchase now mints a personal code for 20% off the next one, good for 30 days. The implementation is one new module plus a terms file, and zero migrations, because the code is a row in nurture_discount_codes, the table that already holds the codes we email people:

 * The code is a row in `nurture_discount_codes`, so it is reserved, claimed and
 * released by exactly the same paths as an emailed nurture code.

Two fields make it a different kind of code. campaign is next_purchase, and the table's (user_id, campaign) unique index is the whole of "one live code per buyer". product_type is 'any', where an emailed code names the single product it discounts.

The entire minting rule is one upsert:

const [row] = await db
  .insert(nurtureDiscountCodesTable)
  .values({ id: crypto.randomUUID(), user_id: userId, campaign: NEXT_PURCHASE_CAMPAIGN, ...fresh })
  .onConflictDoUpdate({
    target: [nurtureDiscountCodesTable.user_id, nurtureDiscountCodesTable.campaign],
    set: fresh,
    // Only a spent or lapsed code is replaced; a working one is left alone.
    setWhere: or(
      eq(nurtureDiscountCodesTable.status, 'claimed'),
      lte(nurtureDiscountCodesTable.expires_at, now)
    ),
  })
  .returning({ code: nurtureDiscountCodesTable.code });

Three behaviours out of one statement: no row yet, mint one; a claimed or expired row, replace it with a fresh code and clear the reservation and Stripe columns; a row that is live and unspent, leave it exactly as it is, because handing somebody a second code while their first one still works is a support ticket waiting to happen. setWhere on a conflict target is the feature that makes that a single round trip, and it is the one bit of ON CONFLICT I always have to look up.

mintNextPurchaseCode never throws. It runs on the webhook's post-grant path, where the sale is already delivered, so the worst outcome of a database hiccup has to be a missing code and not a failed webhook.

The ordering is the feature

/**
 * Gives a paying buyer their code for a discount on the next purchase. Runs after
 * the nurture claim above, so a purchase made with the previous code finds it
 * claimed and earns a fresh one. On every delivery, like the settlement: the
 * upsert keeps a live code, so a retry changes nothing. Never throws.
 */

Mint after the purchase's own code claim settles, and the thing chains: spend your code, the row goes to claimed, the upsert sees a spent row and replaces it. Mint before, and the buyer's live-but-about-to-be-claimed code is kept and they get nothing for the purchase they just made. Same two function calls, opposite behaviour, and no test would have told us which order was right without somebody writing down what should happen.

The cost of reusing the table was one discriminator in five places

This is the part I would want to read if somebody else wrote it, because reuse is never free.

product_type: 'any' is a new value in a column every code path compared with ===. So the match check gained a second arm:

-  if (row.product_type !== params.productType) {
+  // A next-purchase code names no product and is good for any of them.
+  if (row.product_type !== params.productType && row.product_type !== ANY_PRODUCT_TYPE) {

the eligibility query gained an or, and the label in the UI became conditional on the campaign rather than a constant string.

The sharper one was invisible. A row in nurture_discount_codes doubles as the marker for "we emailed this person recently", and every lifecycle campaign skips anyone who has one. Dropping a next-purchase code in that table would therefore have silently muted every lifecycle email for a month after each purchase. The fix is a <> in five candidate queries, and the test reads the generated SQL rather than trusting the builder:

const query = new PgDialect().sqlToQuery(mocks.execute.mock.calls[0][0] as SQL);
expect(query.sql).toMatch(/nurture_discount_codes\.campaign <> \$\d+/);
expect(query.params).toContain(NEXT_PURCHASE_CAMPAIGN);

describe.each over the five campaigns, so adding a sixth campaign that forgets the exclusion fails in a file whose name says what it is about.

Two small things

The code alphabet is shared with the emailed codes and omits the characters people mistype:

/** Same unambiguous alphabet as the emailed codes (no I, O, 0, 1). */
const CODE_ALPHABET = 'ABCDEFGHJKLMNPQRSTUVWXYZ23456789';

32 characters, drawn with crypto.getRandomValues into a Uint32Array, so byte % 32 carries no modulo bias: 32 divides 2^32 exactly. Pick an alphabet whose length is a power of two and that whole class of nitpick disappears.

And the percentage is a constant with a pointed comment:

/** Percentage off the next purchase. Quoted in copy; never type the number. */
export const NEXT_PURCHASE_DISCOUNT_PERCENT = 20;

/** How long a minted code can be spent for. Terms section 5.4 states the same; change both. */
export const NEXT_PURCHASE_CODE_VALIDITY_DAYS = 30;

"Change both" is a comment admitting there is no test pinning the constant to the legal text. There should be. It is on the list.

See it

Open the pricing page and search for "All Access": zero hits, in the rendered text and in the raw HTML. Search for "20% off" and you get the offer stated twice, once in the explainer and once in the pricing FAQ, both of them interpolating the two constants above rather than typing the numbers. Clause 5.4 of the terms names the code and the 30 days, and the policy version reads 1.13.0.

The code itself appears on the purchase confirmation and under "What you own" in the dashboard, served by a route that returns it only while it can still be spent, so there is nothing to see there without buying something.

An evening's work, 2,029 insertions deleted, and the shipped version is one upsert and a <>. That is a better trade than it sounds.

We sign the content type and the byte length into the upload URL, then re-read the file anyway

Daniel Pertu — Tue, 10 Nov 2026 09:26:45 +0000

We shipped a form this week for the one support ticket we most want people to open: "the practice did not match my real test". It is also how a buyer claims our refund guarantee, so the fields are structured rather than free text, and it accepts up to three screenshots.

Three design decisions in it are worth writing down.

No schema change, because the fields live in a message

A mismatch report is an ordinary support ticket. Type bug, category practice-mismatch, and the structured fields ride in the meta column of the opening message:

const meta: MismatchReportMeta = {
  kind: MISMATCH_CATEGORY,
  provider,
  gameId: gameName ? gameId : null,
  employer,
  satOn,
  providerUnlocked: dbUser?.unlocked_providers?.includes(provider) ?? false,
  screenshots: stored,
};

The whole feature added zero migrations. Every existing thing a ticket can do (threading, email replies, the admin queue, cascade on account deletion) works on day one because it is a ticket.

The field I would point at is providerUnlocked. It is a copy, at report time, of whether that account had bought that provider. The live answer is one query away, so copying it is redundant by every normal rule. But the report may become a refund claim, and the thing that matters then is whether they had bought it when they reported the mismatch, not whether they still have it when somebody reads the ticket three days later. A denormalised boolean is the right call when the question is about a moment.

The upload binds type and length, and the server does not trust that

Screenshots go straight from the browser to private object storage through a presigned PUT, so a 5 MB file never passes through a serverless function. The signature covers more than the key:

return getSignedUrl(getClient(), command, {
  expiresIn: UPLOAD_URL_TTL_SECONDS,
  signableHeaders: new Set(['content-type', 'content-length']),
});

Content type and exact byte length are both signed, so the upload has to be the file the server already approved. That is the part most tutorials stop at, and it is not enough, because it only holds if the storage provider enforces the signed headers and if the client is the one we wrote. So when the report itself arrives, the route reads the object back:

// Re-read what is actually in storage. The upload URL bound type and size,
// but this is the check that does not depend on the client or on R2
// enforcing the signed headers.
let inspections;
try {
  inspections = await Promise.all(screenshots.map((key) => inspectScreenshot(key)));
} catch (error) { ... }

inspectScreenshot is a HEAD for the size plus a 12-byte ranged GET for the magic bytes, which is about as cheap as a read gets. Then the sniffed type has to equal the type that key was issued for:

if (!found || !found.sniffedType || found.sniffedType !== expected ||
    found.size > MISMATCH_LIMITS.screenshotMaxBytes) {
  invalidKeys.push(key);
}

Anything that fails is deleted from storage before the 400 goes back, and the response names the failing keys so the dialog can mark those three thumbnails rather than making the person start again.

The sniffer itself is 38 lines of byte comparisons for the three types we accept, with the only comment that matters sitting on top of it:

 * Identifies a PNG, JPEG or WebP from its first bytes, or null for anything
 * else. The declared content type is only a claim; this is what the file is.

It lives in a module with no server-only imports, which means the browser dialog runs the same checkScreenshot the route runs. One definition of "acceptable image", two call sites, no drift.

Two smaller choices in the same area. The admin thumbnail is a presigned GET with a ten minute life that forces ResponseContentType to the type we verified and ResponseContentDisposition: 'inline', so whatever the stored object claims about itself is irrelevant to the browser rendering it. And if one screenshot cannot be signed, it keeps a null URL and the admin view says so, rather than a storage hiccup failing the whole ticket.

A cascade cannot reach object storage

This is the bug we nearly shipped. Ticket rows cascade when an account is deleted. The files those rows point at do not.

/**
 * Deletes every screenshot a user has uploaded. For account deletion: the
 * ticket rows cascade with the account, but the objects they point at do not.
 * Returns how many objects were removed.
 */
export async function deleteUserScreenshots(userId: string): Promise<number> {

It pages ListObjectsV2 by the user's own prefix and batch-deletes, and it is wired into both the self-serve delete and the admin delete, as a best-effort step before the database work:

// Support screenshots live in object storage, which the cascade cannot
// reach. Same best-effort rule as the calendar revoke above.
await deleteUserScreenshots(user!.id).catch((error) =>
  logError('Failed to delete support screenshots before account deletion', error)
);

Every object lives under support/mismatch/<userId>/, which is what makes a prefix delete correct and also how the route proves a key in a submitted report belongs to the person submitting it. The feature's flat layout is doing two jobs.

That commit also did the part that is not code: a new paragraph in the privacy policy naming the new category of data, the storage provider entry extended, the retention line amended, and the policy version moved from 1.9.0 to 1.10.0. If you add a place where personal data lands and you do not move that number, the policy is now wrong and nothing will tell you.

Two details only a phone exposes

The file input's accept attribute lists exactly the three types we take:

/** The `accept` attribute for the file input. Listing only these makes iOS hand over HEIC photos as JPEG. */
export const SCREENSHOT_ACCEPT = SCREENSHOT_TYPES.join(',');

An iPhone screenshot of an assessment is a HEIC file. Name the types you want and iOS converts on the way out; name image/* and you get HEIC, which fails the sniffer, which is a dead end for the person reporting a real problem.

And the date field validates one day into the future:

/**
 * Whether a YYYY-MM-DD string is a real calendar date no later than tomorrow
 * (UTC). One day of slack covers anyone whose local date is ahead of UTC.
 */

Someone in Auckland reporting a test they sat today should not be told they are reporting a test from the future.

See it

Open our privacy policy and search for "screenshots". Four hits: the new paragraph describing what a mismatch report stores, the storage provider entry, the line that says screenshots are deleted with your account, and the retention row. The header reads "Last updated: 8 November 2026 · Version: 1.10.0". The refund guarantee the reports feed is clause 5.3 of the terms, at version 1.13.0.

The form itself sits behind an account on the help and support pages, and there is a link to it on the screen at the end of a practice run. Everything it reports about is on the open side of the site: the test library and the guides.

The honest summary: the presigned upload took an afternoon, the second check took an hour, and the twenty lines that delete the objects when an account goes are the only part of it I would have been embarrassed to leave out.

Our employer pages now name the tests, and three different sentences say who told us

Daniel Pertu — Tue, 10 Nov 2026 09:24:49 +0000

A candidate interviewing at UBS wants to know which tasks UBS sends, not which tasks the vendor sells. We have 180 employer guides and until this week none of them answered that, because answering it honestly is hard: employers almost never publish the names of the tests they use.

So the new module is small on purpose. 21 lineups, covering 21 of the 180 employer pages, 10 providers, 50 named tasks. The component returns null for the other 159.

export function EmployerTaskLineups({ slug, employer }: { slug: string; employer: string }) {
  const lineups = taskLineupsForEmployer(slug);
  if (lineups.length === 0) return null;
  ...

One field decides the heading and the attribution

The interesting part of the type is a three-value union:

/**
 * - `named`: the employer or the vendor names the tasks.
 * - `described`: the employer describes each task in detail without naming it,
 *   and the descriptions match the vendor's own task descriptions.
 * - `reported`: a third party (candidate reports or a prep site) names them.
 */
basis: 'named' | 'described' | 'reported';

It is not metadata. It changes what the page says, in two places. The heading:

{lineup.basis === 'reported'
  ? `${provider} tasks reported at ${employer}`
  : `${provider} tasks ${employer} uses`}

and the line under the list:

const lead =
  lineup.basis === 'reported' ? 'Reported by '
  : lineup.basis === 'described' ? 'Described, not named, in the '
  : 'Source: ';

Of the 21 lineups, 19 are named, one is reported and one is described. The described one is the reason the field exists at all. Procter and Gamble's careers material walks through three interactive assessments in detail without ever naming them: fill the gaps in equations, pick the branch that reorders the symbols, recall the dot positions. Those are three named tasks from a vendor we cover, and matching the descriptions is a judgement call, so the page says it is a judgement call. The heading still says P&G uses them. The line underneath says "Described, not named, in the P&G Interactive Assessment guide, checked 2026".

Compare the single reported entry, where it reads "Reported by WikiJob, 2025", and the heading changes to "Arctic Shores tasks reported at PwC". Same component, different claim, different sentence.

"checked 2026" rather than a year we made up

Every lineup carries a source with a year, and the year means different things:

source: {
  url: string;
  label: string;
  /** Year the source dates from, or the year it was checked live if undated. */
  year: number;
  undated?: boolean;
};

18 of the 21 sources are undated careers pages, so the rendered line says checked 2026, not 2026. One line of code, and it stops a careers page with no date on it from acquiring one in our markup.

The other number worth knowing: those 21 sources sit on only 13 hosts, and nine of the 21 come from one vendor's own customer case studies. The pattern across the whole sweep is that the vendor will tell you which employers it sells to long before the employer will tell you which vendor it buys from.

The list degrades in two steps and looks the same either way

Each task optionally carries the id of our practice game for it, and the name becomes a link to that test's page if one exists:

const page = task.gameId ? testPageForGame(task.gameId) : undefined;

Of the 50 tasks, 31 render as links. Ten carry no game id at all, because the employer names a stage we have no practice for and leaving it out would misrepresent their process. Another nine do have a practice game but no per-test page yet, so testPageForGame returns undefined and they render as plain text. Eight of those nine are the same aptitude test, reused through a shared constant across eight employers:

const GIA: LineupTask = { name: 'Aptitude assessment (GIA)', gameId: 'thm-gia' };

The reader cannot tell the two cases apart, which is the point. A task you cannot practise with us still belongs on the list.

The guard test generates one case per lineup

for (const lineup of TASK_LINEUPS) {
  const label = `${lineup.employerSlug} / ${lineup.provider}`;

  it(`${label}: belongs to an existing employer page`, () => {
    const page = path.join(process.cwd(), 'app', 'employers', lineup.employerSlug, 'page.tsx');
    expect(existsSync(page), `missing ${page}`).toBe(true);
  });
  ...

A loop that emits an it per entry rather than one it with a loop inside costs nothing and buys you a failure message that names the employer. The assertions are the ones a sourced claim needs: an https source with a non-empty label, a year between 2015 and this year, at least one task, no em dashes anywhere in the entry, at most one lineup per employer and provider, and the one that catches real mistakes:

const game = GAMES.get(task.gameId);
expect(game, `unknown game id ${task.gameId}`).toBeDefined();
expect(game?.provider).toBe(lineup.provider);

A task cannot point at a game belonging to a different vendor. That is exactly the slip you make at 1am when two providers both sell something called a numerical reasoning test.

One last detail, since every list item here is a tappable link on a phone: the anchors carry min-h-11 sm:min-h-0, so they are 44px targets on a phone and ordinary inline text on a desktop.

See it

Open the UBS guide and you get four named tasks with "Source: UBS early careers page, checked 2026" under them. PwC says "reported at" in the heading and "Reported by WikiJob, 2025" underneath. Procter and Gamble is the described one, and its list is an <ol> rather than a <ul>, because that source gives the tasks in the order candidates sit them.

Then open Amazon and search for "Source:". Nothing, because there is no lineup for it and the section does not render. That is 159 pages waiting for somebody to publish something.

The full set is linked from /employers.

Worth contrasting with the other content type we shipped the same day: on our per-company interview question pages, every question carries the URL it was reported at and the page renders none of them. Here the source is the first thing under the list. The difference is what the claim is about. "These are the questions people report" is a claim about an aggregate. "This employer uses these tests" is a claim about a named third party's hiring process, and a reader deserves to see who said it before deciding whether to believe us.

One wrong sentence about a vendor lived in eleven files on our site

Daniel Pertu — Tue, 10 Nov 2026 09:22:44 +0000

Our site explains assessments that other companies sell. That means most of our content is a claim about somebody else's product: how long their test runs, how many items it has, whether you can retake it. Every one of those claims can go stale without us touching a line of code, because the vendor ships a new version and says so on their own help centre.

Last weekend we read the vendors' own documents again and fixed what they contradicted. Thirteen commits, 160 distinct files, 1,525 insertions against 1,371 deletions, and not one line of behaviour changed. It was all prose.

Here is what the sweep actually looked like.

The one that spread the furthest

We said that an AssessFirst result stays valid for twelve months and that an early reset needs the recruiter to ask. The vendor's current documentation says something different: a recruiter can invite you to retake at any time, and results no longer expire after a year. One of their older help articles still says they do, which is presumably where ours came from.

One sentence, and the diff touched eleven files:

app/blogs/assessfirst-brain-swipe-drive-explained/page.tsx
app/cheating/assessfirst/page.tsx
app/employers/lcl/page.tsx
app/employers/sncf-reseau/page.tsx
app/games/assessfirst/page.tsx
components/games/af-swipe/AFSwipeGame.tsx
docs/providers/assessfirst.md
lib/cheating/registry.ts
lib/games/providers/assessfirst/insights.ts
__tests__/assessfirst/af-registration.test.ts
__tests__/assessfirst/af-scorers-feedback.test.ts

A hub page, two employer guides, a blog article, a strategy guide, the instruction screen a candidate reads before a practice run, the registry that feeds several of those, the research dossier it all came from, and two tests. Two test assertions moved with it. One of them used to check only that the copy mentioned a year, which is exactly the assertion that would have let the wrong sentence sit there forever:

-      expect(text).toMatch(/year/);
+      expect(text).toMatch(/recruiter invites you to retake/);

The one we invented

This is the one I would rather not publish. On the Cappfinity strengths assessment we had written a confident, actionable mechanism:

Cappfinity records not only what you choose but how quickly and confidently you choose it. The reasoning is that fast, decisive answers to options fitting your genuine strengths signal authentic preference, whereas a slow answer suggests you are constructing a response rather than reporting one, so it can carry less weight.

The vendor's own candidate help says its behavioural questions are untimed, apart from video and written responses, and that where an assessment is time recorded you are told in advance. So our paragraph was not a stale figure. It was a theory, written with the cadence of a fact, that told readers to hurry when the vendor tells them not to overthink. The section heading went from "How you answer is part of the answer" to "Check whether you are being timed", and the advice is now: read the instructions, and if a section says it is time recorded then work quickly, otherwise take the time you need.

A wrong number is embarrassing. A wrong mechanism changes what somebody does in a real assessment.

The one where our numbers described a product generation that had moved on

Our SHL figures were not invented. They were right about a previous generation. "Around eighteen questions, roughly seventeen to twenty-five minutes, roughly 75 seconds a question" described the older multiple-choice Verify tests; the current Interactive versions allow 18 minutes for up to ten questions and have you build charts and fill in spreadsheets. "Inductive Reasoning is 24 shape-sequence items in about 24 minutes" became "up to 15 items in 18 minutes on shape and symbol sequences, and the older multiple-choice version up to 18 in 24 minutes".

Two habits came out of that one. Name the generation, because both are in the field and a candidate's invitation decides which they get. And write "up to", because the tests are adaptive and a fixed count is a promise we are not in a position to make. The page now says so in plain words: "These are SHL's maximums. The tests adapt to your answers, so you may see fewer questions."

The one that went the other way

Not every correction removed a claim. One added one back.

For the LTP G-test our copy was carefully hedged: "LTP does not publish its time limit; preparation sites report 20 minutes, which is what our version uses." The hedge was wrong. LTP's own candidate portal does publish it, in Polish, and the figure is the same 20 minutes. The code comment that used to warn the next reader off now carries the quote instead:

// LTP's portal instruction: "50 zadan, na ktorych rozwiazanie masz 20
// minut" (see lib/games/test-pages/ltp.ts for the source).

The reverse case also turned up: on one Arctic Shores task we had "Rounds: reported as 10, 20 or 30". Those three numbers are a prep site's own practice settings, not a fact about the real task. They are now "Not published", which is less satisfying and true. Elsewhere a single word went: an unsourced "free" came off a card, because nobody had checked whether that one is free.

Why it was 160 files and not one constant

The obvious engineering reaction is that a figure restated in eleven places is a missing constant. We thought about it and left it alone.

The 160 files break down as 55 instruction components, 36 modules under lib/games, 19 files under app/games, 19 blog articles, 14 employer guides, 7 strategy guides, a research dossier and 4 test files, plus five singletons. None of those surfaces wants the same sentence. A hub needs one line of orientation, a per-test page needs the format in detail, an employer guide needs it in the context of that employer's process, an instruction screen needs the one number that matters in the next thirty seconds. A shared SHL_VERIFY_NUMERICAL_DURATION would be interpolated into eleven sentences whose framing is the thing that actually goes wrong.

What is missing is not a constant. It is the review date, which these pages now carry per entry, and the dossier that every line traces back to. The sweep is the cost of writing prose about somebody else's product, and it is a cost that recurs.

See it

Open the AssessFirst strategy guide and search the page for "twelve months". Nothing. Search for "recruiter invites you" and you get nine hits, which is the new rule restated in every place the page needs it.

Then open the SHL hub and search for "24 questions in 24 minutes": gone. "Verify Interactive" appears eleven times. On the Cappfinity tips article, "time recorded" appears five times and "how quickly and confidently" appears zero. On the LTP G-test page, "preparation sites report" is gone and the 20 minutes stayed.

The practice itself is at cogniprep.app. The thing I would take from this if you run a content site about other people's products: the vendors publish more than you think, they change it without telling you, and the copy you are proudest of is the copy most likely to be a theory.

Every question on our 20 new pages carries the URL it was reported at, and the pages show none of them

Daniel Pertu — Tue, 10 Nov 2026 09:20:27 +0000

Candidates who get invited to a recorded video interview search for it by the name of the firm, not the name of the platform. "goldman sachs hirevue questions" is a real query; "video interview platform best practices" is not. Our general guide could not answer the first one, so this weekend we shipped 20 pages that do, one per firm, at /interview/hirevue-interview-questions.

The interesting part is not the pages. It is the field we built, shipped, and then stopped rendering 62 minutes later.

Every question is a claim, so every question got a URL

The content type for these pages has one unusual rule. A question is not prose we wrote; it is something a candidate reported somewhere, so each one is a record with the page it was reported on:

/** One reported question, with where it was seen (recorded, not rendered). */
export interface CompanyQuestion {
  /** The question as reported. Light paraphrase allowed. */
  q: string;
  /** The division or track it was reported for, only where the source says so. */
  context?: string;
  /** Site the question was reported on, e.g. "eFinancialCareers". Not rendered. */
  source: string;
  /** Year of the report, where the page is dated. Not rendered. */
  year?: number;
  /** Exact URL of the page the question appears on. https only. */
  url: string;
}

Across the 20 firms that comes to 271 questions. They resolve to 44 distinct URLs on 18 hosts, with a long tail: 84 questions come from one interview-advice blog, 90 from the two country editions of a finance careers site, 27 from a third, and eight hosts contribute 16 questions between them, two of them one each. 255 of the 271 carry a year, running from 2018 to 2026.

Separately from the questions, each page carries its own sources list for the stage facts and the advice: 121 URLs over 49 hosts, all https, every one opened by hand. That is where you find out how little the firms publish. The 20 pages have 146 rows describing where the interview sits in the process, how long it runs, how many questions, how much thinking time, whether you can retake. 68 of those 146 rows read "Not published." The rule in the type is that a gap stays a gap:

The format (question count, thinking and answer time, retakes) only as sources say it. Never fill a gap with the platform default.

Then we deleted the citation links

The first version rendered each question with its source underneath as a small rel="nofollow" link, because if you can cite it you should. One commit later, that came out:

-                  {count} questions from {entry.company} HireVue interviews, each linked to where it
-                  was reported. Prepare a story for each type rather than a script for each question.
+                  {count} questions from {entry.company} HireVue interviews. Prepare a story for each
+                  type rather than a script for each question.

Net effect of that commit: 17 insertions, 25 deletions, four files. The doc comment on the shell now says why.

 * Sources are kept in the data but never rendered: the owner wants only the
 * questions on the page, with no links out to the sites that reported them.
 * Each question's `url` and `entry.sources` are the record behind the page.

That reads like vanity until you look at what the page is for. Someone landing on it has an interview in three days. A row of citations under every question is 271 chances to leave for a competing prep site, and it answers a question nobody on that page is asking. The URL is not there for the reader. It is there so that the sentence above it can be checked by us, and so that nobody on the team can add a question they half remember.

So the guard test does the checking instead of the reader:

it('cites an https source on every question', () => {
  for (const entry of COMPANY_QUESTIONS) {
    expect(companyQuestionCount(entry)).toBeGreaterThan(0);
    for (const group of entry.questionGroups) {
      for (const item of group.questions) {
        expect(item.url).toMatch(/^https:\/\//);
        expect(item.source.trim()).not.toBe('');
      }
    }
  }
});

The rest of that file is the same set of failures every content registry needs guarding against: a registry entry with no route folder (a sitemap URL that 404s), a folder with no entry (a build that throws, because the lookup throws rather than returning undefined), a title over 48 characters (the layout appends 12 more), the same question listed twice on one page, a "read next" link to a page that does not exist, a path that robots.txt happens to block, and an em dash anywhere in the content.

See it

Open the Goldman Sachs page, view source, and search the HTML for efinancialcareers. Zero hits. Search for any of the hosts above and you get zero again. I ran that sweep over all 20 live pages just now: the only external hostnames anywhere in the served HTML of any of them are js.stripe.com and api.stripe.com.

Then count the questions in the rendered page: 20 on that one, which is exactly what the data holds. The page with the fewest has four, because Oliver Wyman is the firm with the least reported and the rule is that it gets a shorter page rather than a padded one. Six of the 20 firms also have an employer guide on the site, and only those six link to one, because the test fails if a link points at a folder with no page.tsx.

The practice the pages hand off to is at /interview.

Keeping the citation in the data and off the page felt wrong for about a day. It stopped feeling wrong when the first factual correction arrived and I could open the exact URL the line came from in four seconds.

Our app says: the site didn't say, so we assumed. Then it rings the field each assumption is about

Daniel Pertu — Sun, 08 Nov 2026 11:22:01 +0000

When software writes a document for you, the hard part is not writing it. It is telling you which bits it made up.

Nakodo starts a campaign by writing a brief, which how it works describes with the line that matters here: everything in it can be changed before anything happens. A brief written from a website always contains guesses, because websites do not state everything, and the app keeps those guesses alongside it. The question is what the screen does with them.

The answer is 133 lines, a panel above the document and a ring around the fields inside it, and most of the decisions in it are about not nagging.

One state, two places, no prop drilling

The panel is at the top of the page and the marks are deep inside an 859-line form, so both read from one context:

type Marks = Map<BriefPart, string[]>;

const Marked = createContext<{ marks: Marks; mark: (guesses: Assumption[]) => void }>({
  marks: new Map(),
  mark: () => {},
});

The default value is a working no-op: an empty map and a function that does nothing. That is not defensive code, it is what lets the marked fields be used on a page with no panel at all, with nothing to configure and no "if a provider exists" branch anywhere.

The marked field is the same idea again:

export function Highlight({ part, children, className }) {
  const notes = useContext(Marked).marks.get(part);
  if (!notes) return <>{children}</>;
  return (
    <div data-guess className={cn("rounded-md ring-2 ring-offset-4 ring-highlight ring-offset-card motion-safe:animate-in motion-safe:fade-in", className)}>
      {children}
      <ul className="mt-2.5 space-y-1 text-[13px] text-muted-foreground">
        {notes.map((n) => (
          <li key={n} className="flex gap-2">
            <AttentionMark label="Guess to check" className="mt-[7px]" />
            {n}
          </li>
        ))}
      </ul>
    </div>
  );
}

Unmarked, it renders its children and nothing else: no wrapper element, no class, no layout change. So all eight places in the form that can carry a guess are wrapped (six or seven of them render, depending on whether the campaign is looking for creators or for businesses), and in the normal case the component is invisible in the output as well as on screen. The ring is additive, which is the only way a highlight can be switched on inside a form without moving anything.

ring-offset-4 with ring-offset-card is the detail that makes it look deliberate: the ring sits four pixels off the field with the card's own colour in the gap, so it reads as a halo rather than a border somebody added to an input.

Two buttons, both final

<Button onClick={() => settle("approved")}>Looks good</Button>
<Button variant="outline" onClick={() => settle("fixing")}>Make changes</Button>

There is no dismiss cross. A cross invites the one behaviour this panel exists to prevent, which is making it go away without reading it. Instead there are two answers, and the important property is that they are equally final:

const settle = (how: "approved" | "fixing") => {
  setDone(how);
  if (how === "fixing") {
    mark(guesses);
    if (placed > 0) {
      requestAnimationFrame(() =>
        document.querySelector("[data-guess]")?.scrollIntoView({ behavior: "smooth", block: "center" }));
    }
  }
  start(async () => {
    await checkedGuessesAction(campaignId);
  });
};

One server action for both answers, because the thing being recorded is not which button you pressed. It is that you have been asked. A panel that reappears until you press the "right" button is a panel that gets dismissed reflexively on the second viewing.

Note the order: the local state moves first, the write goes after, inside a transition, and the result is thrown away. The comment above it is the policy:

// Saved as soon as either button is pressed, so the panel is gone next time
// too. Nothing is shown if it fails: the guesses simply come back.

That is the nicest kind of error handling to write: the failure mode of "we could not record that you read this" is "you are asked again", which is the behaviour you would have chosen anyway. Showing a red toast for it would be telling the user about a problem that is not theirs and has already been handled.

The scroll uses an attribute, not a ref

The panel has to scroll to the first marked field, which lives in a different component several levels down. The usual answers are a ref passed through context or a ref callback registry keyed by part. This does neither: the ring sets data-guess, and the panel queries for it.

That is fine here for a specific reason. The marks render in the same tick as the state change, so a requestAnimationFrame is enough to let them exist before the query runs, and "the first [data-guess] in the document" is exactly the definition wanted: the earliest part of the form with something to check. A ref registry would have given the same answer and a sorting problem.

Two caps on how loud it gets

// Two notes a part at most: past that the brief reads as a page of warnings
// instead of fields to change.
const MAX_PER_PART = 2;

and, for a guess that does not name a part, nothing is ringed at all:

for (const g of guesses) {
  if (!g.part) continue;
  // ...
}

Ringing everything for an unplaced guess would point at the whole document, which tells the reader nothing. Those guesses stay in the panel as text instead, and the follow-up copy branches on how many of each there were:

{placed === 0
  ? "Change these in the brief below."
  : loose.length === 0
    ? "We've highlighted the parts you need to change."
    : "We've highlighted where most of these go. The rest:"}

Three sentences for three states, and the third one is the only reason the split exists: a mixed case where some guesses are ringed and some are not would otherwise produce a confident sentence that is partly a lie. The whole state lives under role="status", so a screen reader hears the change rather than silently losing a panel.

Two findings

The list keys are the note text: key={n} in the marks and key={g.note} in the panel list. Two identical guesses about the same part of the brief would collide, which is unlikely and not impossible, and an index key would be fine in a list that never reorders.

The bigger one is that "Make changes" settles the guesses permanently, so somebody who presses it, gets called away and comes back tomorrow has a brief with no rings on it and no way to ask for them again. The honest fix is to record the two answers as different things after all: approved means never again, fixing means show it until the brief is saved. That is one more column and a condition, and it would mean the panel is the only part of this screen that remembers what you meant rather than only what you did.

Our setup wizard keeps the step in the URL and the answers nowhere, so Back works and a reload starts over

Daniel Pertu — Sun, 08 Nov 2026 11:20:28 +0000

Setting up a campaign in Nakodo is a wizard, which is a word that usually comes with a drafts table, an autosave, a half-finished row somebody has to clean up, and a resume link. This one has none of that, and the reason is one line of policy: nothing exists in the database until the last step before the review.

What that buys is worth the trade I will come to at the end.

The number of steps is a function

export type Step = "kind" | "where" | "businesses" | "emails" | "website" | "review";

export function setupStepList(kind: CampaignKind | null, emails: boolean): Step[] {
  return [
    "kind",
    "where",
    ...(kind === "businesses" ? (["businesses"] as const) : []),
    ...(emails ? (["emails"] as const) : []),
    "website",
    "review",
  ];
}

Two conditional steps, so the wizard is four, five or six steps long. "Businesses and places" appears only for a campaign looking for businesses rather than creators. "Daily emails" appears only on a plan that can run more than one campaign at a time, because that step is about splitting a day's allowance between campaigns and there is nothing to split when there is one. On the Free plan it never appears at all.

The list lives in its own module rather than inside the component, and the file comment says why: the review page at the end is a server component on its own route, and it has to number the steps the same way. One function, two renderers, no chance of the stepper saying "Step 4 of 5" on one page and "4 of 6" on the next.

The step is in the URL, written by the History API

const go = (s: Step) => {
  const url = new URL(window.location.href);
  if (s === "kind") url.searchParams.delete("step");
  else url.searchParams.set("step", s);
  window.history.pushState(null, "", `${url.pathname}${url.search}`);
};

No router.push. The App Router supports the native history methods and keeps useSearchParams in step with them, so a pushState updates the component that reads the step without touching the server. Moving between steps is therefore free: no request, no server render, no loading state, no revalidation of a page whose data has not changed. And because the step is a real history entry, the browser's Back button steps back through the wizard with no code of ours involved.

The first step deletes the parameter instead of setting step=kind, so the start of the wizard has one canonical URL rather than two.

The URL cannot name a step you have not reached

Putting the step in the URL means anyone can type one. The gate is three lines:

const [reached, setReached] = useState(/* ... */);
const steps = setupStepList(kind, daily !== null);
const requested = steps.indexOf(params.get("step") as Step);
const at = requested > 0 && requested <= reached ? requested : 0;

An unknown step gives indexOf of minus one, which fails the first test. A step further along than you have got fails the second. Either way you land on the first step, which is the only step that is always valid.

A client-side gate would be unacceptable if it were protecting anything. It is not: no step writes to the database, no step authorises anything, and the campaign does not exist yet. The gate is there so the screen is never asked to render a question that depends on an answer it does not have. The real validation is the server action at the end, which gets the whole set of answers in one form submission.

The reload case is handled explicitly, and it is the one place the design shows its seam:

// A reload loses the choices, so a step in the URL that can't be shown yet
// is dropped rather than left pointing somewhere else.
const stale = params.has("step") && at === 0;
useEffect(() => {
  if (stale) window.history.replaceState(null, "", window.location.pathname);
}, [stale]);

replaceState, not pushState, because a wiped parameter should not become a history entry you can press Back into.

The one URL that is allowed to skip ahead

The home page's hero is a single input. You can read it on the live page:

<input id="hero-site" name="site" placeholder="yourbrand.com"
       inputMode="url" autoComplete="url" maxLength="253" />

That address survives sign-up, through a route whose entire job is deciding where a new account lands, and arrives as /campaigns/new?step=website&site=yourbrand.com. The flow then seeds reached so the deep link is allowed:

const site = params.get("site")?.slice(0, 253) ?? "";
const [reached, setReached] = useState(() =>
  site && kind && chosen[kind].length > 0 && !daily
    ? setupStepList(kind, false).indexOf("website")
    : 0,
);

Read that condition as a sentence: if we were given a website, and the first two steps have answers that are correct by default on this plan, and there is no daily-emails step to ask about, then start at the website step with it filled in. A visitor who typed their address on a marketing page gets a one-field setup instead of a five-screen one, and the moment any of those conditions is false the whole wizard comes back.

The 253 is the maximum length of a domain name, and it appears twice: once as maxLength on the public input, once as a slice in the client that receives it. Neither is the real check, which is on the server, and both exist so the string in a URL bar cannot be a paragraph.

A disabled button that says why

Every step's Continue is disabled until that step is answered, and the reason is a value rather than a boolean:

const missing =
  step === "kind"
    ? !kind && "Choose who to look for"
    : step === "where"
      ? platformsChosen.length === 0 && "Choose at least one place to look"
      : step === "businesses"
        ? targeting.types.length === 0
          ? "Choose a kind of business"
          : targeting.locations.length === 0 && "Add at least one place"
        : step === "emails" && daily
          ? shares.total > daily.limit
            ? "Lower your other campaigns to fit your plan"
            : own < 1 && "Give this campaign at least one new email a day"
          : false;

A string or false. One expression gives both "may we continue" and the sentence printed beside the button, so a greyed-out button is never a mystery, and the two can never disagree with each other because they are the same value. Five reasons for five ways to be stuck, including two different ones inside the businesses step.

The step's choices also hold a third state worth stealing. Each platform tile is offered, locked, or absent:

export type PlatformChoice = { platform: Platform; lockedTo: string | null };

Locked means it exists but your plan does not include it, so the tile renders with a lock and names the plan that has it. Absent means it is not configured on this deployment, so it never reaches the client at all. Those are genuinely different facts and a boolean would have flattened them into one sad tile.

The trade

A reload loses your answers. That is the whole cost, and it is a real cost: five screens of choices live in useState and nowhere else, so a refresh at step four puts you back at step one with the URL quietly cleaned up behind you.

What it buys is that the database has no concept of a half-made campaign. No status: 'draft', no nightly job deleting abandoned rows, no query anywhere that has to remember to exclude them, no half-set-up campaign appearing in a list or a count or a plan limit. Every campaign row in the product is one somebody finished and launched, and what happens after that is the part worth writing code for.

If I were to spend anything here it would be sessionStorage on the answers, keyed per tab, cleared on submit. That keeps the reload honest without teaching the database a new state, which is the part I would still refuse.

Two emails about a new campaign, and whichever one goes first cancels the other for good

Daniel Pertu — Sun, 08 Nov 2026 11:18:40 +0000

A campaign in Nakodo is meant to be launched and then left alone, which how it works describes from the outside. The awkward part of that promise is the first hour. You press launch, a progress line starts moving, and then you close the tab, and whatever happens next has to reach you by email.

Two things can happen next. Either the first good fits arrive, or a day passes and none do. So there are two emails, written by two functions in the same file, and most of the design is in making sure you never get both.

The good one waits for a quorum, or an hour

The naive version sends as soon as there is one result. That is a worse email than it sounds: a campaign's first fit often arrives minutes after launch, while you are still looking at the screen that produced it, and an email telling you about one creator when thirty are coming is an email that trains you to ignore the next one.

const ENOUGH_TO_EMAIL = 5; // good fits; fewer is still sent an hour after launch
const WAIT_FOR_MORE_MS = 60 * 60 * 1000;

const ready = rows.filter(
  (r) => r.email && (r.fit >= ENOUGH_TO_EMAIL
    || (r.launchedAt && Date.now() - r.launchedAt.getTime() > WAIT_FOR_MORE_MS)),
);

A quorum with a timeout. Five good fits is worth an email immediately. Fewer is worth an email once the first hour is over, because by then the number is news rather than a progress indicator. Both senders run at the tail of every pipeline run, which is itself on a cron, so both branches are arithmetic on a timestamp the campaign already has:

// Best effort: a failed email mustn't fail the run.
await notifyFirstResults().catch((e) => console.error("Results email failed", e));
await notifyNoFits().catch((e) => console.error("No-fits email failed", e));

The query that feeds it also refuses to look back very far:

gte(campaigns.launchedAt, new Date(Date.now() - 14 * DAY_MS)),

Anything launched more than a fortnight ago is not a new campaign, and nothing that happens to it now should produce a "your first results are in" email. That line is also the safety rail for the day somebody runs a backfill: the blast radius of this email is two weeks wide, by construction.

The exclusion lives in the log, not in a column

There is no resultsEmailedAt column on the campaign. Both senders ask the audit log whether this campaign has already been written about, and the no-fits one asks about both actions at once:

sql`not exists (
  select 1 from ${auditLog} a
  where a.action in ('campaign.results_emailed', 'campaign.no_fits_emailed')
    and a.entity_id = ${campaigns.id}::text
)`,

That one in (...) is the whole mutual exclusion. A campaign that got the good email is permanently ineligible for the bad one, which matters because a campaign can genuinely go from five fits to a dry spell. And a campaign that got the bad one is ineligible for both, so the apology arrives once and is never followed by a cheerful correction a day later.

The two functions also take the same advisory lock:

const due = await withLock("results_email", async (tx) => { /* ... */ });

Not one lock each. One lock for the pair, named after the subject rather than the sender, because the thing that must not interleave is not "two runs of this function" but "two statements about the same campaign". Inside it, the rows are selected and the audit rows are inserted in the same transaction, so a second worker arriving mid-flight sees the row that makes it skip. The audit row doubling as the dedupe key is a pattern these emails all share, including the ones that are turned off in settings, which stops a switch being turned back on from releasing a flood of late mail.

The good email ends with whatever the next real step is

An email that says "you have results" and links to them is fine. An email that says what to do next has to know what the campaign is waiting for, and there are three different answers:

c.mode !== "auto"
  ? `Open the campaign to see why each one fits, and choose who Nakodo writes to.`
  : c.hasOffer
    ? `Nakodo is writing to the best of them, a few each day.${
        autoSendsSaved(c.approval) ? "" : " Their first emails wait for your approval on the Outreach tab."}`
    : `Save your proposal on the campaign's Outreach tab, and Nakodo starts writing to the best of them.`,

Three branches and a nested fourth, from two facts the query already had to fetch: whether the campaign picks its own recipients, and whether the offer it would make has been saved yet. The worst of the three, by a distance, is the last one: a campaign that found good fits and cannot act on them because something is missing. That sentence is the only reason this email is worth sending at all to that user, and it is one hasOffer away from being lost in a cheerful generic paragraph.

Both facts come straight out of SQL on a JSONB column, which is why they cost nothing:

hasOffer: hasOfferSql(campaigns.outreach),
approval: sql<string | null>`${campaigns.outreach}->>'approval'`,

The bad email names a number and a next move

The no-fits email is the one I rewrote most, because the first version was a shrug. It now says how far the search actually got, whether it is still widening by itself, and the single change that helps most for that kind of campaign:

const looked = c.checked > 0 ? `has checked ${plural(c.checked, w.one, w.many)}` : "has been looking";
// ...
`Nakodo ${looked} for ${c.name} since you launched it, but none fit well enough to write to yet. It keeps looking`
  + (c.widen ? ", and widens the search by itself when it runs dry." : "."),
c.kind === "businesses"
  ? "What helps most is more kinds of business or more places to look, under Businesses and places on the brief, or a looser Ideal business."
  : "What helps most is broader search keywords on the brief: the words creators use about their own posts, rather than your product's. A looser Ideal creator helps too.",

checked is a correlated subquery counting the rows that have been scored at all, which turns "nothing fits" into "it looked at 180 and none fit", and those are different emails to receive. The widen clause exists because the sentence would otherwise be a lie for half the accounts: a campaign with widening on is already doing the obvious thing, and telling that user to go and do it by hand is worse than saying nothing.

Both emails link to a specific tab rather than the app: the good one to the campaign filtered to its fits, the bad one straight to the brief, which is the page the email is asking you to change.

The finding

The two sends are not written the same way, and only one of them is right:

}).catch((e) => console.error("No-fits email failed", c.id, e));

That is the no-fits loop. The first-results loop awaits sendEmail with no catch of its own, so a single failure throws out of the loop and lands in the call site's catch above, which keeps the run alive and abandons the rest of the batch. The audit rows for that batch are already committed by then, so one provider hiccup on one address does two bad things: it marks every remaining campaign in the batch as emailed without emailing it, and it does it to the one email in the product that only ever gets one chance. The fix is the sibling's catch, and the better fix is writing the audit row per campaign as each send succeeds, at the cost of the single-statement dedupe that makes the pair safe to run twice at once. I would take the catch now and think about the second part later.

A paid source ran out of credit and our own code hid it from us for nine days

Daniel Pertu — Sun, 08 Nov 2026 11:16:42 +0000

Nakodo leans on a handful of external sources, and two of them are paid, prepaid, and can therefore simply stop. On 12 October one of them ran out of balance. The work that depended on it stopped that day and did not start again for nine days. Nothing crashed, no alert fired, and the only record anywhere was a row in a counters table with a timestamp in it.

Two separate mistakes made that possible, and they are worth separating, because only one of them is the obvious one.

Mistake one: an exhaustion flag that renewed itself

Every external source has a daily row, and a refusal from the source writes exhaustedAt on it. Every request first asks whether the row is usable:

const usable = sql`${providerDays.exhaustedAt} is null`;

That is correct for a source whose budget is a calendar day. A daily API quota resets at a fixed hour, so "it refused us, stop asking until the day turns over" is exactly right, and it saves a few thousand pointless requests.

It is wrong for a prepaid balance, and wrong in a way that is almost funny. The day turns over. The first job of the new day asks the source. The source, still unpaid, refuses. The new day's row is marked exhausted, and every other request that day is skipped locally. Each midnight bought one request, which was spent proving the outage would continue. Nine days of that.

The fix is a per-source retry window rather than a global rule:

export const retryAfter = (counter: Counter): Date =>
  RETRY_AFTER_MS[counter] === undefined
    ? nextUtcMidnight()
    : new Date(Date.now() + RETRY_AFTER_MS[counter]);

The map has two entries, both one hour, for the two sources whose balance can be topped up during the day. Every other source is absent from it and keeps the old behaviour, which for a daily quota is the honest model of what the provider actually does.

The window lives inside the same statement that spends the allowance, so there is no cron and no second round trip:

const usable =
  retryAfterMs === undefined
    ? sql`${providerDays.exhaustedAt} is null`
    : sql`(${providerDays.exhaustedAt} is null
           or ${providerDays.exhaustedAt} < now() - make_interval(secs => ${retryAfterMs / 1000}))`;

await db.insert(providerDays).values({ provider, day, requestsUsed: n })
  .onConflictDoUpdate({
    target: [providerDays.provider, providerDays.day],
    set: { requestsUsed: sql`${providerDays.requestsUsed} + ${n}` },
    setWhere: limit === null ? usable : sql`${providerDays.requestsUsed} + ${n} <= ${limit} and ${usable}`,
  })
  .returning({ used: providerDays.requestsUsed });

An upsert whose WHERE refuses to update returns no rows, so "may I spend one request" and "is this source worth asking again yet" are one question with one answer, decided by the database. Jobs that get a no are deferred rather than failed, with the retry time attached, so the queue holds them and nothing is lost.

Mistake two: nobody was told

The deeper problem is that a source refusing us is not a bug anyone will find in the logs. It is not an exception. Both of ours answer with an HTTP 402 and a sentence of JSON explaining themselves, handled politely by code written to handle it politely. The product keeps working. It just quietly does less.

So refusals now email the operator, and the only interesting part is making sure that happens once:

export async function noteBlock(source: NotifiedSource): Promise<boolean> {
  const [row] = await db
    .insert(providerState)
    .values({ provider: source, blockNotifiedAt: sql`now()` })
    .onConflictDoUpdate({
      target: providerState.provider,
      set: { blockNotifiedAt: sql`coalesce(${providerState.blockNotifiedAt}, now())` },
    })
    .returning({ first: sql<boolean>`${providerState.blockNotifiedAt} = now()` });
  return row.first;
}

coalesce(blockNotifiedAt, now()) is a write that only writes when the column is null: an existing notice keeps its original timestamp. Then the returning clause asks whether the value that is now in the row equals now(), which inside a single statement is a fixed instant, so the comparison means "I am the request that set this". One statement answers both "latch it" and "was I first", with no read, no transaction and no race between two server instances arriving together.

The caller does nothing clever with the answer except send one email:

const paragraphs = [
  `${outage.what} Nakodo noticed at ${utc(new Date())}.`,
  outage.effect,
  "Nakodo tries the source again about an hour after each refusal, so the work picks up by itself once it can go through. The jobs waiting on it stay in the queue rather than failing.",
  "You get this email once. The next one comes only after a request has worked again.",
];

Each caller passes an Outage with three fields, and the types are the whole design of the alert:

export type Outage = {
  what: string;                              // "the balance is used up"
  effect: string;                            // what stops, and what carries on
  link: { href: string; label: string };     // where to fix it
};

An alert that says a source is down is a notification. An alert that says what stopped, what is still running, and which page takes a card is a thing you can act on from a phone. The whole function is wrapped in a try that logs and swallows, because the caller is already on its way to failing a request and an email service having a bad minute must not turn one outage into two.

Forgetting is the other half

A latch you cannot clear is a latch that fires once per deployment and then never again. The clearing side is the mirror image:

await db.update(providerState)
  .set({ blockNotifiedAt: null })
  .where(and(eq(providerState.provider, source), isNotNull(providerState.blockNotifiedAt)));

The isNotNull in the WHERE means the statement is a no-op when there was no notice, which is what lets every successful request call it without thinking. And because a busy invocation might make hundreds of successful requests, there is a module-level set in front of it:

const healthy = new Set<NotifiedSource>();

export async function noteSourceWorking(source: NotifiedSource): Promise<void> {
  if (healthy.has(source)) return;
  healthy.add(source);
  // ... clear the day's refusal and the email notice
}

The set is a hint, not a lock. It is per instance and dies with the process, the database statements are idempotent anyway, and a failure removes the source from the set so the next request tries again. A later outage takes the source back out.

What the table looks like now

export const providerState = pgTable("provider_state", {
  provider: text().$type<NotifiedSource>().primaryKey(),
  nextRequestAt: timestamp({ withTimezone: true }).notNull().defaultNow(),
  blockNotifiedAt: timestamp({ withTimezone: true }),
  updatedAt: updatedAt(),
}).enableRLS();

One row per source, keyed by its name, holding two facts: when the next request may start, and whether we have already said it stopped working. Both are things every server instance has to agree on, which is why neither lives in memory.

The thing I would take from the nine days is not the SQL. It is that the condition had no symptom. The product's plans are metered by what it does for you, and in that incident it did less for everybody while looking entirely healthy. Code that handles a dependency's failure gracefully, with no alert attached to the graceful path, is how an outage gets to be nine days long.

We import 53 icons from one library, and six of them ever reach a public page

Daniel Pertu — Sun, 08 Nov 2026 11:14:53 +0000

Nakodo imports its interface icons from lucide-react. Counting the named imports across the repo:

files importing lucide-react      52
distinct icons imported           53
imported by exactly one file      30
icon elements rendered in JSX    132

Thirty icons with a single call site each is the shape you would expect from a library: you reach for the one that fits and you never need it again. The interesting number is how many of those 53 a visitor can actually see, so I swept all 76 URLs in the sitemap and counted the rendered class names.

curl -s https://nakodo.app/pricing | grep -o 'lucide-[a-z-]*' | sort | uniq -c
#   25 lucide-check
#   10 lucide-plus
#    1 lucide-menu

Across all 76 pages, six distinct icons ever leave the server:

menu    76 pages    1 per page
plus    66 pages    4 to 10 per page
copy     8 pages    1 to 6 per page
x        3 pages    3 per page
check    2 pages    21 and 25
mail     1 page     4

Forty-seven of the 53 live entirely behind the login. The public site is a static content site, and a static content site needs almost no iconography: a word is cheaper to render and easier to translate than a glyph that has to be explained.

What each of the six is doing

menu is the mobile navigation toggle, which is why it is on every single page, including the ten that ship nothing else: the eight hub pages such as /guides and /youtubers, plus /privacy and /terms. Those ten pages have no FAQ and nothing to copy, so one icon is their entire icon budget.

plus is the marker on an FAQ question, and on the four calculators it is also the add-a-row button. The FAQ one is my favourite icon in the app, because it is two symbols for the price of one:

<svg class="lucide lucide-plus size-4 shrink-0 text-muted-foreground
            transition-transform group-open:rotate-45" aria-hidden="true">

The questions are native <details> elements, so group-open:rotate-45 turns the plus into a cross when the answer opens, with the transition doing the turn. No second icon, no state in JavaScript, and it works with JavaScript off.

copy sits on the copy-this-template buttons, which is why it appears on exactly the eight guides that carry a template, with a count that matches how many templates each one has: six on the outreach templates guide, five on the Instagram and TikTok one, four on the follow-up guide, and one each on five others.

x appears three times on three of the four free tools: one on each of the three video rows the engagement calculators start with, as a remove button that disables itself when a single row is left. The fourth tool is the sponsorship cost calculator, which has no rows to remove, so it ships none.

check and mail are the two highest counts in the sweep and the two rarest pages: 25 ticks on the plan features on /pricing, and 21 ticks plus four envelopes on the home page.

The size attribute in the markup is never the size on screen

Every rendered icon carries this:

<svg width="24" height="24" viewBox="0 0 24 24" stroke-width="2"
     class="lucide lucide-check mt-0.5 size-4 shrink-0 ...">

The 24 is the library's default and the size-4 is what you actually see. Eighty of the 132 icon elements in the source carry no className at all, because the button variants size them from the outside:

// base
"[&_svg]:pointer-events-none [&_svg]:shrink-0 [&_svg:not([class*='size-'])]:size-4"
// size variants
xs: "h-7 gap-1 px-2 text-xs [&_svg:not([class*='size-'])]:size-3",
sm: "h-8 gap-1.5 px-3 text-[13px] [&_svg:not([class*='size-'])]:size-3.5",

The :not([class*='size-']) is the part worth stealing. The rule sizes any icon in the button to match the button, and steps aside the moment the icon names a size itself, which it detects by looking for the substring in the class attribute. So an icon has no size by default, inherits one from whatever it sits in, and can override it locally with one class. Across the app the overrides are size-4 27 times, size-3.5 14, size-3 7 and size-5 twice.

Exactly one icon is addressed to a screen reader

I expected to find a rule about aria-hidden on decorative icons, and found instead that the library has one. From lucide-react 1.49.0:

...params.hasA11yProp === false ? {
  [getAttributeName("aria-hidden")]: "true"
} : {},

Every icon is hidden from assistive technology unless you pass an accessibility prop, in which case the hiding switches itself off. That is the correct default for interface icons, which are nearly always a duplicate of a word next to them, and it means 35 of our 132 elements are repeating something the library already did.

One icon in the entire app passes an accessibility prop, in the support thread view:

{line.byEmail && <MailIcon className="size-3" aria-label="By email" />}

That envelope is the only glyph in the product carrying information that no neighbouring text carries: this message arrived as an email rather than being typed into the app. One icon out of 132, and it is the only one where the default stepped aside.

A live check on the rendered page agrees from the other direction: /pricing ships 62 <svg> elements, 36 of them lucide, and 61 of the 62 carry aria-hidden="true". The one that does not is a nested group inside a drawing:

<svg x="82" y="110" width="96" height="96" viewBox="0 0 96 96" overflow="visible">

Which is the other half of the inventory. The 26 non-library svgs on that page are ours: 27 files and 1,622 lines in the illustration directory, drawn on a shared 96 unit grid, and the platform marks are hand-drawn too because YouTube, Instagram and TikTok each require their own logo next to their own data. The icon library covers the verbs. It does not cover the brand, and it is not allowed to cover anybody else's.

The finding

aria-label on a bare <svg> is not reliably announced: the element needs role="img" for the label to be treated as its name, and an <span class="sr-only"> next to a hidden icon is the version that works everywhere. The app already has that pattern in its own attention mark, so the one labelled icon in the codebase is the one that should stop being clever. The 35 redundant aria-hidden attributes can go at the same time, since the library is already doing it.

Seven useMemo calls in 72,683 lines, six of them in one file, and the one that matters is not about speed

Daniel Pertu — Sun, 08 Nov 2026 11:10:59 +0000

Nakodo is a Next.js 16 app on React 19.2.8: 582 TypeScript files, 72,683 lines. Most advice about React performance is about memoisation, so I grepped the whole thing to see how much of it we actually use.

useMemo                7 occurrences, 2 files
useCallback            2 occurrences, 2 files
React.memo / memo()    0
useDeferredValue       0
useLayoutEffect        0
useImperativeHandle    0

For scale, the same grep over the same tree finds useEffect in 23 files, useState in 33, useTransition in 11 and useActionState in 11. So the app is not short of client state. It is short of memoisation, and the reason turns out to be structural rather than principled.

Why there is so little to memoise

226 of the files are .tsx. Eighty of them start with "use client", and 17 of those eighty are the shadcn primitives in src/components/ui. Everything else renders on the server, which includes almost every list in the product: the campaign list, the conversations screen, the creator page, all 76 public pages. A .map() over rows appears in 103 files, and in most of them it runs once, on a server, into HTML.

React.memo protects a child from a parent that re-renders. If the parent is a server component, there is no parent render to protect against, so there is nothing for the wrapper to do. That is the whole explanation for the zero.

One of the seven useMemo calls is in src/components/ui/chart.tsx, which is vendored shadcn code. We did not write it, and it is the only memo in the repo that is not in the file below.

The six that are ours

They are all in src/app/(app)/campaigns/[id]/results-view.tsx, 1,153 lines, the biggest client component in the app and the one screen where a long list genuinely lives in the browser: filters, sorting, selection and a search box that must not wait on a round trip. You cannot look at it without an account, which the server will tell you itself:

$ curl -sI https://nakodo.app/campaigns
HTTP/2 307
location: /login?next=%2Fcampaigns

How it works describes what that screen holds from the outside. From the inside it is six derivations in a chain:

const urlFilters = useMemo(() => parseFilters(searchParams), [searchParams]);
// The search box is local so typing never waits on the URL; it is written
// to the URL with the other filters.
const [query, setQuery] = useState(urlFilters.q);
const f = useMemo(() => ({ ...urlFilters, q: query }), [urlFilters, query]);

then a pass that compares the rows the server just sent against the snapshot the screen started with, then:

const [optimistic, setOptimistic] = useOptimistic(shown, (state, change) => /* ... */);

const counts = useMemo(() => viewCounts(optimistic), [optimistic]);
const list = useMemo(() => applyFilters(optimistic, f, markets), [optimistic, f, markets]);

The interesting one is shown, the memo in the middle, because its dependencies are [rows, snapshot] and neither of those changes when you type. The search box is local state, so a keystroke re-renders the whole 1,153-line component. What recomputes is one derivation out of five: shown is identical, so optimistic is identical, so counts is identical, and only list runs again because f changed.

That is what the memo buys. Not milliseconds in a profiler: a dependency chain where the base array of useOptimistic keeps its identity through renders that have nothing to do with it. The other two useOptimistic call sites in the app pass a boolean, in a settings toggle and in an operator form, and neither needs a memo, because a primitive has no identity to lose.

What is deliberately not memoised

Three lines further down the same component:

const visible = list.slice(0, limit);
const chosen = list.filter((r) => selected.has(r.channelId));
const fitCount = optimistic.filter(isFit).length;

Three derived values, all recomputed on every render, none of them wrapped. The rule that fell out of writing this file is that memoising a single pass over an array you are already holding costs more than it saves: you pay a dependency array, a cache slot and the chance of a stale value, to skip one loop that was going to run in the time it takes to allocate the comparison.

What is worth memoising is applyFilters, and it is worth it because of what it does rather than because of the loop:

return list
  .map((r, i) => ({ r, i, v: sortValue(r, f.sort) }))
  .sort((a, b) => { /* ... */ })
  .map((x) => x.r);

A filter, then a decorate, sort and undecorate: four array allocations and a comparison sort, with a stable tie-break on the server's original order. That is the one derivation in the screen that is not linear, and it is the one that is cached.

Both useCallback calls are for useEffect

Neither of the two is about a child component. They exist because the function is an effect dependency:

const ask = useCallback((p: Part) => { /* ... */ }, [campaignId, router]);

useEffect(() => {
  if (part && asked.current !== part) ask(part);
}, [part, ask]);

Without the wrapper, ask is a new function on every render, the effect's dependency array changes on every render, and the effect fires on every render, which here means asking the server to write part of a campaign setup over and over. The second one, in the support panel, is useCallback(() => { /* thirteen setState calls */ }, []), used the same way.

That is a different tool from the one the performance posts describe. useCallback for a prop is an optimisation. useCallback for a dependency array is a correctness fix, and it is the only kind this codebase has needed. 161 inline arrow handlers are passed straight into elements across the app's client components, and because no child is wrapped in React.memo, a stable identity for any of them would buy exactly nothing.

The gap

The results screen caps the DOM at PAGE = 50 rows and pages in more on demand, which is why the unmemoised passes stay cheap: the list can be long, the render is not. But applyFilters runs over every row in the campaign on every keystroke, and useDeferredValue appears nowhere in these 582 files. If a campaign's list ever grows to the point where typing feels sticky, that is the hook to reach for, and the memo chain above is already shaped to make it a two-line change.

Seven memos, two callbacks, no React.memo. The audit's real finding is that moving list rendering to the server does not reduce the amount of memoisation you need by a bit. It removes the reason for most of it.