DEV Community: Clackpit

How I built a no-account leaderboard for my typing game — and why I’ll never ask for signup

Clackpit — Tue, 19 May 2026 09:32:59 +0000

When I started building Clackpit, I knew I wanted a daily leaderboard. Competitive pressure is the single biggest reason people return to a typing game — seeing your name one slot below someone else is a visceral motivation loop that no feature list can replicate.

But I also knew from playing TypeRacer that account friction kills the moment. You're in the zone, you finish a race at a personal best, and then... "Create an account to save your score." The spell breaks. Half the people close the tab.

So I built Clackpit's leaderboard to work with zero accounts. Here's how.

The core insight: localStorage is your persistent identity layer

Every time someone visits Clackpit for the first time, they're assigned a random handle — something like "QuickFalcon" or "SwiftPine." It gets stored in localStorage. That's it. That's the account.

function getOrCreateHandle(): string {
  const stored = localStorage.getItem('clackpit_handle');
  if (stored) return stored;

  const adjectives = ['Quick', 'Swift', 'Sharp', 'Rapid', 'Keen'];
  const nouns = ['Falcon', 'Pine', 'River', 'Stone', 'Arrow'];

  const handle = 
    adjectives[Math.floor(Math.random() * adjectives.length)] +
    nouns[Math.floor(Math.random() * nouns.length)] +
    Math.floor(Math.random() * 99);

  localStorage.setItem('clackpit_handle', handle);
  return handle;
}

The handle persists across sessions. Players can change it once — this is important, because the ability to choose your name is part of the identity investment. But they can't change it to something that's already on the leaderboard (we check server-side), and once changed, it's locked for 24 hours.

The server side: Cloudflare KV as a daily leaderboard store

The leaderboard resets daily. Each entry is a score object keyed by date:

interface LeaderboardEntry {
  handle: string;
  wpm: number;
  accuracy: number;
  mode: 'sprint' | 'marathon' | 'endurance';
  timestamp: number;
}

When a race finishes, the client POSTs to /api/leaderboard with the handle, score, and mode. The worker looks up the current day's leaderboard from KV, upserts the entry (keeping only the player's best score for the day), and writes it back with a 24-hour TTL.

async function submitScore(env: Env, entry: LeaderboardEntry): Promise<void> {
  const key = `leaderboard:${todayKey()}`;
  const raw = await env.LEADERBOARD.get(key);
  const board: LeaderboardEntry[] = raw ? JSON.parse(raw) : [];

  // Upsert: replace existing entry for this handle, or append
  const idx = board.findIndex(e => e.handle === entry.handle);
  if (idx >= 0) {
    // Only keep the better score
    if (entry.wpm > board[idx].wpm) board[idx] = entry;
  } else {
    board.push(entry);
  }

  // Sort and cap at top 50
  board.sort((a, b) => b.wpm - a.wpm);
  board.splice(50);

  await env.LEADERBOARD.put(key, JSON.stringify(board), {
    expirationTtl: 86400 * 2 // 2-day TTL so yesterday's leaderboard stays readable
  });
}

The daily reset is implicit: a new key (leaderboard:2026-05-17) just starts empty. No cron job needed.

The anti-cheat problem

Without accounts, someone can just refresh localStorage, generate a new handle, and post another score. I don't pretend this is unsolvable — it's not, but it's also not worth solving at this stage. The leaderboard is entertainment, not a tournament with prizes.

What I did add: server-side rate limiting per IP using KV (one submission per 5 minutes), and a WPM cap above which scores are silently rejected (currently 220 WPM — humanly achievable but rare enough to filter obvious bots). Both are soft filters. The goal is making casual cheating annoying, not building a fraud detection system.

Why this works better than I expected

The no-account leaderboard has some emergent properties I didn't anticipate:

The handle creates identity without commitment. "QuickFalcon42 is on the leaderboard" is surprisingly motivating even though QuickFalcon42 is a random string someone got three minutes ago. People name themselves. They check back to see if their name is still in the top 10. The absence of a real account doesn't reduce this effect much.

