Product scope
See what ships, what every buyer must decide, and what version one deliberately omits.
Product scope
This foundation is a source-owned authenticated SaaS application foundation. It is designed to make the first durable product capability safe to build and deploy; it is not a finished business, industry-specific application, or an all-features starter kit.
Use this page before estimating product work or making a buyer-facing claim. A visible source file is not necessarily a shipped buyer feature, and an optional integration is not enabled merely because its package exists.
Included foundation capabilities
| Area | What ships |
|---|---|
| Product application | React SPA, protected routes, settings, notification inbox, neutral dashboard, responsive UI primitives, PWA, and a typed API client. |
| Data and API | PostgreSQL, dbmate migrations, Hono routes/services/repositories, shared Zod contracts, owner-scoped data patterns, and test scaffolding. |
| Authentication | Better Auth password, verification, reset, magic link, sessions, and optional Google sign-in. |
| Billing | One selected deployment provider: Polar, Stripe, or Dodo Payments; plans, hosted checkout, portal, entitlement policy, verified webhooks, and reconciliation. |
| Communication | React Email templates, Resend delivery, development email-log fallback, in-app preferences, and optional Slack operational alerts. |
| Storage and observability | Optional R2/S3/GCS owner-scoped upload path, structured logs, optional Sentry, and deployment readiness. |
| Operations | Railway, Dokploy, and OpenTofu-managed cloud paths; release, upgrade, troubleshooting, removal, and buyer scaffolding contracts. |
Read Included product surfaces for routes and zero-key behavior, rather than assuming that a provider configuration creates a customer outcome.
Every buyer supplies
The generated repository intentionally leaves these decisions to the product owner:
- the actual product domain, dashboard outcome, copy, pricing decision, and customer journey;
- commercial name, logo, accessible visual identity, sender identity, and public domain;
- marketing site, blog, SEO program, analytics choice, and acquisition funnel;
- terms, privacy, retention, deletion, tax, compliance, support, and incident policies;
- external provider accounts, production credentials, DNS, monitoring ownership, backups, and operational response;
- any authorization model beyond a single user owning personal resources.
Marketing-site code is not generated for a buyer application. Public waitlist and contact endpoints are available for a buyer-owned marketing site; they are not a shipped marketing website.
Deliberately not included in version one
| Capability | Why it is absent |
|---|---|
| Organizations, roles, SSO, SCIM, or admin impersonation | Multi-tenant authorization needs a product-specific ownership and disclosure model. |
| Generic queues, cron jobs, workers, or durable AI processing | No generic executor is safe without a validated job, authorization handoff, retry/recovery, cost, and support contract. |
| Built-in blog, SEO suite, marketing pages, legal pages, or sales analytics | These are business and brand decisions outside the buyer product application. |
| Product analytics or a feature-flag platform | Instrumentation, consent, retention, and event taxonomy must be product-owned. |
| Malware scanning, audit-log UI, compliance export, automatic retention/erasure, or application-level field encryption | These require a specific risk model, operational owner, and evidence; they are not checkbox features. |
| Generic coupon, tax display, usage, seat, refund, or provider-switching UI | The included billing contract is intentionally limited to one deployment provider and recurring monthly/yearly plans. |
| A public third-party API or generated OpenAPI contract | The typed Hono RPC boundary is for the shipped browser application. External integrations need their own authentication, versioning, abuse, and support contract. |
Absence is not a prohibition forever. It means the buyer must make a separate product decision and prove the new boundary before claiming support.
Choose the next path
- Add a product-owned resource with the worked feature recipe and domain golden path.
- Replace neutral identity and UX with Customization.
- Add a provider-backed capability only through its billing, email, storage, or authentication contract.
- Remove an optional capability completely with Removing subsystems.
- Evaluate a queue, cron, or long-running process with Background work before adding infrastructure.