BuildLog

BuildLog is the platform you are reading this on. A personal developer journal with a complete content management system behind it - designed, built and maintained solo, and architected like a small product rather than a weekend script. This case study covers what it does, how it is put together, and the engineering calls that made it work.

The problem it solves

Hosted writing platforms handle distribution but own everything else - presentation, data, audience relationship, and the survival of the archive itself. DIY static sites solve ownership but add friction: every post becomes a commit, every typo a rebuild. Both fail the same way over time. Publishing gets heavy, so writing gets rare.

The thesis behind BuildLog: a personal blog should be run like a product. Instant publishing from a real CMS, a reading experience under full control, a community layer with actual identity behind it, and an archive nobody can deprecate - all on infrastructure that costs effectively nothing to run.

What it does

Writing and publishing. A markdown/MDX editor with a live preview that runs the exact production render pipeline. Drafts, back-dating, featured placement, editable URL slugs, per-entry SEO metadata, and a draft-recovery system - forms autosave continuously, and leaving an unsaved editor offers to persist the work before you go.

Reading. Server-rendered prose with zero client JavaScript for content, syntax highlighting compiled at render time, a scroll-tracking table of contents with a reading-progress meter, adjustable text size, dark mode, view counts, related posts, and keyboard-driven search across the entire library.

Community. A hand-built comment engine. GitHub sign-in is required to comment, which puts a real identity behind every thread. Threaded replies, one-tap moderator reactions, spam throttling, and a moderation console that groups every conversation by article.

Administration. A complete CMS behind OAuth - dashboard with live stats, full CRUD over posts and projects, per-thread comment moderation, and an about-page editor. Every change propagates to the public site in about a second without a redeploy.

Tech stack

Architecture in three sentences

Content is stored as MDX documents in MongoDB and compiled to HTML on the server at request time, so browsers receive finished prose with no hydration cost. Every public read flows through a tag-aware cache: a CMS mutation invalidates exactly the cached queries it affects, which gives instant publishing without a rebuild - and a warm page load runs zero database queries. Authentication is deliberately split in two: an edge middleware guards the admin routes without touching the database, while every mutating API call independently re-verifies the session server-side.

The design language

Neo-brutalism, executed as a system rather than a coat of paint: two-pixel ink borders on every surface, zero-blur hard-offset shadows, and controls that physically press into the page when clicked. Code blocks sit in terminal-style windows; three typefaces carry strict, non-negotiable roles - a serif for headings and prose, a grotesque for interface, a mono for anything technical. Dark mode is a single block of semantic token overrides, so every border and shadow in the product inverts for free. The payoff is consistency that is enforced by the system itself: a new component either speaks the language or visibly does not belong.

The hard parts

Three problems actually earned their place in this build:

Cache correctness without a rebuild pipeline. The goal was brutal: publish from the CMS and see the change immediately, but never let a page load hit the database cold. That required threading cache tags through every read - posts, projects, counts, slugs - and making sure each mutation invalidates precisely its dependencies and nothing else. Too broad and the site re-renders constantly; too narrow and stale content ships. The line it walks: a warm request does zero database work, and a publish lands live in about a second.

Auth across two runtimes. The middleware that protects the admin runs on the edge, where the database driver cannot go; the full session logic runs on the server, where the edge cannot see. Bridging that meant splitting the auth configuration into an edge-safe core and a server-side full config, kept provably in agreement, with JWT sessions so no request ever needs a database round-trip just to answer "are you allowed here." Every write endpoint then re-checks independently - the page shell being guarded means nothing to the API.

The server/client rendering boundary. MDX must compile on the server, but comments, scroll-spy and view counts are inherently client-side. Getting that seam right - server compiles, ships finished HTML, and tiny client islands hydrate only what must be interactive - is what keeps article pages fast. Early versions hydrated far more than they should have, and the bundle numbers were blunt about it.

Results

• A live product at BuildLog with a complete CMS, comment engine and design system - zero paid services
• Roughly twenty routes, fourteen API endpoints, forty-plus components - typecheck-clean throughout
• Publish-to-live latency of about one second, with warm page loads at zero database queries
• Monthly running cost: the domain
• The repository itself serves as the flagship project of the portfolio

Code: RajHarsh03/BuildLog - reading the source is the long version of this case study.