From MERN to Modern: Rethinking My Personal Site as a Product, Not a Portfolio Piece

Five years ago, I built my personal website to prove I could. Today, I'm rebuilding it to actually be useful.

---

The Original Sin: Building for the Resume

When I first put together my personal website, I was deep in the mindset of proving technical competence. React on the frontend, NestJS handling the API layer, MongoDB as the data store, and AWS doing the infrastructure heavy lifting. It was a MERN-adjacent stack with some opinionated choices, and it worked — not because it was the right tool for the job, but because it demonstrated that I understood full-stack architecture.

That was the goal. And it was a reasonable one at the time.

But here's the thing about goals: they expire. The thought that once said "I know how to wire together a distributed web application" now quietly says "Is this even a good landing page?"

---

Then vs. Now: A Shift in How I Think About Software

The old me was thinking more moving parts meant more to talk about in an interview. Every architectural decision was also a conversation starter and a technology I learned.

After shipping several products and marking checkboxes for hundreds of requirements, The current me thinks about the same problem through a product lens:

• Who uses this site?
• What do they need from it?
• What's the simplest system that reliably serves those needs?
• What's the cost of maintaining this over time?
• What are the data and control flows in this architecture?

These aren't harder questions — they're just different ones. And asking them honestly forced me to confront some uncomfortable truths about what I had actually built.

---

Who Actually Touches This Architecture?

After some flow charts, it came down to two groups:

Me (the content creator):

• Writing and updating content
• Adding portfolio project descriptions

Anonymous visitors:

• Reading articles or checking out my work
• Arriving mostly from search or referral links
• Entirely read-only user flows

That's it. The anonymous visitor has no account. No complex relational queries that reference them. The site is, fundamentally, content about one person's thoughts, portfolio, and professional journey.

A NestJS API with MongoDB was not built for this type of visiting user. I could have used it to build my own CMS project. This stack is for applications with complex business logic, authenticated users, and dynamic data requirements. I had none of those things. I just had portfolio projects to write about. What I actually needed was a CMS service that can give me a proper editing experience and isolate this architecture with one user group only. Nothing complex, just something with a nice content editor like Sanity.

---

What Was Actually Broken

The pain points accumulated slowly, which is why they're easy to rationalize away:

• Editing content meant touching JSON. There was no editorial interface. Just me, a terminal, and a MongoDB shell.
• SEO was bolted on, not baked in. Site metadata required extra configuration that I never fully got right.
• Performance was acceptable but not optimized. No SSR, no image optimzation, no smart caching headers, no edge delivery.
• The backend did almost nothing except proxy content from a database. It was infrastructure for its own sake to show I know how to build.

---

The Architecture, Honestly

What I Had

What I'm Moving To

The reduction in complexity is not cosmetic. It reflects a genuine reduction in operational surface area.

---

Why Next.js and Sanity

Next.js

Migrating from React to Next.js is not a rewrite — it's important to say that clearly. Next.js is React. Your components, hooks, and mental models transfer directly. What you gain is a framework layer that handles things React intentionally leaves out:

• File-based routing that replaces whatever custom router setup you had
• Server-side rendering and static generation as first-class options, not afterthoughts
• Image optimization via next/image — automatic format conversion, lazy loading, responsive sizing
• API routes if you still need lightweight server logic without a separate backend
• Built-in support for Vercel's edge network, which means caching and CDN delivery without configuration

The incremental migration story is also real. You can start with the pages that matter most and move others over time. It's not a big-bang rewrite.

Sanity

The choice of CMS is always contextual. For a solo content creator with structured content (posts, projects, metadata), Sanity fits well for a few reasons:

• Structured content editing with a clean, customizable Studio UI
• GROQ — a query language that makes fetching exactly the data you need straightforward
• Portable Text for rich content that isn't locked to any presentation layer
• Separation of concerns: content lives in Sanity, presentation lives in Next.js. They don't know about each other. That's a feature.

The author experience goes from "edit JSON and redeploy" to "open Studio, write, publish." That's not a minor UX improvement — it's the difference between a tool I use and one I avoid.

---

What Modern Tooling Actually Gets You

Beyond the authoring experience, the delivery side improves meaningfully:

None of these are theoretical improvements. They're hours of maintenance I no longer spend, and page load times that reflect real engineering rather than good intentions.

---

When NOT to Migrate

This specific stack change makes sense for my context. It may not make sense for yours:

• If your site has real backend complexity — authenticated users, complex queries, transactional logic — a NestJS backend is actually the right tool. Don't swap it out because it seems heavy.
• If you're actively learning full-stack patterns, operating a production-grade backend is genuinely educational. Don't abstract it away prematurely.
• If your content model is highly dynamic or relational, a CMS may feel constraining compared to a flexible database schema.
• If your team is larger than one, the "just edit in Studio" workflow may not scale to collaborative editorial needs without more governance.

Context determines the right answer. This post is about my context, not a universal prescription.

---

The Real Lesson

The technical migration is the easy part. The harder thing was admitting that I had optimized for the wrong thing.

I built a system to demonstrate engineering capability, not to serve my users — even when my primary user was myself. Five years of friction while editing content, five years of over-engineered infrastructure for a site that publishes articles and lists projects.

The shift from engineering-first to product and content-first isn't a retreat from technical thinking. If anything, it requires more mature engineering judgment: the ability to look at a system and ask not just "does this work?" but "is this the right thing to build?"

A simpler, more purposeful system is not a compromise. It's the result of clearer thinking.

That's the version of myself I want the site to reflect now.

---

If you're considering a similar migration or have thoughts on the stack choices here, I'd genuinely like to hear from you.