Why the product surfaces are server-first
LeadScrapper's audit UI and Itiner's client portal both render on the server by default, here's why that held up under real use.
Two products, one default
LeadScrapper Pro's audit results and Itiner's client-facing trip portals look like very different products, but both start from the same default: render on the server, ship a client component only where interaction actually requires one.
A client viewing a shared itinerary link, or a prospect being sent an audit-backed pitch, never has an account and never needs one. Server-first rendering means that page is correct and fast on the first response, with no loading state for content that doesn't change per visitor.
Where the client boundary actually sits
The line is drawn at genuine interaction: editing a draft itinerary, filtering audit results, adjusting a search. Everything upstream of that (the data fetch, the initial layout, the SEO-relevant content) stays server-rendered.
This isn't a rule enforced for its own sake. It's the same default Next.js's App Router nudges toward, and it happens to match what both products actually need: a fast, correct read path for the person who didn't build the software.