Introduction

Honestly, my personal site took me over a year to nail down. I obsessed over many key decisions like design look/feel, font, colors, and layout. I overthought a lot of decisions but my obsession paid off. I produced a personal site that I feel like I can improve and maintain with content over time instead of having a static website that no one visited or cared for. I started building the site early last year (2025). I was hardly using AI tools and was just scratching the surface of knowledge of using Next.js and Sanity. Over the course of a year and a few new AI models along the way (thank you, Claude Opus), I finally got the site live, and I’m proud of what I ended up with.

The final product itself

So, let’s talk about the outcomes first, and then we can dive into the nitty gritty. This site achieved some pretty high Google Lighthouse scores (and honestly I didn’t even try), this is a byproduct of the stack I chose. Next.js (App Router) handles static generation for the site itself, so pages ship fast without a server round-trip on every request. Sanity runs as a headless CMS behind it, content gets queried via GROQ and pulled in at build/request time, so nothing bloats the client bundle just to render a blog post. Tailwind keeps styling utility-first and tree-shaken down to only what's actually used, and Framer Motion handles animation without dragging in a heavier library. I have seriously come to love this tech stack and it may be hard to pry me away from it lol.

The site is hosted on Vercel and that has been one of the easiest workflows of the project, being able to push up to the main branch of my project, and know that the deployment is already running and being tested I don’t even have to think about it.

These tech stack decisions allow me to focus on my overall goal for myself, that is to be consistent with my content this year, and produce blogs that I care about. I can publish content on the go with Sanity Studio and not have to worry about redeploying the site after changes are made (I can seriously publish content on my phone if I wanted to).

Resend makes it incredibly easy to manage contact submissions as well as route them where they need to go. I have a function to allow users to request my resume/work on submission of my contact form and it gets sent directly to them in an email from me automatically. My resume is hosted within my Sanity Studio via a site-settings singleton and can easily be updated if I need to (literally seamless) without any redeploy. This allows me to talk with new people and get my experience across to them quickly, without having to wait for me to send my information over. This is just one of many thought-out decisions I made for this website and why it works so well for me.

Another key decision was incorporating Cloudflare Turnstile, I chose this to allow for quick contact form submissions, allowing for an invisible challenge to prevent any spam submissions from coming through, without adding friction for real users submitting the form. This allows me to focus on valuable submissions from actual important conversations instead of filtering through the bots.

All of that said, the tech stack is really only half the story. The other half is everything I picked up along the way, some of it the hard way.

Lessons learned

Looking back at a year-long build, the biggest thing I learned wasn't a framework quirk or a config setting, it was figuring out where "good enough" actually lives.

I spent a long time obsessing over design, fonts, colors, layout, the kind of decisions that have no objectively correct answer and can eat as much time as you let them. Personal projects don't have a client deadline forcing your hand, which sounds like freedom but is actually the trap. There's no external pressure telling you to stop iterating and ship. At some point I had to just decide the site was done enough to go live, and that decision was harder than any of the actual development work.

The other thing I kept choosing, almost without noticing it, was to do things the harder way on purpose. I built my own SEO fields by hand instead of reaching for the sanity-plugin-seofields plugin. I self-hosted Umami analytics before eventually moving to Vercel Analytics for simplicity. Neither of those was the fastest path, and I knew that going in. But I wasn't optimizing for speed, I was optimizing for actually understanding what I was shipping. That tradeoff shows up everywhere in this project: a little slower to build, a lot more mine at the end of it. It may not be the flashiest site but I truly learned a lot.

Anyway, enough with the feelings, let's look at some actual numbers.

(Google Lighthouse Metrics scores for developedbychels.com)

The Lighthouse Metrics

Like I said, I wanted this website to be high-performing and well thought-out. The stack I chose allowed me to achieve this, it wasn’t really thought about, it was just a given. The scores: 100 Performance, 100 SEO, 95 Accessibility, 100 Best Practices, as well as a 3/3 for Agentic Browsing. I come from a marketing background, so not only did I want to show my development chops, I wanted the site optimized not just for traditional SEO, but for AEO too, since that's where I think search is heading anyway. I wanted to make sure I was ahead of the curve before launch.

Next.js easily allows for managing SEO page meta information and dynamic page meta information. Sanity allows for all of this to be pulled into the Studio and managed on a per post basis. This is exactly what I wanted and is very similar to the setup I use on a day-to-day basis for WordPress clients through my agency work, it was a no-brainer to replicate with the modern stack I chose for this site. I was also able to setup a dynamic llms.txt that pulls live from Sanity that updates based on any content changes to the site. This allows my llms.txt to be managed without even thinking about it.

(The Sanity Studio dashboard for developedbychels.com)

My Sanity Studio Setup

A brief breakdown of my studio setup and how this makes my life so much easier managing this site.

• I’m able to publish blog posts via the “Posts” tab.
• I can manage site settings (like my resume) from this tab.
• I can manage how blogs are categorized via the “Categories” tab.
• I am only one author on this site, but from the “Authors” tab I can manage my profile picture and author bio on this tab that gets pulled through on every post.
• Experiences is a custom schema type I added: this allows me to add new dropdowns via the homepage to share my work experience.
• Case Studies: I plan to expand this once I’m able to release some of my WiP (work-in-progress) projects, but for now this creates new sections on the homepage that allow me to share the title of what I’m working on, the GitHub repo, and a potential live link to the project.

This lets me manage even the frontend/visual pieces (Case Studies, Experiences) without redeploying or touching static content.

What’s next

With the site live, my focus shifts to the next build: sanity-markdown-porter. It's a tool I'm working on to convert Markdown content directly into Sanity's Portable Text format, something that's surprisingly clunky to do by hand right now if you're migrating content or writing posts outside of Sanity Studio itself. I've run into this friction enough times with my own workflow that it felt worth solving properly instead of working around it every time.

The plan is to open-source it once it's in a usable state, mostly because I'd have wanted this exact tool when I was piecing my own content pipeline together. It's early, but it's the next thing I'm excited to sink time into now that the site itself is out the door.