DEV Community: Daniel Pertu

Five things I got wrong shipping v1

Daniel Pertu — Sun, 06 Sep 2026 16:28:23 +0000

I shipped the first version of my assessment-practice platform too eager and slightly wrong in a bunch of ways. None fatal, all instructive. Here's the honest list.

1. I measured reaction time with Date.now(). Which drifts when the system clock syncs and has coarse resolution — for an app whose whole point is timing, this was embarrassing. Switching to performance.now() and event timestamps was the single biggest correctness fix I made.

2. I built the analytics before I had any data. I lovingly engineered a percentile system for a population of… zero. My first users got confidently told they were "in the 50th percentile of 8 people," which is meaningless. I should have shipped raw feedback first and added ranking once real data existed.

3. My landing page shipped as one bundle. Every animation and demo library loaded on first paint, on a page whose job is to convert visitors in three seconds. Code-splitting and lazy-loading below the fold should have been there from day one, not bolted on after a bad Lighthouse score.

4. I over-modelled the database. I stored every trial in its own richly-indexed row forever, planning for scale I didn't have, and made simple queries slower in the process. Storing detail cheaply and summaries fast would have been simpler and faster.

5. I built features nobody asked for. A whole customisation panel, used by approximately no one, while the actual request in every piece of feedback was "more game types." I mistook building for progress.

The meta-lesson, which I'll relearn again anyway: ship the smallest honest version, put it in front of real users, and let them tell you what to build next. Most of my mistakes were me solving imagined problems before I'd met a single real one.

The v2 of all this is live at CogniPrep, a practice platform for psychometric assessments: https://cogniprep.app

Post 8 — Getting a JavaScript-heavy product site to actually rank (Next.js App Router)

Angle: SEO + Next.js. Highly searchable, practical, evergreen.

An interactive, client-heavy site and good SEO feel like opposites — one wants JavaScript, the other wants crawlable HTML. With the Next.js App Router, you can have both, but there are a few things you have to do on purpose. Here's the checklist that moved my pages from invisible to indexed.

Give every page real metadata. The App Router's generateMetadata lets you produce titles, descriptions, and Open Graph tags per route, on the server, so crawlers see them without running your JS:

export async function generateMetadata({ params }) {
  const game = await getGame(params.slug);
  return {
    title: `${game.name} practice — CogniPrep`,
    description: game.summary,
    alternates: { canonical: `https://cogniprep.app/games/${game.slug}` },
  };
}

Set canonical URLs before duplicates bite you. Query params, trailing slashes, and A/B variants all spawn duplicate URLs that dilute ranking. An explicit canonical per page (above) tells search engines which one is the real one.

Ship sitemap.ts and robots.ts. The App Router generates both from code, so your sitemap stays in sync with your actual routes instead of going stale in a static file. Crawlers find your pages faster and you control what they skip.

Keep the indexable content server-rendered. The interactive demos can be client-only (ssr: false is fine for a canvas game), but the words a search engine needs — headings, descriptions, explanations — must be in the server-rendered HTML. Don't hide your actual content inside a client component that only renders after hydration.

Add JSON-LD structured data. A small <script type="application/ld+json"> block describing the page (as a product, article, or FAQ) helps you earn richer search results. It's plain data injected server-side, nothing fancy.

The mental model that fixed this for me: JavaScript can power the experience, but the content and metadata a crawler needs should exist in the HTML before a single line of your JS runs. Split those two concerns, and a heavy interactive site indexes just fine.

Applied all of this to CogniPrep, a practice platform for game-based assessments: https://cogniprep.app

Making timed games accessible when the timing is the point

Daniel Pertu — Sun, 06 Sep 2026 16:27:33 +0000

Most accessibility advice for timers says: let users extend or turn off the time limit (that's literally WCAG's "Timing Adjustable"). But what do you do when the reaction time is the measurement? You can't just switch off the clock without deleting the thing you're measuring. This tension is real and mostly unaddressed, so I want to share where I landed rather than pretend I solved it.

Decouple input speed from cognitive speed where you can. A lot of "slowness" in a timed task is motor, not mental. So I made sure every game is fully operable by keyboard as well as pointer, kept target sizes generous, and never required fine dragging or double-clicks. That removes a chunk of unfair penalty without touching the measurement.

