Why /app?

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.

What real products do

You might expect every product to use /app, but most don't. They've each found their own pattern:

  • Subdomains — Slack uses your-workspace.slack.com, Stripe uses dashboard.stripe.com, Spotify uses open.spotify.com. The logged-in product is a whole separate domain.
  • Dynamic slugs — Linear, Notion, Vercel, and GitHub put your team or username right in the URL: linear.app/your-team, github.com/your-name. The URL is the context.
  • Content-type paths — Figma sends you to /files, Todoist to /app/today, Discord to /channels. The path describes what you're looking at.
  • No prefix at all — Canva and ChatGPT just use /. The product is the site.

So why does your starter use /app?

It's the simplest thing that works

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.

It draws a clear line

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.

It doesn't assume what you're building

/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.

It's easy to outgrow

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.