The Three Lines
what started on a paper, now lives on the internet
On a Friday in December I tried to remember what I'd worked on in February. I couldn't. Not vaguely — completely. Nine months of closed tickets, shipped features, fixed bugs. I had the git history. I had the commit messages. But I had no memory of what any of it felt like, why certain decisions got made, what broke first, what I learned. Just a wall of green squares and merge hashes that could have belonged to anyone.
I kept thinking about that. If I can't remember what I did, did it even matter?
By the end of 2025 I'd shipped things, worked on things. But no trail. Close a bug, move on, forget it ever happened. Ship a feature, forget how it worked two months later. A whole year of work that had already started dissolving.
On a train to Dresden, I wrote three things on a piece of paper.
- Extension to my brain
- Zero friction
- Track everything I do
No wireframes. No tech decisions. No feature list. Just those three lines — not a spec, a reaction. Something had been lost and these were the constraints that might get it back.
Line 1: Extension to my brain
When I told people I was rebuilding the portfolio, everyone said the same thing. Astro. Jekyll. Pick a blog generator, use a template, done in a weekend.
I get it. On the surface it looks like a blogging problem. But that framing is exactly what I was trying to escape.
A blog is a place you publish things. What I wanted was somewhere to think — not just somewhere to post. The difference matters more than it sounds. When you build for publishing, you edit toward publishability before you've even had the thought. The audience enters the room before you've finished the sentence. Everything gets shaped for a reader that isn't there yet, and the half-formed stuff — the actually interesting stuff — never makes it out of your head.
Memory for a developer isn't git history. Git history tells you what changed. It doesn't tell you why you made the call you did at 11pm, what you tried first that broke, which decision you're going to regret in six months, or what it felt like when something finally worked. That context is the thing that compounds. Without it, every project starts from zero.
So not a blog. Something closer to a working record — a system that accumulates context as long as I keep working, and makes it retrievable when I need it.
Line 2: Zero friction
On my old site I wrote maybe four posts in two years.
Not because I had nothing to say. The friction killed it every time. Publishing anything required touching the repo — markdown file, frontmatter, commit, push, deploy. That's five steps between a thought and it being out there. Five steps is enough to talk yourself out of it. Enough to decide the thought isn't finished yet, isn't polished enough, can wait until the weekend. It never gets published.
So I pulled the content layer out of the codebase entirely. Payload CMS as the backend, Postgres in production, SQLite locally for dev. Now I open the admin panel, write, hit publish. That's the whole process. The time between thought and post is the time it takes to type.
The infrastructure decision came from the same place. Vercel was the obvious call — zero config, great DX, deploys in seconds. I went with Hetzner instead, self-managed, running Coolify. Not because Vercel is bad. Because every time I've used a managed platform I've understood less about what I was building. For someone else's project that's fine. For something that's supposed to be an extension of how I work, I wanted to understand every layer. The tradeoff is real — no edge servers, slower load for someone far away. I knew that going in. A second slower is fine.
Zero friction has to work at every level, or it doesn't work. A fast CMS on a platform I don't understand is just friction in a different place.
Line 3: Track everything I do
On most portfolio sites — including my old one — a project is a frozen moment. Name, description, tech stack, screenshot. Done. But building anything takes months, and all that context — the decisions, the rabbit holes, the things that broke — disappears. What's left is a postcard from a place you've already forgotten.
Every piece of content on the site is tagged. Blog posts, devlogs, error logs, social posts. Those tags connect back to projects. Open a project page and you don't just see what it is now — you see everything I wrote while building it. Not a showcase. A thread. Something that keeps accumulating as long as I keep working on it.
Here's what that looks like in practice: I'm building a feature, something breaks in a way I don't understand, I write an error log — what I tried, what failed, what eventually worked. That log lives on the project page. Three months later when something similar breaks, I have the record. The context isn't in my head anymore, and it doesn't have to be. It's in the system.
The private posts idea
Not everything in that thread needs to be public.
There's a lock on individual posts — mark something private and it stays in the system, counts in my own record, shows up in the admin. It just doesn't render on the public site. The trail is still there. It's just mine.
This matters more than it sounds, because it solves a problem I didn't fully name in those three lines on paper: if everything has to be publishable, you write less. The audience changes what you think. You start editing before you've started thinking. The half-formed note, the embarrassing wrong turn, the thing you're not sure about yet — all of it gets filtered out before it ever gets written down.
But that's exactly the stuff worth keeping. A brain doesn't publish its drafts. It holds them, uses them, sometimes discards them. The system should work the same way. Private posts aren't a concession — they're the feature that makes the whole thing honest.
Design last, on purpose
The design came last and it was a deliberate break from what I usually do.
I've always defaulted to dark — dark background, bright text. This time I wanted something that felt like paper. Light, editorial, room to breathe. The kind of page you might actually stay on for a few minutes instead of scanning and leaving.
No hero section. No tech stack ticker. No "available for work" badge. Tabs for writing, projects, experience, favorites. A commit counter. A reading section that shows not just what I'm reading but how far through it I am — progress bar by page count, and notes I add as I go.
Less portfolio, more dashboard of how I actually operate.
Design followed function here, not the other way around. The system existed first. The aesthetic emerged from what the system needed to feel like — something you'd return to, not something you'd glance at.
Where it actually stands
The favorites page is still empty. Some features are still coming. That's fine.
I don't know yet if any of this works the way I intend it to. The system is there. The question is whether I'll use it — whether six months from now I'll have a different kind of nothing to show, a beautiful empty database instead of a blank git log. That's a real possibility and I'm not going to pretend otherwise.
But at least now the infrastructure for memory exists. The three lines on that paper were a reaction to loss — a year of work that had already started disappearing. Whether this fixes that, I'll know in a year.
The repo is at github.com/brgv-code/2026.bhargav.dev. The site is at 2026.bhargav.dev.
If any of this is useful for your own setup, take what you want.
Technically: Turborepo monorepo, pnpm, Next.js 16 (public site) + Next.js 15 with Payload CMS (admin/API), Postgres in prod, SQLite in dev, custom markdown-to-Lexical import plugin, self-hosted on Hetzner via Coolify.