When you log in to your app, the URL changes. The marketing site lives at /, and the logged-in product lives somewhere else. That "somewhere else" is the app route — and in your starter, it's /app.
You might expect every product to use /app, but most don't. They've each found their own pattern:
your-workspace.slack.com, Stripe uses dashboard.stripe.com, Spotify uses open.spotify.com. The logged-in product is a whole separate domain.linear.app/your-team, github.com/your-name. The URL is the context./files, Todoist to /app/today, Discord to /channels. The path describes what you're looking at./. The product is the site.So why does your starter use /app?
Those patterns above all require decisions your project hasn't made yet. Subdomains need DNS setup and CORS configuration. Dynamic slugs like /:team need teams or workspaces as a core concept from day one. Content-type paths like /files assume you know your product's primary view.
/app is a static prefix. It works the moment you add it. No infrastructure, no entity model, no decisions about what your product "is" yet.
Your site has two halves — the public side (landing page, pricing, blog) and the logged-in side (dashboard, settings, notifications). /app marks the boundary. There's no confusion about which side you're on.
Compare that to /home, where visitors would wonder: "Is / the homepage, or is /home?" With /app, the answer is obvious.
/dashboard only makes sense if your primary view is a dashboard. /files only works if your product is file-based. /app can contain anything — dashboards, settings, projects, notifications. As your product grows, the route still fits.
When your product matures, you might want app.example.com or /:team slugs. Migrating away from /app is straightforward — it's a single route prefix swap, not an architecture change. Start simple, evolve when you need to.