We all have that ~/Projects folder, don’t we? Full of half-finished ideas and create-react-app clones. This year, I decided to actually ship.

As a developer, my “superpower” isn’t just coding; it’s spotting inefficiencies. And as a sports fan, I saw a huge one: most sports media is too broad. It’s all “breaking news.” But the real, high-intent searches are hyper-specific.

Users aren’t just searching “fantasy football.” They’re searching “is my fantasy trade fair?” or “funny fantasy football names.”

They aren’t just searching “college football.” They’re searching “who is the backup QB for Penn State?”

This is the “long-tail” SEO goldmine. So, I built a portfolio of micro-sites to target these niches. Here’s how.

The Philosophy: Don’t Build an App, Build a Resource My goal wasn’t to build a complex SaaS. It was to build fast, high-value, low-maintenance content and tool sites.

For Content: The answer is static. Fast, secure, cheap.

For Tools: The answer is serverless. Lightweight, scalable, cheap.

The Stack: Keep It Simple, Stupid (KISS) I didn’t over-engineer this. The goal was speed to market.

Frontend: Mostly Next.js and Astro. Astro is incredible for pure content sites—zero client-side JS by default. For anything with interactivity, Next.js is my go-to.

Backend/Data: This is where it gets fun. For some sites, it’s just a local data.json file I update manually. For others, it’s a headless CMS (Sanity.io or Strapi).

Hosting: Vercel and Cloudflare Pages. git push and it’s live. It’s a solved problem. Don’t waste time on complex deployments for this kind of project.

Project Type 1: The “Tool” Site The most complex builds are the “tool” sites. They need to do something.

My most popular one is a fantasy football trade analyzer. It’s a simple React front-end that pulls player projections (from a 3rd party API, cached in a serverless function) and runs them through a basic algorithm to score the trade. It’s not complex AI, but it’s 10x better than a “gut feeling,” which is what most players use. It solves one problem, and it solves it well.

Project Type 2: The “Living Data” Site These are the most challenging from a content perspective. This is data that is current, but not “breaking news.”

Think about a Penn State football depth chart. It changes after spring practice, during fall camp, and with any injury. This can’t be a simple static file (unless I want to redeploy constantly).

The solution: I built a simple Next.js site that uses ISR (Incremental Static Regeneration). It fetches data from a headless CMS, which I (or a VA) can update from a simple web interface. The page re-validates, and the content is updated without a full redeploy.

Project Type 3: The “Evergreen” Site These are my favorites. The “set it and forget it” projects.

I’m a huge golf fan. The Ryder Cup and Presidents Cup are massive events, but the core data (all-time player records, past results) is historical. It rarely changes.

For this, I built a site for Ryder Cup players using Astro. It’s 99% static HTML/CSS. It’s incredibly fast, ranks well on Google, and I only have to spend a few hours on it every two years to add the new results. It’s the perfect low-effort, high-value asset.

What I Learned Niche Down: Don’t build “ESPN.” Build the one page on ESPN that everyone is trying to find.

Ship It: A “good enough” site that is live is infinitely better than a “perfect” one in your ~/Projects folder.

Devs Have an SEO Advantage: We understand site speed, data structures, and schema.org better than most marketers. Use that.

I’m still building. The college football rivalries are next (www.theredriverrivalry.com, www.ironbowlhistory.com). The model works.

What are you building? What’s your go-to stack for “side hustle” projects like this?