Forem: Raz Chiriac

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! 🫖