Daily resets reduce intimidation. On a permanent leaderboard, a 180 WPM typist who's been there for two years makes every new visitor feel hopeless. A daily leaderboard lets a 95 WPM typist realistically place in the top 10 on a quiet morning. It stays competitive.

Zero friction means more completions. This is the real one. In early testing (before I shipped the leaderboard), about 60% of visitors who started a race finished it. After shipping the leaderboard, that number went up — people who were going to quit mid-race sometimes pushed through to post a score.

If you're building anything with a competitive element and you're considering whether to require accounts first: ship the no-account version. You can always add accounts later. You cannot un-kill the momentum you lost from the friction.

Try the leaderboard at clackpit.launchyard.app — the daily reset is at midnight UTC if you want to plant a flag.

How I built an anonymous daily leaderboard — and why it resets every night

Clackpit — Mon, 18 May 2026 09:45:43 +0000

Every competitive typing site has a leaderboard. Most of them are terrible.

TypeRacer shows you an all-time WPM rank that you'll never crack. MonkeyType has a global top-1000 that's been locked in by dedicated grinders for years. Both create the same problem: if you're not already in the top tier, the leaderboard is demotivating noise.

When I built Clackpit, I wanted a leaderboard that actually worked for a normal person sitting down to practice. That meant rethinking two things: identity and time horizon.

The problem with persistent identity

Most leaderboards require an account. Name, email, password — the whole thing. That's fine for a product where you've already committed to the user relationship. But for a typing site, where someone might show up for a 3-minute race and never return, it's a massive conversion blocker.

I wanted anyone to be competitive immediately. No friction.

The solution I landed on: anonymous handles that persist in localStorage, chosen from a curated wordlist on first visit.

const ADJECTIVES = ['swift', 'nimble', 'sharp', 'quick', 'bright', /* ... */];
const NOUNS = ['falcon', 'arrow', 'spark', 'dash', 'flare', /* ... */];

function generateHandle(): string {
  const adj = ADJECTIVES[Math.floor(Math.random() * ADJECTIVES.length)];
  const noun = NOUNS[Math.floor(Math.random() * NOUNS.length)];
  const num = Math.floor(Math.random() * 99) + 1;
  return `${adj}${noun}${num}`;
}

// Store in localStorage so it persists across sessions
function getOrCreateHandle(): string {
  const stored = localStorage.getItem('clackpit_handle');
  if (stored) return stored;
  const handle = generateHandle();
  localStorage.setItem('clackpit_handle', handle);
  return handle;
}

The handle is sticky — come back tomorrow and you're still swiftfalcon42. You can change it, but you don't have to. It's yours without signing up.

The problem with all-time leaderboards

Persistent leaderboards have a nasty property: they compound. The longer they exist, the more locked-in the top positions become. A new user who types 90 WPM sees a leaderboard full of 140+ WPM monsters and correctly concludes that competing is pointless.

The fix is surprisingly simple: reset the leaderboard every night at midnight UTC.

A daily leaderboard has a completely different social dynamic:

Everyone starts equal each day. The person who showed up for the first time today can be #1 by the end of the day.
Yesterday's champion is gone. That 140 WPM monster? They have to earn it back.
Streaks become the real achievement. Staying in the top 10 for a week is more interesting than a stale number on a permanent board.

The implementation

I'm running on Cloudflare Workers with KV storage. The leaderboard is a sorted list stored in KV with a TTL that expires at the next midnight UTC.

// Calculate seconds until next midnight UTC
function secondsUntilMidnightUTC(): number {
  const now = new Date();
  const midnight = new Date(now);
  midnight.setUTCHours(24, 0, 0, 0);
  return Math.floor((midnight.getTime() - now.getTime()) / 1000);
}

