Getting started
See how to go from purchase to first local run with Starter Pro, and understand the fastest path from setup to launch.
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.
- 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.
- 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.
- 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.
- 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.
- 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
pnpm installStart 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.
NEXT_PUBLIC_APP_URL=http://localhost:3000
DATABASE_URL=
AUTH_SECRET=Add optional variables only when you are ready to validate those systems.
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
pnpm db:generate
pnpm db:migrate
pnpm db:seedGenerate 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
pnpm devhttp://localhost:3000Confirm 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
Validate auth first
- sign in works locally
- registration flow is reachable
- protected routes redirect correctly
- session-aware UI behaves correctly
- provider and password flows are understood
Validate billing flows
- billing page renders correctly
- checkout flow is understood
- portal flow is understood
- subscription state is clear
- webhook responsibilities are understood
Validate the backend baseline
- 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:
- rewrite the whole UI
- rename everything
- add features immediately
- ignore auth and billing validation
- 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:
- get the app running
- validate auth
- validate billing
- validate protected routes
- replace branding
- add your first domain entity
- 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.