TechEarl

The Joke Domain That Outlived Gatsby

Five years ago I bought a domain about a coworker's Dr Pepper habit. Here is what building it in Gatsby, then rebuilding it on Next.js 16, taught me about side projects that outlive their framework.

Ishan Karunaratne⏱️ 8 min readUpdated
Share thisCopied
A five-year-old Dr Pepper fan site built on Gatsby, why Gatsby stopped being a safe bet, and how I rebuilt it on Next.js 16 without losing the parts that worked.

Every team has the person with the thing. Mine had Dr Pepper. They would show up to standup with a can, mention the can, and somewhere between yesterday's blockers and today's plan they would tell us how many they were on for the week. It became a running bit, the kind that gets funnier the longer nobody lets it go.

So I bought the domain. drpepperaddiction.com was available, it cost less than a lunch, and at the time it was purely a gag I could drop in the team channel. What I did not plan on was committing to it. I built an actual site, wrote actual pages, and five years later it is still online. This is the story of that build, why the framework under it quietly stopped being a safe bet, and what I did about it.

Building it in Gatsby, and why the images sold me

In 2021 I reached for Gatsby. React-based, static output, a big plugin ecosystem, and a content layer that let me write pages in Markdown and query them with GraphQL. For a small content site it felt like the right amount of structure.

The part that genuinely sold me was the image pipeline. gatsby-plugin-image plus sharp did, at build time, all the work I would otherwise have hand-rolled: responsive srcset variants, modern formats, and a blur-up placeholder so a can of Dr Pepper faded in instead of popping. I dropped a source image in, referenced it, and got a fast, properly-sized picture on every screen.

What I did not expect was the scores. This is a site whose whole job is showing soda, so most pages are image-heavy, which is usually exactly what tanks a performance audit. Instead they came back at essentially 100 on PageSpeed for both mobile and desktop. The build-time image handling was doing precisely its job, and on an image-first site that was the feature that mattered most.

I wrote a handful of pages, leaned hard into the maroon-and-crimson palette, and shipped it. Then, because the site was just going to sit there accruing a hosting bill, I added some Amazon affiliate links. A case of Dr Pepper is a real thing people buy. Might as well let the joke pay for itself.

Then it just ran

It ran for about five years. I registered the domain in mid-2021 and, rounding up, it has been live ever since with almost no attention from me.

The affiliate experiment was a clean, honest failure. As far as I can tell I never got a single meaningful click, let alone a sale. That is not a Gatsby problem or an affiliate-program problem, it is a "nobody knew the site existed" problem. I had built a small, fine site and done nothing to bring anyone to it. The lesson there is old and keeps being true: shipping is the easy 20 percent.

But the site stayed up, the bill stayed small, and every so often I would remember it existed and smile. That alone was worth the price of the domain.

Gatsby quietly died under it

Here is the part that pulled me back. Gatsby is no longer a framework I would start a new project on.

Netlify acquired Gatsby in early 2023, and after the acquisition active development wound down. The releases slowed and then mostly stopped, the open issues piled up, and the community moved on. Nothing dramatic happened, there was no shutdown notice. It just went quiet, which for a build tool is its own kind of warning. Try to stand an old Gatsby site back up on a current Node version and you feel it immediately: dependency resolution fights you, native modules need rebuilding, and plugins that were fine in 2021 throw on install.

A static marketing-ish site does not strictly need maintenance. But a build toolchain that fights you every time you touch it is a liability, and "I cannot easily change my own site" is a bad place to be even for a joke. So I decided to rebuild.

Rebuilding on Next.js 16

I moved it to Next.js 16 with the App Router, which is the same stack I run this blog on, so I knew the terrain. The rebuild was less a migration than a re-pour: same content, same identity, new foundation.

The content came across as MDX through next-mdx-remote, which kept the writing in plain files instead of a database. The image handling I cared about did not need rebuilding: Next.js optimizes images natively, so the fast, properly-sized pictures that made the Gatsby version score so well came along without the Gatsby plugin in the middle.

What I gained was control. Server-rendered where it helps, statically generated where it does not, no GraphQL layer between me and my own Markdown, and a dependency tree that installs cleanly on a current Node. If you are weighing the same move, my Gatsby-versus-Next mental model is simple: Gatsby optimized for a plugin-and-GraphQL world that has largely passed, and Next optimized for owning your rendering. For a content site in 2026, owning your rendering wins.

What the joke turned into

Somewhere in five years of poking at it, the site stopped being only a gag and became a genuinely fun little corner of the internet about Dr Pepper. The piece I am most fond of is the explainer on the mysterious 23 flavors of Dr Pepper, which lays out the famous fan-speculated list, what the can actually lists, and why the real recipe has never left the company vault. It is the rare page that is both a trivia rabbit hole and an honest answer to a question people genuinely search.

From there it grew the kind of pages a fan site grows. There is a set of Dr Pepper recipes for the people who cook and bake with it, a merch page for the truly devoted, and, in the spirit of the standup bit that started all of this, an am I addicted to Dr Pepper quiz that does not take itself seriously. The whole site leans all the way into the bit, which is the only way a thing like this is worth doing.

What I would tell you about side projects that outlive their stack

A few things this taught me, in the order they mattered.

  1. Commit to the bit. The difference between a domain you forget to renew and a project you are still happy about five years later is whether you actually build the thing. The commitment is the fun.
  2. Pick a stack you can still run later. Frameworks have lifecycles. Gatsby was a reasonable bet in 2021 and a bad one to keep in 2026, and there was no way to know that on day one. What you can do is make sure future-you can rebuild without a fight.
  3. Keep your content portable. The writing lived in Markdown, not a database or a proprietary format, so the move was a copy rather than a rescue. Content can only outlast a framework if it was never welded to one.
  4. A side project does not have to win to be worth it. Mine has earned nothing and amused me for years. That is a perfectly good return.

The domain is still pointed at a live site, it builds in seconds, and I can change it whenever I want again. It outlived the framework I first built it on, which feels like exactly the right ending for a joke I refused to let go of.

TagsGatsbyNext.jsSide ProjectsJavaScriptStatic SitesMDX

Found this useful? Pass it on.

Copied

Ishan Karunaratne

Software Systems Architect · Senior Software Engineer · Engineering Leadership

Software systems architect and senior software engineer with more than two decades designing, building, and running production software, Linux systems, and DevOps infrastructure, and lately working AI into the stack. Now a CTO, though what I write here is drawn from the full arc of that work, across architecture, engineering, and operations, not any single job.

Keep reading

Related posts

ffmpeg cheat sheet: -c copy stream copy, -ss/-to/-t trim, scale and crop filters, -vn audio extract, palettegen/paletteuse for high-quality GIFs, libx264/libx265/libsvtav1 with -crf and -preset, setpts and atempo speed, concat demuxer, subtitles, and common-error fixes.

The ffmpeg Command Cheat Sheet

A scannable ffmpeg reference: convert containers, stream-copy without re-encoding, trim and cut, resize and crop, extract or replace audio, high-quality GIFs with palettegen, x264/x265/AV1 quality with -crf and -preset, change speed, concat, subtitles, and the fixes for the errors you actually hit.