lkmail.me

lkmail Update 1.21: Hitting the Brakes and Embracing KISS

Welcome to Update 1.21 of the lkmail development journey. Today, we are hitting the brakes.

If you read my last post about resolving the "invisible wall" between build time and runtime secrets on Cloudflare's Edge, you might have thought: "Wow, that's a clever solution." But stepping back from the keyboard this week, my primary thought was: "Wow, I have completely lost track of what I am building."

The architecture had become way too complicated. We were jumping through burning hoops to satisfy a complex Static Site Generation (SSG) pipeline, managing dual-environment secret vaults, and wrestling with CI/CD compiler rules—all just to display a simple list of GitHub projects.

It is time to do an architecture audit, dial back the technical gymnastics, and return to a foundational engineering principle: KISS (Keep It Simple, Stupid).

The "Complex AI Bias" Trap

Modern development often involves leaning heavily on AI coding assistants. While they are incredible tools for productivity, they come with a hidden trap that I fell right into: Complex AI Bias.

When you ask an AI how to fetch data in Next.js, it doesn't just give you the simplest way to get data on a screen. Because it is trained on enterprise-grade documentation and "best practices," it often defaults to the most robust, highly optimized, and technically complex architecture available.

I asked for a portfolio page, and I was guided into an enterprise-level Edge-cached SSG architecture. Before I knew it, I wasn't coding a website anymore; I was managing infrastructure boundaries. AI tools are fantastic at helping you write complex code, but they won't tell you when that complexity is entirely unnecessary for your specific use case.

Auditing the Architecture: The 1.20_6 Retrospective

Let's look back at the highly technical fix from Update 1.20_6. We forced Next.js to bake our GitHub API response into static HTML during a remote Cloudflare build process.

Why it was too complex:

  1. Pipeline Friction: We had to configure separate variables for the build environment and the runtime environment just to authenticate a simple API call.
  2. Stale Data: By baking the data at build time, my GitHub star counts and project lists will never update unless I manually trigger a new deployment.
  3. Debugging Hell: Testing required pushing code to a remote server and waiting for a CI compiler to finish, breaking the local feedback loop.

The KISS Alternative: If we had just stopped and asked, "What is the simplest way to show a user my GitHub repos?", the answer wouldn't have been SSG.

The KISS approach is simple Client-Side Fetching. Instead of fighting the build compiler, we could have just allowed the browser to fetch the data directly when the user visits the /projects page. No build secrets. No CI container isolation. Just standard React, fetching data exactly when it's needed. Yes, it might take a fraction of a second longer to load on the user's screen, but it saves hours of architectural overhead and pipeline maintenance.

The Rebuild Strategy

Going forward, we are stripping away the bloat. We will be auditing the entire codebase with this new, less-technical, highly pragmatic mindset.

Our new rules for the lkmail rebuild:

Conclusion

Sometimes, the best technical fix isn't figuring out how to configure the complex system—it's deleting the complex system entirely.

By embracing KISS, we lower our cognitive load, reduce bugs, and actually have fun building again. With this simpler, cleaner architecture in place, we are finally ready to tackle the Contact UI—and this time, we are doing it the easy way.