Getting started

See how to go from purchase to first local run with Starter Pro, and understand the fastest path from setup to launch.

Starter ProUpdated September 24, 2026
Starter ProSetup

Get from purchase to product work fasterLink to section

Starter Pro is built to shorten the path between:

  • buying the product
  • running it locally
  • validating the foundations
  • customizing the product
  • shipping your own SaaS faster

The goal is not to study the codebase for days.

The goal is to get the production baseline running, confirm the important systems, then start building your product on top of it.

After purchase

Download and unzip Starter Pro from your claim email before running the setup commands below. Need the email again? Use purchase recovery to resend your access link.

The confirmation page reports payment as confirmed only when your checkout is complete and paid. A pending, incomplete, expired, or unavailable confirmation does not provide download access. If the page cannot confirm your payment, check again or contact support before paying again.

Payment confirmation and email delivery are separate steps. Use the access link in your claim email once delivery has been processed.

Core setup principle

Validate the foundation first. Customize second. Build your product third.

First 30 minutes after purchaseLink to section

Use this timeline to choose your next action, not to race through setup. The timeboxes are suggested planning checkpoints, not measured setup times or an email-delivery promise. Downloads, PostgreSQL, and provider configuration can take longer. A local first run is not a production launch.

Before starting, have the checkout email available and review the README and Node.js/pnpm requirements in your downloaded release. Use a local development database and keep environment files private. Buying Starter Pro does not provision your database, email sender, OAuth apps, or Stripe account for you.

  1. 0–5 minutes: check payment and claim access. Check your checkout confirmation and the inbox/spam folder for the email used at checkout. Payment confirmation is separate from access-email delivery. Continue when you can open the claim email; if access is missing, follow purchase recovery.
  2. 5–10 minutes: download and inspect the package. Open the access link, check that the product is Starter Pro, download the ZIP, and unzip it. Read the release README before running commands. Your checkpoint is an extracted project and a clear setup entry point, not a configured SaaS. See delivery for the access flow.
  3. 10–20 minutes: prepare the local foundation. Follow the setup flow below for dependencies, environment variables, PostgreSQL, and database setup, in that order. Use only a local development database; do not run migrations or seeds against production. Check the environment guide for the integrations you intend to exercise. Continue only after setup succeeds.
  4. 20–25 minutes: check the first local run. Start the app using the release instructions, then verify a configured sign-in flow and a protected page. A rendered login or billing page alone does not validate authentication or payments. Use the auth guide and testing fixtures for the checks your local configuration supports; do not bypass verification to meet a timebox.
  5. 25–30 minutes: choose one product change. Once the baseline works, choose a small branding or product-copy change and preserve the working auth and billing foundations. Record any integration still unverified. Follow billing testing separately in test mode, then complete the production checklist before launch.

Payment or access is blockedLink to section

If payment is uncertain, contact purchase support before paying again. Recovery does not complete an unpaid checkout. If payment is confirmed but the email or link is missing or expired, use purchase recovery with the same checkout email. A recovery confirmation does not prove a purchase exists or that an email reached your inbox. Follow the recovery troubleshooting guide rather than repeatedly submitting requests.

If recovery still fails, the link shows another product, or you cannot access the checkout email, use purchase support. Include the checkout email, product name, approximate purchase date, and the error you see. Do not share passwords, card details, API keys, or claim/download links, including in screenshots. No support response-time guarantee is promised.

Local setup is blockedLink to section

Pause at the failing step. Compare the downloaded release README, required Node.js/pnpm versions, environment values, and local PostgreSQL connection with local development. Keep the failing command and a sanitized error for diagnosis; do not delete data, remove validation, or switch to production credentials to get past a setup error.

If email, OAuth, or billing is not configured, use the corresponding guide and record that flow as unverified. Continue from the last successful checkpoint when the prerequisite is ready, even if that takes longer than 30 minutes.

What this page helps you doLink to section

By the end of this page, you should understand:

  • what to configure first
  • what to validate before editing deeply
  • how to avoid wasting time on low-leverage setup
  • how to move from installation to real product work
  • when to focus on auth, billing, backend, and branding

The fastest serious pathLink to section

Starter Pro gives you a production-ready baseline with:

  • authentication
  • billing
  • protected routes
  • settings
  • dashboard structure
  • backend-ready foundations
  • secure delivery path

You are not starting from a blank codebase.

You are starting from a product-shaped system that is already much closer to launch.

Important

The fastest path is not rewriting everything.

The fastest path is validating what already exists, then replacing only what belongs to your product.

Setup flowLink to section

Download and unzip Starter ProLink to section

Open your claim email and use the access link to download your package. Unzip it before running the setup commands below.

Install dependenciesLink to section

