Evaluator FAQ
This page answers the first questions a developer usually asks when deciding whether this starter is worth buying or adopting.
Who is this starter for?
Teams building a B2B2C SaaS product with separate org, portal, and platform concerns.
What is already included?
The repo includes the main product app, a separate marketing app, a separate docs app, a Convex backend package, and shared packages for config, access, permissions, theme, and supporting infrastructure.
See what-you-get.md.
What will I still need to decide myself?
Your product rules, final auth setup, billing policies, domain workflows, copy, visual identity, and external integrations that are specific to your business.
See ../development/customization-guide.md.
How hard is it to get running locally?
The starter already has a guided first-run path. The default flow is pnpm continu:init followed by pnpm dev, with demo users and tenant routing support already accounted for.
See ../development/local-setup.md.
What should I read if setup or local routing goes sideways?
Use the buyer-facing troubleshooting page first. It focuses on the actual evaluation blockers instead of maintainers' internal debugging detail.
See ../development/evaluator-troubleshooting.md.
How are auth and billing handled?
Auth is handled through Convex Auth, and billing is modeled at the organization level with Polar as the billing provider.
See ../development/auth-model.md and ../development/billing-model.md.
Is access control already modeled?
Yes. The starter already distinguishes roles, permissions, and higher-level product capabilities.
See ../development/permissions-and-capabilities.md.
Is this tied to one specific vertical?
No. The starter is opinionated about architecture and surface boundaries, not about one narrow product niche.
Where does the backend live?
Authored Convex backend code lives in packages/backend/convex, not inside the app package.
Where should I start if I want to evaluate the codebase quickly?
Read the starter overview, what-you-get page, surfaces and host model, then the architecture summary.
How do teams usually adopt this starter?
Most teams fall into one of three paths: a fast branded fork, a product-first fork with moderate customization, or a heavier architecture-preserving implementation for a more complex SaaS.
How do I know if this starter fits my product?
The starter is strongest when your product has a real org, portal, and platform split. If you only need one thin app surface, it may be more structure than you want.
See vertical-fit-and-use-cases.md.