Skip to main content

Implementation Paths

Most buyers do not adopt a starter in the same way. This page outlines the three common paths this starter supports best.

Path 1: Fast Branded Fork​

Choose this when you want to validate speed first.

Typical team​

  • founder-led build
  • small product team
  • tight timeline to demo or early launch

What changes first​

  • branding and copy
  • auth provider credentials
  • billing plan definitions
  • a narrow set of product workflows

What stays mostly intact​

  • app surface split
  • backend package layout
  • starter-level permissions and capability model

Path 2: Product-First Fork​

Choose this when the repo shape fits, but your domain model and workflows will diverge quickly.

Typical team​

  • product team with defined roadmap
  • need for moderate customization across org, portal, and platform
  • desire to keep the architecture while replacing product details aggressively

What changes first​

  • backend schema and domain modules
  • route-level UI inside each surface
  • access rules and product capabilities
  • integrations specific to the product domain

What usually stays intact​

  • high-level surface boundaries
  • shared package strategy
  • local setup and deployment shape

Path 3: Architecture-Preserving Implementation​

Choose this when the main reason to buy the starter is the structural baseline rather than the current feature content.

Typical team​

  • larger engineering team
  • heavier product-specific requirements
  • longer-term investment in the org, portal, and platform model

What changes first​

  • substantial product workflows
  • domain-specific package and backend expansion
  • custom integrations and policy logic
  • deeper permissions and capability modeling

What you are really buying​

  • the repo shape
  • the separation of surfaces
  • the backend/package boundaries
  • the existing setup, auth, billing, and access-control baseline

How To Choose​

  • If speed matters most, start with the fast branded fork.
  • If product divergence is obvious but the architecture still fits, take the product-first path.
  • If you mainly want the structural baseline, use the architecture-preserving path.