Building This Website - From Template to Next.js
Building This Website - From Template to Next.js
This site didn't start as what you see now. It started as a template I found online, opened on a laptop during a 17-hour flight with nothing but time to kill.
That's the thing about personal projects—they don't happen all at once. They happen in small chunks, late nights, long flights, and random bursts of motivation.
Starting Point: A Template and a Long Flight
I grabbed a basic template and started customizing. Nothing fancy at first—just HTML, CSS, and TypeScript. The goal was simple: get a layout I actually liked.
Most of those initial hours were spent tweaking colors, moving sections around, and figuring out the structure I wanted. No frameworks, no build tools. Just files in an editor and a browser refresh.
By the time I landed, I had something that felt like mine instead of someone else's template.
The React Phase
Once the layout was solid, I got ambitious. I wanted:
- A dynamic animated background
- Smooth transitions between sections
- Things that felt alive instead of static
This is when I brought in React. And then Framer Motion for animations. Each feature started as "I wonder if I can do this" and turned into hours of documentation and Stack Overflow.
The animations were harder than I expected. Getting elements to animate on scroll, timing things correctly, making it feel smooth instead of janky—that took a lot of trial and error.
Adding Next.js
At some point I thought "can I really turn this into a Next.js app?" So I did.
Next.js gave me:
- Better routing
- The ability to add this blog with MDX
- Server-side rendering
- A cleaner project structure
Was it necessary? Probably not for a personal site. But I learned a ton doing it, and that was the whole point.
The Hard Parts
Animations
Framer Motion is powerful but has a learning curve. Getting animations to trigger at the right time, not conflict with each other, and actually look good took more effort than I anticipated.
My advice: start with simple fade-ins before trying anything complex. Get those working, then layer on more.
MDX Setup
Setting up the blog was its own adventure. MDX lets you write posts in Markdown (like this one), but getting it configured correctly with:
- Frontmatter parsing (gray-matter)
- Syntax highlighting for code blocks (highlight.js)
- Proper styling with Tailwind Typography
Each piece required figuring out how they all work together. The documentation assumes you already know things you don't know yet.
Dark Mode
Dark mode sounds simple until you try to implement it. I had colors scattered everywhere—inline styles, CSS files, Tailwind classes. Changing the theme meant hunting down every color definition.
The fix was centralizing everything. I created TypeScript files that define all the colors in one place. Components pull from there instead of having hardcoded values. When I want to change something, there's one source of truth.
This also made adding dark mode way easier. Instead of maintaining two separate color schemes across dozens of files, I maintain one config that switches based on the theme.
Simplifying the Contact Form
Originally I set up an SMTP server with Mailgun for the contact form. It worked, but it meant managing more infrastructure than I needed for a simple contact form.
I switched to Resend. It's an API call instead of a mail server. Way simpler, no backend to maintain, and it just works.
Sometimes the best solution is the one with fewer moving parts.
The Tech Stack Now
For anyone curious, here's what's running this site:
- Next.js with React and TypeScript
- Tailwind CSS for styling
- Framer Motion for animations
- MDX for blog posts (you're reading one now)
- next-themes for dark mode
- Resend for the contact form
What I'd Tell Someone Starting Out
Start with something that exists. Templates aren't cheating. They're a starting point. The learning happens when you start changing things.
Add features one at a time. Don't try to build everything at once. Get the layout working. Then add animations. Then add the blog. Each step teaches you something.
It's okay to refactor. This site has been rewritten in pieces multiple times. The first version of anything is never the final version.
Projects take time. This wasn't built in a weekend. It was built over weeks and months—an hour here, a few hours there. That 17-hour flight kickstarted it, but the work continued long after I landed.
Build something you'll actually use. I write on this blog. I update the portfolio. Having a reason to come back to the project keeps you improving it.
It's Never Really Done
I still find things I want to change. A component that could be cleaner. An animation that's not quite right. A new feature I want to add.
And that's fine. Personal projects aren't about reaching a finish line. They're about learning and building something that represents you.
If you've been thinking about building your own site—start. It doesn't have to be perfect. It doesn't have to use the latest framework. It just has to be yours.
You can iterate from there.