We're developers. We love to build. But how many of your side projects are collecting dust in a private GitHub repo? My ~/Projects folder was a graveyard until I stopped trying to build "the next big thing" and started solving small, specific problems.
As a sports fan, I was constantly frustrated by mainstream media sites. They're slow, bloated with ads, and terrible at answering specific, high-intent questions.
I didn't want "Big Ten News." I wanted the Penn State depth chart, right now. I didn't want a 2,000-word opinion piece. I wanted a fantasy football trade analyzer that could tell me if I was getting fleeced.
This is the "long-tail" of SEO. And as developers, we are uniquely equipped to dominate it. Here's the stack and strategy I used to build and deploy 8 (and counting) of these niche sites.
The Stack: JAMstack or Bust
The goal is speed. Both development speed and site speed. Over-engineering is the enemy.
Frontend: Astro.js for content, Next.js for tools.
Backend: Headless CMS (Sanity.io) for "living" data, Vercel/Netlify Serverless Functions for "tool" logic.
Hosting: Vercel. git push, and it's live.
Case Study 1: The "Evergreen" Content Site (ironbowlhistory.com)
The Problem: Rivalry history is static. It's a perfect "set it and forget it" project.
The Solution: Astro.js.
Why? Astro ships zero client-side JavaScript by default. For a site that is 99% text and images, this is a Google Lighthouse score killer (in a good way). I wrote the content in Markdown files, built the site, deployed it, and now I only touch it once a year to add the latest game score. The Iron Bowl history is fascinating, and the site is blazing fast because it's just static HTML.
Case Study 2: The "Living Data" Site (pennstatedepthchart.com)
The Problem: A depth chart changes constantly. Injuries, position battles, etc. I can't be redeploying a static site every day.
The Solution: Next.js with ISR + a Headless CMS.
Why? I created a simple data model in Sanity (e.g., Position, Player 1, Player 2). I (or a non-technical helper) can update the chart from a web UI. The Next.js frontend uses Incremental Static Regeneration (revalidate: 3600) to fetch the new data from the CMS every hour. This gives me the performance of a static site with the flexibility of a dynamic one. Managing the Penn State depth chart is now a content problem, not a code problem.
Case Study 3: The "Tool" Site (fftradeanalyzer.com)
The Problem: This needs logic. It needs to take user input (Player A, Player B) and return a result.
The Solution: A Next.js API Route (Serverless Function).
Why? The frontend is a simple React form. When the user hits "Analyze," it POSTs to /api/analyze. This serverless function:
Takes the player names.
Fetches the latest "Rest of Season" projections from a 3rd-party API (I use FantasyData.io).
Caches those projections in Vercel's KV storage (so I'm not hitting the API on every request).
Runs a simple algorithm (Player A's value vs. Player B's value).
Returns a JSON response to the client.
This fantasy football trade analyzer is my most complex build, but by keeping the logic serverless, it's still incredibly cheap and scalable.
Stop building monoliths. Find a niche, build a fast solution, and ship it.
Top comments (0)