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:

Interactive UI — a multi-step quiz that takes user input, makes API calls, and streams AI responses. Standard React CSR makes sense here.
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:

Reads the built index.html (the SPA shell).
For each content route, generates body HTML server-side from my data files.
Injects the generated body into the SPA shell at the <div id="root"></div> mount point.
Updates <title>, meta tags, canonical URLs, and JSON-LD schema per route.
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(/&lt;title&gt;[^&lt;]*&lt;\/title&gt;/, 
    `&lt;title&gt;${post.title} | MySite&lt;/title&gt;`);
  html = html.replace(/name="description" content="[^"]*"/, 
    `name="description" content="${post.metaDescription}"`);
  html = html.replace('&lt;div id="root"&gt;&lt;/div&gt;', 
    `&lt;div id="root"&gt;${generatePostBody(post)}&lt;/div&gt;`);
  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

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

u/Deep-Fly-5831