DEV Community: Raz Chiriac

I built a sudoku app where the AI coach is never allowed to be wrong

Raz Chiriac — Mon, 05 Oct 2026 14:43:21 +0000

I play sudoku most mornings. Every app I tried was either slow to enter digits, covered in ads, or both. So I built Kodiak Sudoku, and along the way I ran into three problems that turned out more interesting than I expected.

1. Making 81 cells feel instant

A sudoku board is 81 cells, each with up to 9 pencil marks. If typing a digit rerenders the whole grid, you feel it, especially on a cheap phone.

What worked:

Zustand with one selector per field. Each cell subscribes only to its own value, its notes and whether it's selected. Typing a 7 rerenders one cell, plus the cells that need to highlight matching 7s.
Notes as bitmasks. All 81 cells' notes live in a single Uint16Array. Bit 3 set means "3 is a candidate". Toggling a note is one XOR, and comparing two cells' notes is one integer compare, which makes the memoized cell comparator trivial.
Keyboard first. Arrow keys or hjkl to move, digits to place, N for notes mode, U and R for undo and redo, ? for the full list. One window-level listener reads from the store directly, so there's no React state in the hot path.

// toggle candidate d (1-9) in cell i
notes[i] ^= 1 << d;

// is d a candidate?
const has = (notes[i] & (1 << d)) !== 0;

2. A daily puzzle you can't cheat

The daily puzzle has a leaderboard, and a leaderboard is only worth anything if it's honest. The rule I set early: the solution never reaches the browser.

The client gets the givens only.
Hints go through a server action that looks up the stored solution, returns one cell, and records that you used a hint.
When you finish, the server compares your board with the stored solution before writing a completion.
Anonymous solves don't count toward the board. You can play without signing in, but the leaderboard needs an account.

Hints are allowed on the daily, and the board shows how many each player used. That turned out fairer than banning them. There are now weekly, monthly and all-time standings too, ranked by dailies solved and then average time.

3. An AI coach that can't hallucinate a move

This was the part I was most nervous about. I wanted a coach that looks at your actual board and says something like "look at box 5, the 4 can only go in two cells". Language models are good at that kind of explanation. They are also very good at confidently suggesting a digit that's wrong.

A wrong digit on someone's board is the worst possible failure. It's silent, and it breaks trust in everything else. So the design is:

The model sees the board, never the solution. It has to reason about the position like a person would.
The output is a strict schema. A short nudge, a one-sentence reason, and an optional move (cell plus digit). Anything that doesn't parse is thrown away.
Every suggested move is checked server-side against the stored solution and against the deterministic solver's next step. If it fails, the move is dropped and only the explanation is shown.
There's a 2.5 second budget. If the model is slower, the player gets a deterministic hint from the solver with a canned explanation for that technique. The panel never comes back empty.
The client can't redirect the check. Each request verifies that the submitted board's givens match the original puzzle, so a tampered board can't point the validator at a different solution.

The validation function is the most heavily tested code in the project. Rejected moves are logged, so I can see if a model update starts guessing more.

Teaching, not just solving

The coach works best when the player knows the vocabulary, so I added a Technique Journey: 15 short lessons from naked singles to swordfish. Each lesson is a real, verified puzzle you solve in place, and the same boards show up inside the blog posts, so you can try an x-wing right next to the explanation.

Stack

Next.js 15 (App Router), React 19, Supabase for Postgres and auth, Drizzle with hand-written SQL migrations, Zustand, Zod at every server boundary. Hosted on Vercel. Payments are Stripe Checkout called with plain fetch, no SDK. Puzzles come from a public dataset of 3 million rated sudokus, bucketed into four difficulty levels, and every one is checked by the solver for a unique solution.

How it pays for itself

The game, the daily, the leaderboards and the lessons are free with no ads. Kodiak Plus adds the AI coach, AI post-game debriefs and unlimited quick play. Everyone else still gets solver-based hints. There's also an Android app.

If you play, I'd love to hear how the keyboard controls feel and whether Hard is actually hard. The daily puzzle resets at midnight UTC.

How I built the sudoku site I always wanted (Next.js 15, Supabase, keyboard-first)

Raz Chiriac — Sun, 10 May 2026 15:17:14 +0000

Every sudoku site I've ever used has the same two problems: ads everywhere, and a mouse-only UI that makes fast solving feel clunky. I play sudoku to think, not to fight with my browser.

So I built my own. It's called Kodiak Sudoku — free, no ads, keyboard-first, with vim bindings and a leaderboard that doesn't lie. Here's what went into it.

The stack

Next.js 15 with the App Router
React 19
TypeScript throughout
Supabase for the database (auth, leaderboard storage, daily puzzle state)
Drizzle ORM on top of Supabase
Tailwind CSS
Vercel for hosting + Edge Config for feature flags

Nothing exotic — just a stack I could move fast with and trust in production.

The three things I actually cared about

1. Free with no ads

This sounds simple but it shapes every decision. No ad SDK to load, no layout shift, no third-party trackers. The page is fast because there's nothing slowing it down. I'm covering hosting costs out of pocket for now — Vercel and Supabase's free tiers go surprisingly far for a side project at this scale.

