From Golang to Static: Why I Switched to Netlify and AI-First Maintenance
For years, I was a staunch advocate of dynamic backends. My personal website ran on a robust Golang engine, serving pages with the precision and speed that only compiled languages can offer. I had even built a brilliant, custom golang based CMS for it.
Yet, I made a radical decision: I tore it all down. I migrated my entire digital presence to a static architecture hosted on Netlify.
With my deep experience in AI, I wanted to reach a specific milestone: using AI to maintain my website 100%. This sparked a journey to find the ideal tech stack. I evaluated all the major options -- Next.js, React, Vue -- but found none of them suitable for pure AI maintenance.
Why would I abandon the raw power of Go for simple HTML and CSS? The answer lies in a single, transformative goal: I wanted to use AI to maintain my website.
The Static Renaissance with Netlify
Let's start with the hosting. If you haven't looked at the modern static hosting landscape recently, you are missing out. Multiple provders -- GitHub, Gitlan, Vercel and Netlify -- have made the process of deploying simple static sites absurdly simple.
Gone are the days of configuring Nginx, managing VPS security patches, or worrying about database connections. I just push to Git, and seconds later, my site is live globally. They handle SSL, CDN distribution, and cache invalidation automatically. It is the kind of "it just works" infrastructure that lets me focus on creating, not maintaining.
Not only this, but Netlify also has made processing simple forms really simple by saving the posted values on their side.
The Pivot: Designing for AI Maintenance
My decision to switch from Golang wasn't just about hosting convenience; it was about maintainability in the age of AI.
Large Language Models (LLMs) are incredible coding assistants, but they struggle with complexity. A complex Golang application with intricate dependencies, routing logic, backend, frontend, and build pipelines turned up to be a heavy lift for an AI agent. It requires too many explanations and involvement to do the job properly.
Static files, however? They are the native language of the web. HTML, CSS, and vanilla JavaScript are pure, text-based, and declarative. An AI can read a single HTML file and understand exactly what is happening on that page without needing to know about a router in a different directory or a controller in another package.
By simplifying the architecture, I unlocked the ability to have AI agents effectively become my webmasters.
Introducing CleanLit: The First AI-First Web Framework
This philosophy birthed something new. I realized that existing frameworks -- React, Vue, even modern static generators -- were still too complex for seamless AI interaction. They relied on heavy build steps, transpilers, and "magic" that hides the real code.
So, I built my own. I call it CleanLit, and it is the world's first AI-First Web Framework.
It is still HTML, JS, and CSS, but it allows breaking things down into standalone web components, which makes it incredibly easy for AI to work with smaller context windows and more reliably.
You can see it in action here: https://cleanlit.lesichkov.co.uk/home/
The core philosophy is documented in a format designed specifically for LLMs: https://cleanlit.lesichkov.co.uk/llm.txt
CleanLit is built on four pillars:
- AI-First: Compartmentalized architecture where every page is self-contained. AI can edit a page without breaking the rest of the site.
- Zero-Build: No Webpack. No Vite. No waiting. It uses native ES Modules and Web Components. What you see is what runs.
- Human-First: It prioritizes cognitive clarity. No mental gymnastics to trace imports across dozens of folders.
- Security by Design: No
node_modules. No supply chain attacks.
It turns out that the best architecture for AI agents is also the best architecture for humans: simple, standard, and build-free.
The Challenge: Static Search
The migration wasn't without its hurdles. The most difficult part of transferring my blog was reimplementing search.
In my Golang app, search was trivial: a SQL query against the database. In a static world, you don't have a database to query at runtime.
I had to rethink the problem. I couldn't rely on server-side processing. The solution involved generating a search index at "compile time" (or rather, content-generation time) and using client-side JavaScript to query it. It required a shift in mental model -- trading server CPU cycles for a slightly larger initial download and client-side logic. But the result is a search experience that is instant, works offline, and requires zero backend infrastructure.
Conclusion
Moving to Netlify and a static architecture wasn't a downgrade; it was an evolution. By stripping away the complexity of a dynamic backend, I've created a site that is faster, more secure, and most importantly, ready for the future where AI agents sit alongside us in the editor.
If you are still wrestling with complex build pipelines and server maintenance for your personal site, I challenge you to ask yourself: could you go static? The AI revolution is here, and it loves simple code.
