What You Only See After Building the House
Learning to look at my own site through someone else's eyes — ignoreBuildErrors, security gaps, duplicate Git structures. Building and maintaining are different muscles.
unstackd.io went live.
I connected the domain, changed the nameservers, typed the address into my browser. The familiar screen appeared. Hero slogan, timeline, footer. Everything was there. I felt good.
But feeling good and being right are different things.
I reviewed the site as a "product," through the eyes of four experts: a senior web developer, a UI/UX designer, a security specialist, and a service developer. All four were AI, of course. But the issues they raised were real.
The results were longer than expected.
First issue: ignoreBuildErrors: true.
This was a setting I'd added weeks ago whenever build errors appeared. "Build anyway, even if there are errors." By the logic of someone who doesn't know programming, it was reasonable. If there's an error, the site won't load; if the site won't load, I can't make progress—so just get it up and running.
The problem was that this was the equivalent of cutting the seatbelt and driving.
TypeScript checks whether types in your code match. If you define "this variable must be a number," it warns you at build time when you accidentally pass a string. I had turned off all those warnings.
It took ten commits to fix.
Second issue: security.
The admin API had no input validation. Meaning—when someone sends data to the server, they could slip in arbitrary fields beyond the intended ones like "title," "content," or "status."
The odds of a hacker targeting a one-person site are low. But "low probability" doesn't mean "no need to act."
I created a whitelist. A predefined list of allowed fields; anything not on the list gets discarded.
I didn't write a single line myself. AI wrote it. All I did was instruct: "This security vulnerability exists—fix it."
The third issue was a bit embarrassing.
There was a massive empty space at the bottom of the homepage. With only nine entries, you had to scroll forever to reach the footer. Two causes: the hero section had a "minimum height of 75%" and the content area had a "fill all remaining space" property.
I didn't notice when building it. Properties I'd added thinking "this will look nice" created blank space when there were few entries. Things you only see after it's finished.
And the most confusing problem: the Git structure.
There were two .git directories inside the project folder. One at the root, one inside site/. Both pointed to the same GitHub repository, but each was tracking code from a different point in time. Some fixes were applied at the site/site/ path, others at site/.
This happened because I didn't set up the structure properly when I first created the project. In Episode 02, I learned that "planning comes before code"—and here that lesson repeated itself.
Today I deleted the duplicate site/.git, cleaned up redundant files. Three old prototype versions, three completed task documents, seven duplicated documents, empty folders, cache files. More than twenty unnecessary files had accumulated in the project.
One thing I realized through this process.
Building is exciting. Adding features, seeing something appear on screen, pressing the deploy button to publish it to the world. There's a sense of achievement in that.
But reviewing is boring. Fixing type errors, validating security, removing empty space, organizing folders. This isn't creating something new—it's refining what's already built. Sometimes there's no visible change on screen.
For someone with only evening hours, carving out time for this boring work is hard. There's always the temptation to build one more feature in those limited hours.
So I decided to make it a rule. For every three new features, one review session. The 3:1 rule.
Once you've built the house, you need to look up at the roof sometimes.