Current State
This file describes the actual starter baseline already present in the repo.
Use it before choosing the next work so planning starts from shipped code, not older docs or product drift.
Current Delivery Focus
The repo is no longer in "port the old app" mode.
The active priority is:
- Starter hardening and packaging readiness
The repo already contains most of the painful B2B2C SaaS infrastructure that usually slows down a new app:
- separate org, portal, and platform surfaces
- Convex auth plus MFA, with optional lower-level step-up primitives left available for downstream apps
- org billing with Polar checkout, plan change, cancellation, reactivation, and webhook reconciliation
- entitlement-backed premium operations like API credentials, webhooks, audit logs, and exports
- platform-admin impersonation and portal support handoff flows
- inbox plus email notification delivery across org, portal, and platform
- retention jobs, audit logs, maintenance mode, feature flags, and incident notices
The repo is not yet positioned as an enterprise starter.
Out of scope for the current tier unless product traction justifies it later:
- SAML / OIDC enterprise SSO
- SCIM provisioning
- advanced enterprise procurement or compliance workflows
Product Positioning Baseline
The starter should optimize for developers who want the operational guts of a serious SaaS app without bundling a lot of CMS-style surface area or starter candy.
The current product direction is:
- a real B2B2C starter with org, portal, and platform boundaries already in place
- strong default support for auth, billing, notifications, permissions, operational controls, and admin governance
- opinionated but extensible defaults instead of a giant generic app-builder
- honest scope boundaries around what is launch-tier vs later premium or enterprise work
App Baseline
Already in place:
Org surface (/org)
- public auth and invite acceptance flows
- overview plus settings for account, billing, custom domains, API access, webhooks, audit logs, exports, notifications, roles, and security
- team-management and session-governance flows
- entitlement-backed premium operations
Portal surface (/portal)
- public auth, invite acceptance, suspended-membership handling, and tenant-aware routing
- overview, activity, support, account/profile/notification settings
- org-scoped portal membership and support request flows
Platform surface (/platform)
- first-admin bootstrap and platform-admin invite acceptance
- overview, organizations, users, subscriptions, audit, and control-plane settings
- maintenance mode, feature flags, incident notices, and operator-management flows
- org and portal impersonation entrypoints with support-session handling
Shared app behavior
- maintenance routing and public maintenance page
- unknown-tenant handling
- locale-aware app and marketing surfaces
- shared uploader, rich-text editor, and dirty-state baseline primitives
Backend Baseline
Already in place:
- Convex auth and schema baseline
- explicit org, portal, and platform identity boundaries
- MFA plus session-governance posture, with no separate step-up gating on routine org or platform operations
- org billing state, billing email isolation, checkout, plan changes, cancellation/reactivation, and webhook reconciliation
- org billing provider-state visibility for launch-tier trust: provider subscription status, portal availability, and explicit repair states for missing customer, missing subscription, shared customer, price mismatch, and provider portal outage
- API credential issuance and revocation with token usage tracking
- webhook endpoint creation, secret rotation, test delivery, retry handling, and delivery-attempt history
- JSON export request and download flow for tenant operations state
- org, portal, and platform notification preferences plus inbox and email delivery wiring
- platform-admin impersonation, portal support handoff, and retention coverage
- maintenance mode, platform feature flags, and incident notice resolution
- scheduled retention jobs for expired auth, invite, impersonation, support-session, webhook, and incident records
Partially complete or still thin:
- operational API productization is real but narrow: there is one authenticated org operations endpoint, not a broader external API platform yet
- rate-limit primitives and policies exist, but enforcement still needs a final pass across the highest-risk callsites
- starter documentation is directionally useful but not yet sharp enough for external productization
- bootstrap, seed, and first-run guidance still need a stricter "can a stranger launch this quickly" pass
Not built yet:
- enterprise identity and provisioning
- broader public API surface with versioning, richer scopes, and clearer external docs
- deeper in-app billing repair tooling for legacy shared-customer cases
- fuller billing-provider cache and richer billing-profile, invoice, and payment-method management
Docs Baseline
Already in place:
- app, product, and development docs structure
- starter architecture and workspace rules
- planning docs and operating docs
Needs correction now:
- the planning docs had stale roadmap content from an older product track
- the current planning set now needs to stay aligned with the actual starter, not a legacy app port
Rule:
- keep this file current whenever repo reality changes materially
Immediate Implication
The highest-leverage next work is not adding more surfaces.
The highest-leverage next work is:
- validating and hardening the flows already present
- closing the remaining launch-tier operational gaps
- making the starter easier to bootstrap, understand, and trust
- documenting a clear boundary between launch-tier starter scope and future enterprise scope