Why I Deleted My Admin Panel

A few weeks ago, my blog had authentication. It had protected admin routes. It had a dashboard where I could draft posts, upload images, and manage content without touching code. It was everything a "real" blog is supposed to have.

Yesterday, I deleted all of it.

Every auth route, every admin component, every database migration related to users and sessions — gone. The commit message was blunt: Remove all admin features, auth routes, and related files. And it was the best simplification I've made to this project.

What I Built (And Why)

When I started PanhaInsight, I followed the playbook every tutorial teaches:

• Users need to log in, so add authentication
• Admins need a dashboard, so add protected routes
• Content needs to be manageable, so add a CMS interface
• Images need to be uploaded, so add a storage layer

I used NextAuth for authentication, Prisma for the user database, and a set of React components for the admin panel. It worked. I could log in, write a post in a rich text editor, and publish without writing markdown or running git push.

The problem? I was the only user. I was the only admin. I was building infrastructure for a team of one, and that infrastructure came with a cost I didn't fully see until I paid it.

The Hidden Tax of Features

Every feature you add to a project has three costs:

1. Complexity cost

Authentication means sessions, tokens, password handling, and security updates. Admin routes mean middleware, role checks, and protected API boundaries. A CMS means state management, form validation, error handling, and UI maintenance. Each piece is small on its own. Together, they become a second project living inside your first one.

My codebase had more lines of auth and admin code than blog rendering code. Think about that. The tooling to publish content was larger than the code that actually displayed it to readers.

2. Cognitive cost

Every time I wanted to add a feature to the blog itself — a tag filter, an RSS feed, a podcast page — I had to navigate around the auth system. Is this route protected? Does this API need a session check? Will this change break the admin dashboard? The auth layer wasn't just code; it was friction.

3. Deployment cost

Auth requires environment variables. Database connections. Secret rotation. On Vercel, every deployment had to have the right NEXTAUTH_SECRET, the right DATABASE_URL, the right callback URLs for OAuth. One misconfiguration and the admin panel broke. For a blog.

The Realization

The breaking point came when I wanted to write a post from my phone. I opened the admin dashboard on mobile and it was unusable. The rich text editor wasn't responsive. The image uploader failed. I couldn't publish.

So I did what I should have done from the start: I opened the GitHub app, edited a markdown file, and committed. It worked perfectly. The post went live in under a minute.

That experience broke the illusion. I didn't need an admin panel. I needed a text editor and git. I already had both. Everything else was theater.

What I Kept (And Why It's Enough)

The simplified architecture is almost embarrassingly small:

• Markdown files in content/posts/ and content/podcasts/
• YAML frontmatter for metadata — title, date, tags, summary
• Git for version control and deployment
• Vercel for hosting with automatic builds on push

That's it. No database. No auth. No admin interface. No CMS.

The workflow is:

1. Write a post in any text editor
2. Save it as a .md file in content/posts/
3. git add, git commit, git push
4. Vercel builds and deploys in ~30 seconds

It works from my laptop, my phone, or any machine with git. It's faster than logging into a dashboard. It works offline. It's backed up by default. And the entire history of every post is in git log.

What About Images?

This was the one real gap. The admin panel had an image uploader that stored files and returned URLs. Without it, I needed a different approach.

My solution: I store images in the public/images/ directory, commit them with the post, and reference them in frontmatter:

coverImage: "/images/systemDesign.webp"

For a blog that publishes a few times a week, this is trivial. For a high-volume newsroom, it wouldn't scale. But I'm not a newsroom. I'm one person, and this scales perfectly to one person.

The Lesson

Software engineers have a bias toward building. We see a problem and reach for a framework. We see a workflow and want to automate it. We see a blog and think it needs a CMS.

Sometimes the best solution is the one that already exists. Markdown is forty years old. Git is twenty years old. They are boring, stable, and more capable than most proprietary tools. Using them isn't a compromise — it's a choice to stop inventing problems.

The commit that removed the admin panel deleted hundreds of lines of code. It deleted dependencies, environment variables, and database tables. It made the project smaller, faster, and more resilient.

And it made me write more. Because when publishing is git push instead of logging into a dashboard, navigating a CMS, and fighting a WYSIWYG editor, the friction disappears. The blog becomes a place for writing, not for managing software.

---

The best feature is the one you delete before anyone notices it was there.