Building and Re‑building My Personal Site: What I Learned Along the Way

How I Accidentally Broke My Personal Website

(And How Rebuilding It Taught Me Everything I Didn’t Know I Needed)

When I started building my personal website, my goal was simple: create a digital home for my work, my projects and—eventually—my ideas. Like most side projects, it began as a static portfolio. Hard-coded pages. HTML sprinkled with React components.

It worked, but every update required touching code. Adding a new work sample meant opening a file. Updating the footer meant redeploying.

It didn’t feel like a site I could live with. I wanted something more dynamic—a proper CMS I could control from a browser.

That’s when I fell in love with the idea of using Next.js App Router, Prisma, and Supabase. Modern React rendering, strongly typed models, a real database and email/password authentication.

Within a weekend, I had a functional admin dashboard where I could add experiences, tools and apps without opening VS Code. It felt like magic.

Going Dynamic (Fast)

Prisma made modeling my content simple. I created models for:

• Post
• Experience
• WorkSample
• WebApp
• Tool
• SiteSettings

Supabase handled authentication with email/password, and Next.js server components made it easy to build protected routes.

In just a few days, I had:

• a blog system
• a CMS-style admin panel
• an experience manager
• a tools and apps section
• a footer that loaded from the database

At its best, the site felt like a real product.

When Everything Seemed Fine… Until It Wasn’t

Then suddenly… everything broke.

• Pages that used to load were empty.
• The blog admin threw red Prisma errors.
• The dashboard said: “Database connection is not configured.” even though I did have DATABASE_URL.
• The homepage crashed with: “Cannot read properties of undefined (reading ‘slice’)”
• My dark-themed apps page looked nothing like the rest of the site.
• The header links sent visitors to wrong routes.
• The footer disappeared entirely.

For a while, it felt like I was putting out fires without knowing where the smoke came from.

The First Problems I Found

After digging deeper, I found two early culprits:

1. Incorrect or missing environment variables

Prisma silently refuses to initialize if DATABASE_URL is missing or wrong. I had updated my Supabase password (good habit), but forgot to update Netlify’s env variables. So the admin panel couldn’t connect, reported “database not configured,” and refused to load Experiences, Posts or Audit logs.

Updating the connection string across all environments immediately fixed this part.

2. Migrations that were never applied

Even when authentication worked, my tables didn’t. I never applied migrations to the production database, so Prisma kept yelling: “Unable to load posts. Verify your DATABASE_URL and run pnpm prisma migrate deploy.”

Running the migrations finally created missing tables—and the admin panel came back to life.

But this was only the surface of the real problem.

The Deep Problem: A Database Split in Two Worlds

Things got really interesting the day I cloned my project using Lovable.dev, a tool that can auto-generate and refactor entire projects. To my surprise: The Lovable version worked flawlessly. My original version… didn’t. Both were connected to the same Supabase database, but one worked and the other didn’t.

That’s when the truth hit me: My project had a Frankenstein database setup. Over time, I had:

• switched from SQLite → Postgres
• changed connection strings
• merged old code with new code
• accumulated migrations that didn’t belong together

Some Prisma migration files still contained SQLite SQL, like:

INTEGER PRIMARY KEY AUTOINCREMENT
DATETIME DEFAULT CURRENT_TIMESTAMP

Prisma tried to apply these to PostgreSQL, which obviously failed. This explained the endless stream of errors.

The Real Fix: A Full Reset and Rebuild

In the end, the only real solution was the one I kept trying to avoid: Reset the entire database and start clean. Here’s what I actually did:

1. Dropped all content tables in Supabase
2. Deleted every old Prisma migration, keeping only migration_lock.toml
3. Removed the _prisma_migrations table in Supabase
4. Let Prisma rebuild everything with: npx prisma migrate dev --name init
5. Regenerated Prisma Client
6. Reconnected the admin panel
7. Tested data flow from admin → Supabase → frontend

This time everything aligned perfectly. The migrations were correct. The schema matched the database. Supabase authentication worked. The admin dashboard finally loaded without a single warning.

For the first time in weeks, every page worked—and I didn’t get a single red error on reload.

Fixing UI Breakage Along the Way

Some of the UI problems were unrelated to the database:

• My dashboard’s top bar broke because a client component was wrapped by a server component.
• Work Samples crashed the homepage because I called .slice() on undefined.
• The site header, footer and your Tools/Apps pages were visually inconsistent.
• Navigation links pointed to routes that no longer existed.

As I rebuilt the backend, I also cleaned up the UI:

• Restored interactivity by keeping client components where they belong
• Added null checks (title?.slice(0,160))
• Rebuilt the Tools and Apps pages with the main layout
• Added a fallback footer that always renders even if the DB is empty
• Updated navigation links to the canonical routes

The site finally felt unified again.

What I Learned From Rebuilding Everything

Looking back, I learned more from breaking my site than from building it:

1. A dynamic site is only as stable as its environment variables. One wrong DATABASE_URL brought down the entire admin panel.
2. Migrations are not suggestions — apply them religiously. If your schema has a model, it doesn’t exist until the migration runs.
3. Mixing SQLite and Postgres migrations is a recipe for chaos. A single AUTOINCREMENT can break an entire production deploy.
4. Client components silently die when wrapped incorrectly. Hydration issues are real.
5. Consistency beats cleverness. A unified layout is better than a collection of beautiful but disconnected pages.
6. Resetting and starting clean is sometimes the fastest path forward. It’s painful. It’s scary. But sometimes, it’s necessary.

The Best Part: The Site Is Now Better Than Ever

What started as:

• a static portfolio
• became a dynamic CMS
• then broke
• then evolved into a cleaner, more maintainable platform with solid foundations

There were frustrating moments, but also incredibly rewarding ones—those “aha!” moments when everything works again after hours (or days) of debugging.

If you’re building your own site:

• Expect it to break.
• Expect to chase problems you never imagined.
• Expect to reset things at least once.
• And expect to learn a lot more than you planned.

Because that’s the real value of a personal project: not just what it becomes, but what it teaches you along the way.