I've been designing scoring rules for friend-group sports prediction pools (predict match results before kickoff, points awarded by accuracy). Sharing something I think gets under-discussed: the same scoring formula behaves very differently across sports.

Standard football formula:

• 1pt correct outcome (W/D/L)

• 2pt correct goal difference

• 3pt exact score

This works because in football:

• ~30-35% of matches end in the most-predicted outcome

• ~5% end on the most-picked exact score (1-1, 1-0)

The 1/2/3 ratio inversely matches the outcome probabilities. Players genuinely choose between safe and bold picks. EV rewards confidence.

Apply the same to NBA:

• ~65% of games end with the favorite winning

• "Exact score" is functionally impossible (100+ realistic final-score combos)

The 3pt tier dies. Nobody earns it, everyone bets chalk, leaderboard concentrates around favorite-pickers.

What I changed for basketball:

• 1pt correct winner

• 2pt winner + margin within 3 points

• 3pt winner + margin within 5 + correct total over/under

Margin-within-3 hits ~8-10% of NBA games. Adding totals adds a second independent prediction. Bold picking still pays — underdog by 4 and right beats favorite by 12.

The bigger principle: scoring design is matching reward distribution to the outcome distribution of the sport. Football tolerates "exact score." Basketball needs probabilistic-equivalents (margin tolerance + totals).

Where I'd love this sub's input:

1. **Tennis** — favorites win ~70-80% of matches but set counts and total games add granularity. Has anyone designed scoring around set-by-set outcomes vs just match winners?
2. **Hockey** — outcome distribution feels close to soccer, but OT and shootouts create a weird tail. Do you handle 3rd-period leads or OT outcomes as their own scoring tier?
3. **NFL** — ~62% favorites win, middle ground between NBA and soccer. Spread betting dominates the analytical frame. Has anyone built non-betting pools where ATS (against-the-spread) is a tier above outright winner?
4. Any academic or data-driven work on validating scoring-rule fairness across sports? I've been thinking through this empirically and there might be formal literature I'm missing.

Context: I'm building a sports prediction app for friend groups (beteamapp.com— explicitly not a betting product, just chips/points/leaderboards). The scoring rule design came up as a real engineering decision.

The Problem: Most AI gift assistants give great advice but terrible execution—links are often broken, out of stock, or don't ship to your location.

The Solution: I built PickifyAI. It uses a quick psychographic quiz to understand the "vibe" of the recipient, then leverages Claude 3.5 Sonnet (via Strict Structured Outputs) to map those needs to actual products from Amazon, Etsy, and AliExpress.

Key Features:

• Zero Hallucinations: Every product link is verified and in-stock.
• No Friction: No signups, no emails, no ads.
• Tech Stack: React 19, Node.js (for custom SEO pre-rendering), and Claude 3.5.

I’m a solo dev looking for feedback on the AI's reasoning. Does the "95% Match" feel accurate for the people you're shopping for?

Try it out:https://pickifyai.com

I needed real SEO from a React 19 SPA without rewriting in Next.js or Remix. Solved it with a Node.js post-build script that generates static HTML for blog posts, hub pages, and other content-heavy routes — while leaving the interactive parts (a 7-step quiz) as standard CSR.

THE PROBLEM

I have a React SPA (Vite-style build, deployed on Vercel) with two very different page types:

1. Interactive UI — a multi-step quiz that takes user input, makes API calls, and streams AI responses. Standard React CSR makes sense here.
2. Content pages — ~50 blog posts and ~17 hub/landing pages. These need to rank in Google and be readable by non-JS crawlers (LLM crawlers and SEO scanners often struggle with pure CSR).

The standard advice is "migrate to Next.js for SSR/SSG." But for a one-person team, that's a massive rewrite for what is essentially just 50-60 routes that need HTML on first paint.

WHAT I DID INSTEAD

A post-build Node.js script that:

1. Reads the built index.html (the SPA shell).
2. For each content route, generates body HTML server-side from my data files.
3. Injects the generated body into the SPA shell at the <div id="root"></div> mount point.
4. Updates <title>, meta tags, canonical URLs, and JSON-LD schema per route.
5. Writes the file to build/route-path/index.html.

ARCHITECTURE

Bash

# My build command:
npm run build:
  1. react-scripts build        → standard SPA bundle in /build
  2. node scripts/prerender.js  → generates static HTML per route
  3. node scripts/sitemap.js    → generates sitemap.xml

THE PRERENDER SCRIPT (Simplified)

JavaScript

const fs = require('fs');
const path = require('path');

const template = fs.readFileSync(
  path.join(__dirname, '..', 'build', 'index.html'), 'utf-8'
);

function renderBlogPost(template, post) {
  let html = template;
  html = html.replace(/<title>[^<]*<\/title>/, 
    `<title>${post.title} | MySite</title>`);
  html = html.replace(/name="description" content="[^"]*"/, 
    `name="description" content="${post.metaDescription}"`);
  html = html.replace('<div id="root"></div>', 
    `<div id="root">${generatePostBody(post)}</div>`);
  return html;
}

WHAT WORKED

• SEO Results: Google indexing improved substantially. Pages moved from "Crawled - not indexed" to indexed within ~2 weeks.
• Performance: Faster first paint for content pages.
• Low Friction: Hits 80% of the SEO benefit at 5% of the migration cost.

WHAT DIDN'T

• Hydration Mismatches: React will scream in dev mode if the prerendered HTML doesn't match the React render exactly. I kept the prerendered body simpler than the React version to avoid complex conflicts.
• Dynamic Data: Doesn't work for user-specific content, which stays as standard CSR.

CASE STUDY

I run a free AI gift finder: pickifyai.com(built with React 19 + Claude 3.5 Sonnet). The content pages use this approach, while the quiz flow is standard CSR. You can actually see the prerendered HTML if you View Source on any of the blog pages.

OPEN QUESTIONS

1. Anyone else doing post-build prerender from a CSR app? What edge cases bit you?
2. How do you handle the React Helmet Async vs prerendered <head> conflict?
3. Is there a more elegant way to handle hydration mismatches when the prerender body is intentionally a simpler subset of the React render?