TL;DR: This post tracks four architectural rewrites of my personal site over ten years. I cover the move from managed platforms (Blogger) to dynamic backends (Django), and finally to static generators (Jekyll/Hugo). Beginning in 2025, I stripped away all external themes and heavy frameworks to build a zero-dependency, vanilla-web architecture from the ground up for absolute control and performance.

Technical Context

For an engineer, a personal site is the only project where you have absolute authority over the stack. There are no product managers, no legacy constraints, and no enterprise technical debt: you own the metal.

Over the last decade, my approach to this site has evolved from simple content publishing to a pursuit of complete technical control. This is the timeline of that evolution.

2015–2018: Managed Platforms (WordPress & Blogger)

Stack: WordPress.com -> Blogger.com
Links: villageprogrammer.blogspot.com

The initial goal was low-friction publishing. I started on WordPress in 2015 because it was the default, then moved to Blogger in late 2017 to create “Village Programmer” and get slightly better access to the underlying HTML/XML templates.

Technical Trade-off: Control was completely sacrificed for convenience. The rendering pipeline was a black box. The UI was composed of unmanaged CSS and proprietary widgets injected by the platform. Portability was non-existent; the content was locked in a managed ecosystem. I could write, but I couldn’t engineer.

2018–2020: Dynamic Architecture (Django & PostgreSQL)

Stack: Django + PostgreSQL + Nginx
Links: Self-hosted Linux instance

By college, I had learned MVC patterns and relational databases. Naturally, I assumed my blog needed a backend. I migrated everything to a custom Django application.

The Trade-off: Operational overhead was the primary failure point. Managing a relational database and a Python runtime for a read-heavy, low-write blog is an architectural mismatch. The maintenance burden, including security patches, database backups, and server monitoring, became a distraction from actually writing or building new features. I learned that “Full-Stack” often just means “more things to break”.

2020–2024: Static Site Generators (Jekyll & Hugo)

Stack: Jekyll -> Hugo (Even Theme)
Links: vk4s.github.io

I eventually recognized that a blog is an immutable dataset that should be pre-compiled. I migrated to the Jamstack: first using Jekyll on GitHub Pages, then porting to Hugo for sub-second build times. My content was finally decoupled from the infrastructure, living purely as Markdown in a Git repository.

The Trade-off: Performance and portability were solved, but I was still using an off-the-shelf theme (“Even”). Modifying the site’s behavior meant fighting against foreign CSS conventions and non-essential JavaScript dependencies. It was fast, but it wasn’t mine.

2025–2026: Custom Architecture (Zero Dependencies)

Stack: Hugo + Vanilla Web Technologies
Links: lorbic.com (Engineering Blog) / vikashpatel.net (Portfolio)

The current iteration of lorbic.com is a complete rewrite. Beginning in early 2025, I started stripping away the layers of accumulated technical debt: removing heavy CSS frameworks like Bootstrap, and deleting bloated JavaScript dependencies like jQuery and Zoom JS.

The mandate was strict: zero external dependencies, zero CSS frameworks, and maximum performance through native primitives. I separated my portfolio (vikashpatel.net) from my engineering writing (lorbic.com).

Engineered Features

Instead of importing “black box” plugins, I implemented focused, vanilla solutions for specific needs.

1. Command Palette (Terminal-inspired UI)
Navigation is handled via a native terminal overlay (Cmd+K). It utilizes a pre-compiled JSON search index and a custom routing engine. This allows for instant theme toggling and site-wide search without the overhead of heavy third-party search libraries.

2. Contextual Selection Tooltip
Standard anchor links are static. I engineered a tooltip that hooks into the browser’s Selection API. Highlighting text creates a Text Fragment URL (#:~:text=...), allowing readers to share exact paragraph references.

3. Interactive Data Tables
All Markdown tables are wrapped in a custom JS observer. This adds an interactive action bar to every dataset, enabling one-click “Copy to Markdown” and “Download as CSV” functionality. It relies purely on the DOM; zero external CSV-parsing libraries are required.

4. Performance Telemetry HUD
To maintain performance hygiene, a real-time HUD tracks metrics via the Navigation Timing API. It displays DOM load times (typically < 40ms) and network payload sizes directly in the viewport.

The Backstage Workflow

While the site is static at the edge, the management layer is automated.

I manage the publication pipeline using custom Python tooling via Poetry. Scripts residing in the scripts/ directory handle automated backups of my self-hosted Listmonk newsletter instance and schedule content distributions.

The deployment pipeline is a standard Git-based CI/CD flow via GitHub Actions, which builds the static site via Hugo and pushes the optimized assets to the CDN.

Building your own blog engine is not about necessity. It’s about forcing yourself to understand the boundaries of the systems you use.

By stripping away managed platforms and heavy themes, I had to solve core problems in CSS containment, the critical rendering path, and DOM performance manually. The result is an infrastructure that behaves exactly as designed, served as fast as physics allows.