Never encode meaning in color alone. Cognitive games lean hard on color, which quietly excludes colorblind users. I paired every color with a shape or label, and used a palette checked against the common color-vision deficiencies. Same information, more than one channel.

@media (prefers-reduced-motion: reduce) {
  * { animation: none !important; transition: none !important; }
}

Respect prefers-reduced-motion. Flashing and rapid movement aren't just uncomfortable — for some users they're disqualifying or dangerous. Honoring the OS setting is one media query and there's no excuse to skip it.

Offer an extended-time mode, and be honest about what it means. For users who need it, I provide a mode with longer windows — clearly flagged as separate, so the timing-based scores aren't silently compared against standard runs. It's a practice tool, so a fair practice environment matters more than a pure number here.

Say what you don't support. Some game-based assessment formats are genuinely hard to make fully screen-reader accessible, and pretending otherwise is worse than being clear. I document the current limits so nobody's blindsided.

The honest takeaway: for timed cognitive tasks, "accessible" isn't a checkbox you complete — it's a set of trade-offs you make deliberately and disclose. Removing motor and sensory penalties is unambiguously right. Adjusting the timing itself is where it gets genuinely hard, and the responsible move is transparency, not a fake solution.

I'm working through these trade-offs on CogniPrep, a practice platform for game-based assessments: https://cogniprep.app

How I store "unlimited sessions" without my database exploding

Daniel Pertu — Sun, 06 Sep 2026 16:26:24 +0000

I promise users unlimited practice sessions. Every session is a stream of trials, and every trial has timing, correctness, and metadata. Do the math, and a heavy user generates thousands of rows a week. Store all of it naively and both your storage bill and your history queries fall over. Here's how I kept "unlimited" honest.

Separate the thing you write a lot from the thing you read a lot. Trials are write-heavy and rarely read individually. Session summaries are read constantly (the history page, the percentile). So I split them: an append-only trial log, and a materialised summary row per session computed when the session ends.

sessions:  id, user_id, game_type, started_at, score, percentile, accuracy, mean_rt
trials:    id, session_id, index, stimulus, response, correct, rt_ms

The history page never touches the trial table. It reads sessions filtered by user_id, ordered by started_at, with an index on (user_id, started_at desc). That query stays fast no matter how many trials exist underneath, because it doesn't join to them.

Cold trial data doesn't need to live in hot storage. Users rarely drill into an individual trial from six months ago. So raw trials past a certain age get rolled up: I keep the session summary forever, compress the per-trial detail into a single JSON blob on the session (or push it to object storage), and drop the individual rows. History stays complete; the hot table stays small.

Compute summaries once, not on every read. The percentile, mean reaction time, and accuracy are calculated when the session closes and written to the summary row. Recomputing them on every page load would mean rescanning trials constantly — the exact thing the split was meant to avoid.

The principle generalises to anything with high-volume detail and low-volume summaries: write detail cheaply, read summaries fast, and age the detail out on a schedule. "Unlimited" is a storage strategy, not a promise to keep every byte hot forever.

This is the data model behind CogniPrep, a practice platform for psychometric assessments: https://cogniprep.app

Boolean soup is why your UI has impossible states

Daniel Pertu — Sun, 06 Sep 2026 16:25:00 +0000

My first version of a mini-game tracked its phase with a pile of booleans: isLoading, isShowingStimulus, hasResponded, isComplete. It worked until it didn't. A slow network plus a fast click gave me isShowingStimulus && hasResponded && isLoading all true at once — a state that makes no sense but that my code happily rendered. I was writing defensive if checks to paper over combinations that should never exist.

The fix was to stop tracking facts about the state and start naming the state itself.

A game has phases, so model phases. Each mini-game moves through a fixed lifecycle: idle → stimulus → awaiting_response → feedback → complete. That's a finite state machine. There is exactly one current phase, and only certain transitions are legal.

const machine = {
  idle:            { START: "stimulus" },
  stimulus:        { SHOWN: "awaiting_response" },
  awaiting_response: { RESPOND: "feedback", TIMEOUT: "feedback" },
  feedback:        { NEXT: "stimulus", DONE: "complete" },
  complete:        {},
};

function transition(state, event) {
  return machine[state][event] ?? state; // ignore illegal events
}