async function submitScore(
  kv: KVNamespace,
  handle: string,
  wpm: number,
  accuracy: number
): Promise<void> {
  const key = 'leaderboard:daily';
  const ttl = secondsUntilMidnightUTC();

  const raw = await kv.get(key);
  const entries: LeaderboardEntry[] = raw ? JSON.parse(raw) : [];

  // Update or insert this handle's best score
  const existing = entries.findIndex(e => e.handle === handle);
  if (existing >= 0) {
    if (wpm > entries[existing].wpm) {
      entries[existing] = { handle, wpm, accuracy, ts: Date.now() };
    }
  } else {
    entries.push({ handle, wpm, accuracy, ts: Date.now() });
  }

  // Keep top 100, sorted by WPM descending
  entries.sort((a, b) => b.wpm - a.wpm);
  const top100 = entries.slice(0, 100);

  await kv.put(key, JSON.stringify(top100), { expirationTtl: ttl });
}

The TTL does the reset automatically. No cron job, no cleanup task. When the KV key expires, the leaderboard is gone. Next write creates a new one that expires at the next midnight.

What I learned

The daily reset changes behavior in ways I didn't predict.

I expected it to just be "fairer." What I didn't expect was that it makes people check back more often. If you posted a 95 WPM score and there are 3 hours left in the day, you have a reason to come back tomorrow and see if you held on. If the leaderboard were permanent, there's no urgency.

Anonymous handles have a surprising amount of personality. quietarrow71 feels different from swiftfalcon42. People started identifying with their handles even without accounts.

