The Scan I Couldn’t Read

At some point in building Hat Trick, I ran into one of those moments where I felt very much like a 50-year-old person pretending to be calm in front of a machine.

A security scan came back with issues.

That sentence sounds tidy. The actual feeling was more like: Oh no, the grown-ups are here.

I was already out over my skis with this project. What started as a soccer trivia game had turned into trivia plus fantasy leagues, accounts, live head-to-head games, API data, legal questions, and payment decisions still waiting in the corner. I had gone from “Wouldn’t this be fun?” to “Why is there a security report and why does it look like it was written for someone with a badge?”

The scan flagged multiple issues. The two phrases I remember most were RLS policies and server-only client.

I will be honest: I did not know what either of those meant when I first saw them.

RLS, I learned, means Row Level Security. In normal-person language, it is about making sure people can only see or change the pieces of information they are allowed to see or change. Not everyone’s stuff. Just their stuff.

That sounded important.

“Server-only client” was another phrase that made my eyes glaze over at first. My rough understanding became this: some operations should happen only behind the scenes, on the private side of the app, not out where a user’s browser can poke at them. Like not leaving the keys to the concession stand taped to the front door.

Again: important.

The uncomfortable part was that the AI proposed fixes, and I had to approve them even though I did not fully understand every line of what it was changing.

That is a strange kind of trust.

It was not blind trust exactly. I did ask questions. I made the AI explain what the warnings meant in plain English. I tried to understand the shape of the problem, even if I could not understand the code itself. Was this protecting user data? Was this moving something sensitive away from the public-facing part of the app? Was this tightening who can access what?

If the answer was yes, and the explanation made sense, I approved it.

But I would be lying if I said I felt confident the whole time.

There was a part of me thinking, Should I be allowed to click this button? Another part was thinking, Well, not fixing a security issue because I feel embarrassed would be worse.

That has been one of the recurring tensions of this whole project. The AI can move fast. Shockingly fast. It can rename an entire app in seconds. It can build features I would not have known how to start. It can explain a broken signup flow and make me feel less foolish for clicking the same dead-looking button until I got rate-limited.

But speed does not remove responsibility.

Security was the first area where that really sank in for me. With colors or copy, I can use my eyes. With a fantasy landing page, I know when it feels boring. With a trivia question, I can tell if it is too easy.

With security, I am much more dependent on explanation and trust.

So my rule became simple: I do not need to understand every technical detail, but I do need to understand the reason for the fix. If I cannot explain it back in plain English, I ask again.

That is slower than just saying yes to everything. It is also a lot less magical. But it feels safer.

I still approved fixes I did not fully understand. That is the honest truth. I am not going to pretend I suddenly became a security expert because a scan used scary words at me.

But I did understand enough to know this was not cosmetic. It was not another magenta word in a hero section. It was about making sure the app did not expose things it should not expose.

And for a project that had already grown bigger than I meant it to, that felt like a line I had to take seriously.

What I learned: if the AI is going to fix something important, I need it to explain the “why” before I approve the “what.”