Impossible states become unrepresentable. A click that arrives during feedback sends a RESPOND event that the machine simply ignores, because feedback has no RESPOND transition. No guard clauses, no flag juggling. The bug I was patching couldn't occur.

You get testing and visualization for free. Because transitions are data, I can assert "from stimulus, only SHOWN does anything" in a unit test, and I can literally draw the graph. When I outgrew the hand-rolled version I moved to XState, but the reducer above carried me a long way and is worth reaching for before adding a dependency.

The general rule: if you find yourself writing if (a && !b && c) to describe your UI, you probably have one state variable with a handful of legal values, not four independent booleans. Name the states.

I use this pattern across every game in CogniPrep, a practice platform for game-based psychometric assessments: https://cogniprep.app

Keeping a heavy, animated landing page fast in Next.js

Daniel Pertu — Sun, 06 Sep 2026 16:19:30 +0000

My marketing homepage has interactive game demos, scroll animations, and a lot of moving parts. All of that kills first load if you ship it in one bundle. Here's how I kept it fast without cutting the fun stuff.

Server-render the hero, lazy-load the rest. The only thing that needs to be fast is what's above the fold. I keep the hero server-rendered and dependency-light so the Largest Contentful Paint lands early, then defer everything below it.

next/dynamic for the expensive, client-only pieces. The interactive demos are pure client components — no reason to server-render a canvas game:

const GameDemo = dynamic(() => import("./GameDemo"), {
  ssr: false,
  loading: () => <DemoSkeleton />,
});

Only mount a demo when it's about to be seen. Dynamic import splits the code, but I don't even want to fetch that chunk until the user scrolls near it. An Intersection Observer gates the mount:

const [show, setShow] = useState(false);
useEffect(() => {
  const io = new IntersectionObserver(([e]) => e.isIntersecting && setShow(true), {
    rootMargin: "200px", // start loading just before it enters view
  });
  ref.current && io.observe(ref.current);
  return () => io.disconnect();
}, []);

Measure, don't guess. @next/bundle-analyzer showed me a charting lib and an animation lib were most of my initial weight — both trivially deferrable once I stopped importing them at the top level. Pair that with next/image for the demo thumbnails and next/font to kill layout-shift from web fonts, and the "everything happens at once" homepage loads like a static one.

The principle: the browser should pay for a feature only when the user is about to reach it. Split by route and by viewport.

This is the actual homepage for CogniPrep — https://cogniprep.app if you want to poke at the load behaviour.

Turning a raw score into "you're in the 68th percentile"

Daniel Pertu — Sun, 06 Sep 2026 16:18:36 +0000

A raw score is almost useless on its own. "You scored 74" — good? bad? The number people actually understand is a percentile: where do I sit relative to everyone else. Building that ranking layer was more interesting than I expected.

The naive version breaks fast. The textbook definition of a percentile is "the fraction of the population scoring below you." The obvious implementation is: pull every score, sort, find your position. That's fine for a demo and miserable in production — you don't want to load and sort an ever-growing table on every result page.

Streaming quantiles fix it. Instead of storing raw scores forever, I keep a compact summary per game type using a t-digest — a data structure that estimates quantiles from a stream with tight accuracy at the tails (which is exactly where percentile questions get interesting: the 95th matters more than the 50th). New scores update the digest; querying a percentile is cheap and O(1)-ish. You trade a sliver of precision for not hauling around the whole dataset.

The cold-start problem is the real trap. Early on you don't have a population. Your first user can't meaningfully be "in the 60th percentile of 12 people." I handled this by:

seeding each game with a modelled reference distribution based on published norms, then
blending toward the empirical distribution as real data accumulated, and
hiding the percentile entirely below a minimum-N threshold, showing a raw breakdown instead so I wasn't lying with confidence. Interpolate, or your numbers look chunky. With discrete data, exact-match percentiles jump in ugly steps. Linear interpolation between the two nearest ranked points smooths it into something that reads as a real, continuous score.

The general lesson: "show me where I rank" sounds like one line of SQL and is actually a small system — a summary structure, a norming strategy, and a rule for what to show when you don't know enough yet.

I built this ranking layer for CogniPrep, a practice platform for psychometric assessments. https://cogniprep.app if you want to see it in action.