2. Keyboard-first, with vim bindings

Most sudoku sites are built for mouse/touch. Clicking individual cells is fine on mobile, but on desktop it's slow. I wanted to navigate the board the way I navigate everything else — with hjkl, or arrow keys, or number keys to fill in digits instantly.

The input handling ended up being one of the more interesting parts of the build. React's synthetic event system and the browser's native focus behavior don't always agree, especially when you're trying to make a grid feel like a text editor. Getting vim-style navigation to feel snappy without fighting the DOM took a few iterations.

If you're into this kind of thing — keyboard-driven UIs, focus management, accessibility — I'd love to hear how you've solved similar problems.

3. Honest leaderboards

This one bugged me about every other sudoku leaderboard I've seen: hint-assisted times compete directly against pure runs. Someone who used three hints finishing in 4 minutes shouldn't outrank someone who solved it clean in 5.

Kodiak separates the two. Pure runs and hint-assisted runs are ranked independently. It's a small thing but it changes how the leaderboard actually feels — it's something you can be proud of, not just a number.

Interesting technical bits

Daily puzzle state at the edge

The daily puzzle is the same for everyone, every day. I'm using Vercel Edge Config to store and serve the active puzzle, which means the puzzle data is globally distributed and available with essentially zero latency. State per-user (progress, timer, hints used) lives in Supabase.

Drizzle + Supabase

I'd used Prisma before and wanted to try Drizzle. The type inference is excellent and the query builder feels closer to writing SQL, which I prefer. The integration with Supabase was smooth — I'm using Supabase for auth and RLS policies, with Drizzle handling the query layer.

Puzzle generation vs. curation

I ended up curating puzzles rather than generating them on the fly. Generated puzzles can technically be valid but feel mechanically similar. Hand-selected (or at least filtered) puzzles have more character. For the daily puzzle specifically, I wanted something people would actually enjoy solving, not just a valid grid.

What I used Claude for

Claude was my pair-programmer throughout. Not in a "it wrote the whole thing" way — more like having a senior dev available to rubber-duck architecture decisions, catch edge cases in my input handling logic, and help me move faster on the parts I found tedious (writing marketing copy, mostly).

The parts that required actual judgment — how to structure the leaderboard, how to handle timer state across tab visibility changes, how to make the keyboard UX feel right — those were conversations, not prompts. Worth being honest about the difference.

What's next

The site is live now at kodiaksudoku.com. Daily puzzles, leaderboards, full keyboard support including vim bindings.

Things I'm thinking about for v2:

Mobile experience improvements (touch is functional but not delightful yet)
Puzzle difficulty ratings based on solving technique, not just time
A "practice mode" for specific techniques (naked pairs, X-wing, etc.)
A Loom walkthrough once I've seen how real users actually play

If you build keyboard-first apps, care about honest UX, or just play a lot of sudoku — I'd genuinely love to hear from you. What would make this better?

Built with Next.js, Supabase, Drizzle, Tailwind, and Vercel. Pair-programmed with Claude.

Console Wrangling

Raz Chiriac — Sun, 14 Aug 2022 16:15:05 +0000

Have you ever console logged the console?

So you know the good ol’ console.log() ?

Well, that’s not the only thing the console can do, it’s only the most basic.

Have you ever used the console to log the console? No? You should try it.

The console will show you what the console can do.

Today we’ll talk about two of the functions available on the console object:

console.table() and console.trace()

Lets say we have two objects:

const carA = {make: 'Ford', model: 'F150', year: '2018', color: 'white'}
const carB = {make: 'Ford', model: 'F250', year: '2016', color: 'blue'}

If we wanted to do some debugging and had to print these objects out to the console we could use console.log() but it wont look too nice.

Look how neat console.table() can display the two objects:

You can even sort the two rows by column just by clicking on the headers!

One other console function we’ll talk about today is console.trace(). This will output a stack trace to the console.

And that’s all for today.

I hope I’ve helped make your debugging a little less boring. Now go show off your new console skills in your next stand-up.

Cheers!

Object Equality in JavaScript

Raz Chiriac — Sat, 13 Aug 2022 16:33:00 +0000

Howdy! Here’s a simple way to check for object equality.

Let’s say we have two objects:

const carA = {make: 'Ford', model: 'F150', year: '2018', color: 'white'} const carB = {make: 'Ford', model: 'F150', year: '2018', color: 'white'}

We can see that carA is the same as carB. So we would expect carA === carB to return true but it does not. This is because JavaScript checks for equality on non-primitive types like Objects, Arrays and Dates by reference. This means, JavaScript checks if the two objects point to the same place in memory, not if they have the same key-value pairs.

One way to check for key-value equality of two objects, without the use of an external library or much coding is by converting the objects to strings using JSON.stringify() .

carA == carB // => false
carA === carB // => false

JSON.stringify(carA) === JSON.stringify(carB) // => true

Keep in mind that this approach only works if the key-value pairs are in the same order on both objects. We could go into sorting object entries by key and other approaches in future posts.

Cheers! 🫖