The old quickstart frontend focused on direct backend flow verification. That remains important, but many real SaaS projects also need a public-facing docs layer for setup, onboarding, and technical explanation. The shell now supports that use case directly.
Documentation
A docs-ready page template with breadcrumbs and article navigation.
A reusable SaaS frontend template usually needs documentation just as much as it needs login and billing. This page shows how the shell can host product docs, onboarding guides, or integration notes without becoming a separate site.
Environment
http://localhost:3000Docs shell
Layout modeArticle + TOC
BreadcrumbsEnabled by shell
Language switchTop navigation
Overview
This docs page is meant to be copied and replaced with product documentation, not kept as-is.
Routing model
Separate public and authenticated responsibilities without splitting the app shell.
Recommended route split: public routes such as `/`, `/pricing`, `/docs`, and `/login`; authenticated routes such as `/account`, `/billing`, and `/referrals`. The top shell stays consistent so the user does not feel thrown between unrelated interfaces.
Account surfaces
The avatar menu is the entry point into settings, billing, and referral management.
Instead of a plain “signed in” pill, the template now treats the authenticated surface as a product area. The avatar menu should be the stable user entry point for settings, sign-out, subscription visibility, and referral visibility. Product teams can extend this with workspace switching, security settings, or profile preferences.
Integration notes
Keep backend contracts stable and frontend routes expressive.
The frontend remains a consumer of the shared backend contract. That means JSON envelope parsing, auth session management, Stripe Checkout session creation, and referral read APIs should remain consistent. The shell and design can evolve, but the integration contract should stay boring and predictable.