Measuring reaction time in the browser is harder than it looks

Daniel Pertu — Sun, 06 Sep 2026 16:17:30 +0000

If your app measures how fast someone reacts to something, the number you record is only as good as your timing. I learned this the hard way building game-based cognitive assessments, where the reaction time basically is the measurement — a sloppy 40ms of jitter turns a real signal into noise.

Here's what actually matters.

Use performance.now(), not Date.now(). Date.now() is wall-clock time — it can jump around when the system clock syncs, and its resolution is coarse. performance.now() is monotonic and high-resolution, measured from a fixed time origin. Everything below assumes it.

Don't timestamp inside your event handler. The intuitive approach is: when the click fires, call performance.now(). But your handler might run late if the main thread is busy, and you'd be measuring "when my JS got scheduled," not "when the user acted." Every modern input event already carries an accurate event.timeStamp from the same time origin:

button.addEventListener("pointerdown", (e) => {
  const reactionMs = e.timeStamp - stimulusShownAt;
});

Timestamp the stimulus at paint, not at state-set. When you call setState to show the target, the pixels don't hit the screen on that line — they hit after the next composite. The closest honest "shown at" is the requestAnimationFrame callback timestamp for the frame that actually rendered it:

requestAnimationFrame((frameTime) => {
  stimulusShownAt = frameTime; // when the browser is about to paint
});

Accept the limits, then design around them. You still can't beat the display: a 60Hz screen only updates every ~16.7ms, browsers coarsen timers to mitigate Spectre-style attacks, and background tabs get throttled. So I stopped pretending to measure absolute lab-grade milliseconds and instead:

measured relative differences within a session, where the constant offsets cancel out,
flagged responses that arrived before the stimulus (anticipations/guesses) and threw them out,
normalised against a per-user baseline captured in a warm-up round. The takeaway that generalises: for any timing-sensitive UI, separate "when did the thing appear" from "when did the user act," get both from the browser's own high-res clock, and be honest about the noise floor you can't remove.

I'm building CogniPrep, a practice platform for game-based psychometric assessments — this reaction-timing stuff is the guts of it. Link: https://cogniprep.app

My first post, check it out

Daniel Pertu — Fri, 12 Jun 2026 11:57:35 +0000

Daniel Pertu

Jun 12

CogniPrep

#webdev #career

2 min read

CogniPrep

Daniel Pertu — Fri, 12 Jun 2026 11:57:11 +0000

Job hunting is stressful enough. Then you get to the final stages and hit a psychometric game assessment — a series of cognitive mini-games designed to measure how your brain works under pressure. No practice material, no "study guide", just vibes.

That's exactly what happened to a friend of mine. They bombed it. Not because they weren't smart — because they'd never seen anything like it before.

So I built CogniPrep.

What it is

CogniPrep is a practice platform for Arctic Shores psychometric assessments — the game-based cognitive tests used by employers like KPMG, PwC, Deloitte, and a growing number of others. You get access to 14 authentic game simulations, unlimited sessions, and detailed feedback reports with percentile scores so you actually know where you stand.

The goal isn't to game the system. It's to remove the unfamiliarity. When you've seen the format before, your anxiety drops and your actual ability comes through.

The stack

Next.js 15 (App Router) — server components, server actions, the works
Supabase — auth + Postgres
Tailwind CSS — utility-first, as God intended
Vercel — deployment

Pretty boring stack, intentionally. The games themselves are the complex part — each one simulates a different cognitive domain (working memory, attention, spatial reasoning, etc.) and has its own scoring logic and session state.

Interesting problems I ran into

1. Game session state

Each game session needs to track timing and responses and produce a score that maps to a percentile relative to a real population baseline. I ended up storing population stats in the DB and running a cron to keep them fresh. Simple but effective.

2. Feedback that actually means something

Raw scores are useless without context. The feedback system computes percentile rankings so users see not just "you scored 74" but "you scored in the 68th percentile — here's where to focus." That required building out a proper analytics layer per game type.

3. Landing page performance

The homepage has interactive game demos, animated sections, and a lot going on. I leaned heavily on next/dynamic with lazy loading to keep the initial bundle lean. The hero renders fast; everything else loads as the user scrolls.