Skip to main content

Active Priority

This is the single-source baton for what should happen next.

Update it whenever the active phase or next-task stack changes.

Current Phase​

  • Phase 1: Starter Hardening And Packaging Readiness

Current Objective​

Make the existing starter credible enough that it can be:

  • used internally as the default base for a real B2B2C SaaS app
  • branched cleanly into new projects without hidden setup debt
  • marketed honestly without selling paper features

Why This Is Next​

  • The repo already has a lot of real operational depth.
  • The current risk is not lack of surface area; it is unvalidated edges, stale planning, and unclear starter boundaries.
  • Shipping marketing before this pass would overstate readiness and hide the real work still needed for day-one trust.

Immediate Next Tasks​

  1. Browser-validate the highest-risk critical flows end to end: org bootstrap, portal invite and access, platform bootstrap, impersonation and support handoff, billing change/cancel/reactivate, API credential issuance, webhook test and retry, export request and download, and maintenance-mode recovery paths
  2. Finish rate-limit and abuse-protection wiring on sensitive auth, invite, support, webhook-test, and API-credential paths that still rely on the shared policy layer more than active enforcement
  3. Browser-validate the launch-tier billing baseline in Polar sandbox: verify the new provider-state visibility, legacy shared-customer handling, and repair-state messaging against live checkout, plan-change, cancellation, reactivation, and portal flows
  4. Tighten starter bootstrap quality: verify seed flows, platform-admin bootstrap, org bootstrap, env validation, and first-run docs from a clean setup path
  5. Replace stale planning and product docs with starter-accurate guidance: what exists, what is intentionally out of scope, and what extension points are safe for downstream apps
  6. Define the launch-tier feature boundary clearly so enterprise features stay deferred instead of quietly leaking into the current roadmap

After That​

Once the items above are locked, the confirmed post-Phase-1 direction is:

Phase 2 — Billing depth and operational support polish:

  • seat-count and usage-limit enforcement at plan tier
  • downgrade behavior and seat reconciliation
  • platform-admin billing repair tooling (plan override, seat reset, billing-identity re-link)
  • impersonation lifecycle hardening and portal support-session polish
  • incident-notice and governance workflow tightening

Phase 3 — Starter bootstrap and developer experience:

  • clean bootstrap path from env setup to first run
  • seed and demo defaults that showcase real starter value
  • setup, branding, and extension-point docs for downstream forks

Phase 4 — Productization and honest market surface:

  • feature boundary documentation: launch-tier vs deferred
  • demo content and walkthrough paths grounded in shipped flows

Phase 5 — API productization and extensibility:

  • full external API surface definition: resource shape, auth, errors, pagination
  • key scopes, API usage logs, and versioning contract
  • external API docs
  • webhook event catalog with stable schemas
  • background job patterns and feature flag ergonomics
  • notification and event pipeline definition and extension points

Phase 6 — Enterprise readiness (demand-gated):

  • OIDC SSO first, SAML if needed, SCIM after SSO adoption
  • enterprise compliance and packaging decisions

Completion Signal​

This phase is complete when:

  • the critical auth, billing, admin, portal, impersonation, and automation flows validate cleanly end to end
  • the remaining launch-tier gaps are either shipped or explicitly documented as not part of this starter tier
  • a new project can bootstrap from this repo without guesswork-heavy setup or hidden environment traps
  • the docs describe the starter that actually exists today, not a different historical roadmap