Field notes

Most RAG tutorials end at “embed your docs, store in a vector DB, cosine-similarity search.” That's the easy 80%. The remaining 20% is where every prod system I've seen gets bitten:

1. Chunk overlap eats your retrieval quality. Naive splitting on token count produces chunks that cut mid-sentence. The model retrieves chunk N+1 but loses the context from chunk N. Use a recursive splitter with ~15% overlap — the duplicate tokens are worth it.

2. Cosine similarity doesn't mean “relevant.” A query about “refund policy” will pull every chunk with the word “refund” ahead of an actual relevant policy summary. Re-ranking with a cross-encoder (or just an LLM call) fixes 90% of relevance issues with retrieval.

3. Most failures are query-side, not corpus-side. Spend a day on query expansion / HyDE before adding more docs.

The Next.js docs make SSR feel like the default for everything. After three projects, my heuristic is the opposite — start static, opt into SSR only when you have specific evidence you need it.

Static handles 80% of cases. Marketing pages, dashboards with client-fetched data, dashboards behind auth — none of them need SSR. They need a fast first paint, which static prerender + client hydration does better than SSR.

SSR earns its complexity when:SEO depends on data that changes per request (search pages, location-targeted content), or authenticated content needs to render server-side (paid content gates). That's a real list — short, specific.

The wins from default-SSR are smaller than they look on the docs page. The costs (slower builds, more failure modes, cache complexity) are real.