terminal
pnpm install

Start by installing the workspace dependencies.

This gives you the local baseline required to run the app, generate the database client, and validate the foundation.

Configure local environmentLink to section

Start with the core variables first.

.env.local
NEXT_PUBLIC_APP_URL=http://localhost:3000
DATABASE_URL=
AUTH_SECRET=

Add optional variables only when you are ready to validate those systems.

.env.local
AUTH_GITHUB_ID=
AUTH_GITHUB_SECRET=
AUTH_GOOGLE_ID=
AUTH_GOOGLE_SECRET=

STRIPE_SECRET_KEY=
STRIPE_WEBHOOK_SECRET=
STRIPE_PRICE_STARTER_PRO_ONE_TIME=

RESEND_API_KEY=
AUTH_EMAIL_FROM=

Do not overconfigure too early.

Get the baseline running first.

Run database setupLink to section

terminal
pnpm db:generate
pnpm db:migrate
pnpm db:seed

Generate the database client, run migrations, and seed local fixtures.

This helps you validate auth, users, billing surfaces, and local development flows faster.

Start the appLink to section

terminal
pnpm dev
browser
http://localhost:3000

Confirm that the app loads and the main product routes are reachable.

Validate foundationsLink to section

Before changing product logic, confirm the important layers:

  • sign in
  • registration
  • protected routes
  • seeded users
  • billing surfaces
  • settings pages
  • dashboard shell

This gives you confidence that the baseline works before you customize it.

Replace branding and product copyLink to section

Once the baseline is validated, update:

  • product name
  • logo
  • metadata
  • navigation labels
  • billing copy
  • email sender identity
  • marketing links

Branding comes after validation, not before.

Build your product layerLink to section

Now add your real product:

  • domain entities
  • workflows
  • onboarding
  • dashboards
  • customer-facing features
  • internal operations

Keep auth, billing, and protected access intact while you build your differentiation.

Validation prioritiesLink to section

Authentication

Validate auth first

Confirm that the authentication foundation behaves correctly before product customization.
  • sign in works locally
  • registration flow is reachable
  • protected routes redirect correctly
  • session-aware UI behaves correctly
  • provider and password flows are understood
Billing

Validate billing flows

Understand how billing flows work before integrating real production billing.
  • billing page renders correctly
  • checkout flow is understood
  • portal flow is understood
  • subscription state is clear
  • webhook responsibilities are understood
Backend

Validate the backend baseline

Confirm the backend-oriented structure is ready before domain customization.
  • database client is generated
  • migrations run locally
  • seed data exists
  • server-side boundaries are understood
  • domain additions have a clear place

What to avoidLink to section

The most common mistake is trying to redesign everything before the foundations are validated.

Avoid this order:

  1. rewrite the whole UI
  2. rename everything
  3. add features immediately
  4. ignore auth and billing validation
  5. discover infrastructure issues later

That path feels productive, but it usually delays launch.

A better rule:

validate the base first, then customize, then build the product.

Decision guideLink to section

Prefer this path

  • install dependencies first
  • configure only the required environment variables
  • validate authentication and billing before redesigning
  • replace branding after the baseline works
  • build your product inside the existing structure

Avoid this path

  • rewriting the UI before validating the foundation
  • configuring every integration too early
  • removing authentication or billing before understanding them
  • building product features on a broken setup
  • treating Starter Pro like a blank template

Fastest path to valueLink to section

If your goal is speed, focus on this sequence:

  1. get the app running
  2. validate auth
  3. validate billing
  4. validate protected routes
  5. replace branding
  6. add your first domain entity
  7. ship the first vertical slice

This gives you the best speed-to-confidence ratio.

High-leverage setup

Starter Pro pays for itself when you avoid rebuilding the foundation and start building what customers actually care about.

First product changesLink to section

After setup, the best first changes are usually:

  • replace branding
  • update metadata
  • define your core domain model
  • add your first real entity
  • connect the first real workflow
  • keep auth and billing intact

Examples:

  • projects
  • workspaces
  • reports
  • AI generations
  • CRM records
  • internal operations data

The exact feature does not matter.

What matters is building your product inside the existing structure instead of fighting it.

When it becomes worth buyingLink to section

Starter Pro becomes worth buying when your question changes from:

Can I prototype something?

to:

How do I launch this without burning time on auth, billing, and setup?

If that is already your question, the fastest next step is not more setup research.

It is moving to Starter Pro and building on the baseline.

Production baseline

Start from a product-shaped SaaS foundation instead of rebuilding the infrastructure layer.

Launch confidence

Validate authentication, billing, protected routes, and backend structure earlier.

Higher-leverage work

Spend more time on customers, product logic, workflows, and distribution.

Next stepsLink to section