The all-time leaderboard problem is worse than I thought. After watching a few users interact with the board, I noticed that the first thing most people do is scroll to find where they rank. On a daily board, everyone is visible (it only has today's players). On a permanent board, most newcomers wouldn't appear at all. That invisibility is demoralizing.

If you want to see it in action: Clackpit. Sprint mode submits to the daily board after your race. Try it and see where you land before midnight resets it.

Curious what others have done for leaderboards — permanent, daily, weekly? Drop your approach in the comments.

How I calculate WPM in real time — and why most typing sites get the math wrong

Clackpit — Sun, 17 May 2026 08:02:49 +0000

Most typing speed sites use a formula you can fit on a napkin:

WPM = (totalCharsTyped / 5) / elapsedMinutes

Divide by 5 because a "word" is standardized as 5 characters. Divide by elapsed minutes to normalize for time. Simple, intuitive, and — in most steady-state situations — totally fine.

But if you're building a live typing race with real-time feedback, this formula will embarrass you pretty quickly.

Where naive WPM breaks down

Problem 1: The cold-start spike

You start a race. Within the first 0.1 seconds you've typed 2 characters. The formula says:

(2 / 5) / (0.1 / 60) = 240 WPM

Congratulations, you are apparently the world's fastest typist before you've even finished the first word. This looks ridiculous on screen and tanks the credibility of the whole display.

Problem 2: What do you do with backspaces?

If someone types teh, backspaces to fix it, then types the, did they type 8 characters or 4? The naive formula counts raw keystrokes, which means a slow typist who makes tons of mistakes can paradoxically show a higher WPM than someone accurate — because they typed more total characters.

At race end, you want to reward accuracy. During a race, backspace-heavy typing should hurt through time lost, not inflate the WPM counter.

Problem 3: Rolling vs. cumulative

This is the one that bugs me most. A lot of sites show "live WPM" during a race, but what they're actually computing is your average from the beginning. Start fast, hit a hard word, and the number slowly drifts downward. It doesn't feel live — it feels like watching a lagging average.

Real live WPM should reflect what you're doing right now, not what you did since the first keystroke.

What Clackpit does instead

Here's the approach I landed on after a lot of iteration:

1. Don't show anything for the first 2 seconds

Before 2 seconds have elapsed, the WPM display just shows --. This kills the cold-start spike entirely. A 2-second delay is imperceptible to the user — they're focused on typing — but it prevents the ridiculous 500 WPM flash that naive implementations show.

2. Rolling 5-second window for live WPM

Rather than "chars typed since race start", I track a buffer of keystroke timestamps. The live WPM calculation only looks at correct characters typed in the last 5 seconds:

interface KeyEvent {
  timestamp: number; // ms since race start
  char: string;
  correct: boolean;
}

function getRollingWPM(events: KeyEvent[], nowMs: number): number {
  const WINDOW_MS = 5000;
  const MIN_ELAPSED_MS = 2000;

  if (nowMs < MIN_ELAPSED_MS) return 0;

  const windowStart = nowMs - WINDOW_MS;
  const recentCorrect = events.filter(
    (e) => e.correct && e.timestamp >= windowStart
  );

  if (recentCorrect.length < 2) return 0;

  // Use actual span of events in the window, not the full window size
  // This avoids underestimating WPM when the window isn't full yet
  const spanMs =
    recentCorrect[recentCorrect.length - 1].timestamp - recentCorrect[0].timestamp;

  if (spanMs < 200) return 0; // avoid division by near-zero

  const wpm = (recentCorrect.length / 5) / (spanMs / 60_000);
  return Math.round(wpm);
}

The key detail: I use the actual span between the first and last event in the window, not the full window size. If you've only been typing for 1.5 seconds of a 5-second window, using 5000ms as the denominator would undercount your speed. Using the real span gives you a more accurate instantaneous rate.

3. Final WPM counts correct characters only

At race end, the score is:

function getFinalWPM(events: KeyEvent[], totalElapsedMs: number): number {
  const correctChars = events.filter((e) => e.correct).length;
  return Math.round((correctChars / 5) / (totalElapsedMs / 60_000));
}

If you backspaced 20 times, those keystrokes don't boost your WPM — but they did cost you time, which is the natural penalty. You're not being double-punished, but you're also not being rewarded for typing characters that never made it into the final output.

4. Accuracy is tracked separately

function getAccuracy(events: KeyEvent[]): number {
  if (events.length === 0) return 100;
  const correct = events.filter((e) => e.correct).length;
  return Math.round((correct / events.length) * 100);
}

This counts all keystrokes including backspaces in the denominator. Backspacing is a keystroke; it reflects how much correction happened. This is slightly different from how some sites calculate it (correct chars / total chars typed), but I think it's more honest about how efficiently you actually used your keyboard.

The tradeoff

The rolling window approach means your live WPM during a race is not directly comparable to your final WPM. Live WPM is "how fast are you going right now" and final WPM is "how fast did you go overall." They're measuring different things. I think that's actually correct — live feedback and final score serve different purposes — but it's worth being explicit about it in your UI so users aren't confused.

You can see all of this in action at Clackpit — the multiplayer typing race I built. Race starts, live WPM kicks in after 2 seconds, and your final score only counts the characters that mattered.

If you've built something similar and solved the cold-start problem differently, I'm curious — there's probably a dozen valid approaches here.

Why I built forced correction into my typing game (and why MonkeyType got it wrong)

Clackpit — Sat, 16 May 2026 08:03:35 +0000

If you've ever used MonkeyType, you know you can just breeze past mistakes. You hit the wrong key, the word turns red, and you keep going. Your accuracy score takes a hit, but you don't actually have to fix anything. You move on.

I think that's the wrong call. And I built Clackpit differently because of it.

The case against "press on through mistakes"

Here's the thing about typing: it's a motor skill. Your fingers are building muscle memory with every keystroke. When you press the wrong key and keep going, you're not just making a mistake — you're reinforcing it. You're training your hands to accept the wrong movement and then correct course mentally.

That's not how you get faster. That's how you get fast-but-sloppy.

Every professional typing curriculum I've read makes the same point: accuracy first, speed second. Speed is just what happens when accurate movements become automatic. But you can't automate inaccurate movements into accuracy by doing them quickly.

MonkeyType lets you bulldoze through errors because it's optimizing for feel. It feels great to keep typing even when you mess up. You still get a WPM number at the end. The game continues. But that feeling comes at a cost to your actual improvement.

What forced correction actually does

In Clackpit, if you mistype a character, you're stopped. You have to delete back to the error and retype correctly before you can continue. There's no moving forward past a mistake.

When I first implemented this, I thought people might hate it. It's genuinely more frustrating in the short term. Your WPM scores feel lower because your effective speed is lower — you're spending time on recovery, not just forward motion.

But that friction is the point. The frustration is exactly the signal you need.

Forced correction creates a tight feedback loop: wrong key → immediate stop → muscle memory fires again → correct key. That loop, repeated hundreds of times, is how your fingers actually learn. Without the stop, you get a loose feedback loop: wrong key → mental note → keep going → eventually less bad.

The drill loop compounds it

Forced correction in-race is one thing. But Clackpit also tracks which words you stumbled on and offers a one-click drill: after every race, you can pull up just those words — the ones where your fingers fumbled — and run them again, five repetitions each.

This came directly from a thread on r/typing where someone asked for exactly this feature two years ago. Eighteen upvotes and then nothing shipped. I built it because I've wanted it myself for years.

The combination is what makes it work. Forced correction means you fix the error in context. The drill loop means you go back and drill the specific weak spots in isolation. It's the same methodology a piano teacher would use: play the piece correctly, then isolate the hard passage and work it until it's clean.

Where MonkeyType gets it right (because fair is fair)

MonkeyType is genuinely good at what it's trying to be. If you already type accurately and you're trying to push your ceiling, flowing through mistakes and focusing on raw speed makes sense. It's a speed benchmark tool. The experience it optimizes for — fast, fluid, uninterrupted — is the right experience for that goal.

Clackpit is optimizing for something else: improvement. The target user isn't someone benchmarking their ceiling. It's someone who wants to type better than they do now.

Both are valid goals. They just need different tools.

The uncomfortable truth about most typing games

Most typing games optimize for engagement, not improvement. Uninterrupted flow feels good. High WPM numbers feel good. Social leaderboards feel good. None of those things are bad — but they're not the same as actually getting better.

The design decision I keep coming back to is: what does the user actually want at the end of six months? Not what feels good in the next three minutes, but what will they have gotten from using this?

If the answer is "higher WPM and fewer typos in real work," then forced correction isn't a punishment. It's the feature.

If you want to try it: clackpit.launchyard.app — no account required, works in your browser. Brutal feedback welcome.

I built a real-time typing game with no traditional backend — here's the architecture

Clackpit — Wed, 13 May 2026 08:03:04 +0000

I've been mildly obsessed with typing games since I first used TypeRacer in 2009. Last month I finally built my own: Clackpit — a real-time typing game with a daily leaderboard, a "drill your weak words" mode, and a shareable result card. No accounts required.

This post is about the engineering decisions behind it.

The core challenge: making keypresses feel instant

Typing games live or die on latency. If there's any perceptible lag between pressing a key and seeing the result on screen, the whole thing feels broken. The browser event loop is the enemy here.

The naive implementation is to listen to keydown, update some state, then re-render. The problem is that if your render path is slow — even 16ms — it compounds with the browser's own input processing and suddenly the game feels sluggish.

A few things that actually helped:

Don't use a controlled <input> for the active field. I initially used a React-style controlled input where every keypress went through state → re-render → DOM update. The round-trip adds jank. Instead I track position in a ref and only update visual DOM nodes directly when needed, avoiding a full reconcile on every keystroke.

const posRef = useRef(0);
const errorsRef = useRef<Set<number>>(new Set());

function handleKeyDown(e: KeyboardEvent) {
  const ch = e.key;
  if (ch.length !== 1) return; // ignore Shift, Ctrl, etc.

  const expected = passage[posRef.current];
  if (ch === expected && !errorsRef.current.has(posRef.current)) {
    advancePosition();
  } else {
    markError(posRef.current);
  }
}

This keeps state reads synchronous and avoids batched update scheduling entirely for the hot path.

Forced correction: the UX decision I spent the most time on

TypeRacer forces you to backspace over mistakes before you can continue. Monkeytype lets you skip past errors (they count against accuracy, but you keep moving). Which is better?

I went with forced correction, and it was deliberate.

The argument against: it's more frustrating. You're flying through a passage, mistype one letter, and suddenly you're stuck hammering backspace instead of continuing.

The argument for: it actually changes how you type. With skip-past, your fingers learn "type fast, fix it later." With forced correction, you either slow down and type accurately or you pay an immediate penalty. Over time, you develop fewer errors per word, not just faster correction.

For a game that's explicitly about improving typing, forced correction is the right choice. I added a subtle red flash on the error character so it's visually clear why you're blocked — without that feedback, users just hammer keys more frantically.

function markError(pos: number) {
  errorsRef.current.add(pos);
  // Flash the character element red
  const el = charRefs.current[pos];
  el?.classList.add('error-flash');
  setTimeout(() => el?.classList.remove('error-flash'), 150);
}

Scoring in real-time

WPM is a surprisingly contested metric. The "standard" definition is characters typed divided by 5 (one "word" = 5 chars), divided by elapsed minutes:

function calculateWPM(charsTyped: number, elapsedMs: number): number {
  const minutes = elapsedMs / 60_000;
  return Math.round((charsTyped / 5) / minutes);
}

But that raw number is misleading if you typed fast and inaccurately — you'd get credited for errors you then backspaced over. I count only characters that are currently in a "correct" committed state: once you backspace and re-type a character, it only counts once toward WPM.

Accuracy is simpler — total keystrokes versus correct keystrokes at completion:

function calculateAccuracy(totalKeystrokes: number, errorKeystrokes: number): number {
  if (totalKeystrokes === 0) return 100;
  return Math.round(((totalKeystrokes - errorKeystrokes) / totalKeystrokes) * 100);
}

Both are recalculated on every keypress and shown live. Watching your WPM update in real-time as you type is oddly motivating.

The "drill your weak words" loop

This is the feature I was most excited about building, and the one that r/typing has been asking for in various forms for years.

After each race, I track which words you made errors on. Not just "you had 3 errors" — specifically which words those errors occurred in. Then I offer a drill mode that generates a new passage using only those words, repeated and shuffled:

function buildDrillPassage(weakWords: string[]): string {
  if (weakWords.length === 0) return getRandomPassage();

  // Repeat each weak word 2-3x, shuffle, join
  const repeated = weakWords.flatMap(w => Array(3).fill(w));
  const shuffled = repeated.sort(() => Math.random() - 0.5);
  return shuffled.join(' ');
}

The insight: most people have a small set of letter combinations that consistently trip them up — "tion", "the", words with double letters. Random passages rarely hit your specific weak spots enough to train them. Drilling your actual errors does.

The UX is a single button after each race: "Drill your 4 weak words." No friction, no navigation. Most users click it.

The anonymous leaderboard: no login, no friction

I really didn't want to build an auth system. Auth is a solved problem, but it's also friction — every signup form is a place where users bounce.

The leaderboard works like this: pick a handle (stored in localStorage), submit your score. That's it. No email, no password.

// On first visit, prompt for a handle
const handle = localStorage.getItem('clackpit_handle') 
  ?? promptForHandle();

// After each race, submit score
await fetch('/api/scores', {
  method: 'POST',
  body: JSON.stringify({ handle, wpm, accuracy, mode }),
});

Scores are stored in a Cloudflare Worker KV store, keyed by date. The daily leaderboard shows the top 20 WPMs for today. Handles aren't unique — two people can both be "keymaster" — but that's fine. The leaderboard is for fun, not identity.

One thing I added: if you submit a score lower than your existing best for the day, it doesn't overwrite. Your handle shows your peak, not your last run.

The share card

After every race you get a result card showing your WPM, accuracy, and mode. It's copyable text, not an image — partly because generating images serverlessly is a pain, and partly because text shares better across platforms.

The format:

⌨️ Clackpit
97 WPM · 98% accuracy · Standard mode
https://clackpit.launchyard.app

There's a one-click copy button that puts this on the clipboard. Twitter/X, Discord, whatever — it pastes cleanly. The URL is the backlink that makes this worth doing from an SEO perspective, but it also actually sends interested people to a working demo, which is the more important thing.

Wrapping up

Clackpit took about two weeks of evenings to get to something I was happy with. The stack is TypeScript throughout, Cloudflare Workers for the backend, no database beyond KV for leaderboard scores.

The lessons:

Input latency is a product problem, not just a performance problem. Test on slow hardware.
Forced correction is a meaningful product choice that affects what skill users actually build.
Removing signup friction (localStorage handles + anonymous scores) meaningfully increases engagement.

If you want to try it: https://clackpit.launchyard.app

I'd genuinely like feedback — especially from people who type a lot and have opinions about how typing games should work. Drop a comment or find me here.

I built a typing game with the feature r/typing asked for — here's what I learned

Clackpit — Mon, 04 May 2026 01:05:48 +0000

Two years ago, a Reddit moderator named Gary_Internet posted in r/typing and described the one feature that would make a TypeRacer competitor worth switching to:

"The other thing that would really set you apart from Typeracer is to give people the ability to practice all the words that they made mistakes on at the click of a button... 5 repetitions of each word. You'd be in a league of your own."

That comment got 14 upvotes. The original post got 18. And nothing ever shipped.

So I built it.

What I built

Clackpit is a browser-based typing race with three things TypeRacer doesn't do well:

1. Forced correction that actually works

TypeRacer forces you to backspace and fix mistakes before moving on — that's the right call, it trains real accuracy. But plenty of typing sites (looking at you, NitroType default settings) let you barrel through mistakes and just count them at the end. Clackpit uses the TypeRacer model: wrong letter typed, cursor stops, you fix it or you don't advance. No skip, no workaround.

2. The drill loop Gary_Internet asked for

After every race, a "Drill these words →" button appears on the finish screen. It shows every word you made a mistake on during the race. Click it and you get a fresh passage with those exact words interleaved five times each — so if you fumbled "through", "because", and "enough", you get:

through because enough through because enough through because enough...

Forced correction applies in the drill too. You work through your actual weak spots, not random text.

3. Three modes for different use cases

Sprint: a fixed passage, same as TypeRacer — finish line competition
Marathon: long texts (250–600+ words) for typists who want sustained practice, not short bursts
Endurance: timed mode (30s / 60s / 120s) with automatic passage rolls — WPM and accuracy scored at the end

One interesting technical decision

The hardest part of the forced-correction mechanic isn't implementing it — it's making it feel fair. If you type a wrong letter, you need to be blocked. But what about composing characters, dead keys, IME input, and the dozen ways a browser can fire keyboard events before a character is "committed"?

The short answer: keydown + keypress together with a per-character state machine, tracking whether the current character is "incorrect and unresolved" vs "correct" vs "awaiting backspace." Getting that state right for every edge case (paste attempts, autocorrect, mobile soft keyboards) took longer than the rest of the game combined.

What's missing / what I'd love feedback on

The daily leaderboard is anonymous (you pick a handle, it persists in localStorage) — no accounts, no email, no password. That keeps friction at zero but it also means there's no real identity behind a score. I'm curious whether typists care about that, or whether the anonymous daily rank is enough of a hook.

The other thing I haven't done yet: multiplayer. Real-time races against other humans are obviously more exciting than a solo timed run. But multiplayer without users is a ghost town, and a solo typing game with a good drill loop is actually useful on its own. Starting single-player felt right.

Try it at clackpit.launchyard.app — I'd genuinely love feedback from people who actually care about typing. What would make you come back tomorrow?