As developers, we love to over-engineer. We'll use Kubernetes to host a personal blog. We'll build a microservice architecture for a "to-do" app. I get it, it's fun.
But when your goal is to actually ship and build a portfolio of profitable side hustles, "fun" isn't the priority. Speed and efficiency are.
My "side hustle" is a portfolio of 8+ niche sports sites. They all look similar, but the technical stack under the hood is completely different for each, based on one simple question: How often does the data change?
Here's a breakdown of the three "data-change" categories and the stack I use for each.
- "Never-Change" Data: The Pure Static Site This is "set it and forget it" content. Think "history," "all-time records," or "biographies."
Example: My Iron Bowl history site.
The Problem: The 1982 game result is not going to change. This data is permanent.
The Stack: Astro.js + Markdown.
Why? This is the purest form of the JAMstack. I write content in .md files, Astro builds it into pure HTML/CSS, and I deploy it to Vercel. It ships zero client-side JS by default. The Lighthouse speed score is a perfect 100, it costs $0 to host, and it's unhackable. I touch it once a year to add the new game score.
- "Sometimes-Change" Data: The SSG/ISR Site This is the most common category. The data is current, but not "real-time." Think "rosters," "schedules," or "player lists."
Example: My Presidents Cup players site.
The Problem: The all-time records are static, but the current team changes every two years. I don't want to dig into code to update it.
The Stack: Next.js (or Astro) + a Headless CMS (Sanity.io).
Why? I give a (non-technical) virtual assistant access to the Sanity CMS. They can update the player list, add new photos, etc. The Next.js site uses ISR (revalidate: 3600) to rebuild the static pages every hour, pulling in the fresh data. I get the speed and SEO of a static site, but with the power of a CMS.
- "Instantly-Change" Data: The Dynamic Tool This is any site that requires user input to produce a unique result.
Example: My fantasy football trade analyzer.
The Problem: I can't "pre-build" the answer. A user needs to enter Player A and Player B, and I need to fetch live data, run an algorithm, and return a result right now.
The Stack: Next.js (as a React framework) + Serverless API Routes.
Why? The frontend is a simple React form. On submit, it calls my own /api/trade endpoint. That API route (a serverless function) does the heavy lifting: it fetches the latest player projections from a 3rd-party API, caches them, runs my trade logic, and sends back a JSON response.
Stop building monoliths. Stop using a one-size-fits-all solution. Match your stack to your data, and you'll ship faster and more efficiently.
Top comments (0)