BUILDING IN KOREA
Manballers Devlog — Episode 05
Teaching a Database What a Good Spot Looks Like
Connecting Supabase turned out to be the easy part. Deciding what actually makes a barefoot walking spot “good” — in a way a database could store — was the real problem.
The map was working. Google Maps loaded on localhost, centered on Seoul, exactly like it had since the last episode. But it was an empty map — no pins, no places, nothing to actually click on. The next step was Supabase: the database that would hold every barefoot walking spot Manballers would ever have.
Before any of that, I needed to answer a question I hadn’t thought through at all. What information does a single “spot” even need?
01
What Is a Table, Actually?
I asked Claude to explain Supabase in the simplest terms possible. The answer: think of it as a very structured spreadsheet living on the internet. A “table” is one sheet — Places, in my case. Each row is one location. Each column is one piece of information about that location.
That framing helped more than anything else. I wasn’t designing a database. I was designing a spreadsheet with rules.
02
Deciding What “Good” Means, in Columns
This was the part I underestimated. It’s easy to say “rate the spot.” It’s harder to decide what specifically gets rated, in a way a stranger three cities away could fill out consistently.
With Claude, I landed on a first version of the Places table:
name
The place name — a park, a stretch of beach, a trail with no formal name at all.
latitude / longitude
The exact coordinates, since so many good barefoot spots don’t have a real street address to begin with.
surface_type
Soil, grass, sand, or mixed — the single biggest factor in whether a spot is actually comfortable underfoot.
safety_rating
A simple score — glass, sharp debris, and traffic proximity are the main things this is trying to capture.
accessibility_rating
How easy the spot is to actually reach — parking, transit, walking distance from the nearest road.
facilities
Whether there’s somewhere to rinse your feet or wash up afterward — small detail, surprisingly high impact on whether people come back.
checkin_photo
A live, real-time photo field — the “I walked here today” proof, rather than a static review written once and left to go stale.
Seven columns doesn’t sound like much written out. It took longer to argue myself into than I expected — mostly deciding what to leave out.
03
Connecting Supabase to the Project
The actual connection was simpler than the table design. Inside the Supabase dashboard, creating a new project took a couple of minutes. Claude walked me through generating an API key and a project URL, then adding both into a local environment file in the Next.js project — the file that keeps secrets out of the code itself.
I typed the table structure into Supabase’s table editor, column by column, matching the list above. Watching it turn into an actual empty table, sitting there waiting for rows, was oddly satisfying — a spreadsheet that also happened to be a real database.
04
The First Row
To test the connection, I added one row by hand, directly in the Supabase dashboard — a real spot near where I live, filled in manually with made-up-but-plausible ratings.
Then, back in the code, Claude helped wire up a simple query to pull that row and log it to the browser console. Seeing that one object — name, coordinates, surface type, all of it — actually come back from the database instead of sitting in a spreadsheet felt like a bigger milestone than the map itself had a couple of episodes ago.
I wasn’t designing a database. I was designing a spreadsheet with rules.
Next up: getting that data to actually show up as a pin on the map, and building the form that lets someone add a new spot without touching the Supabase dashboard directly.
Up Next
Episode 06 — Starting Over From Zero
Back to zero base.