Plain language. Every term explained. Expected outcome after every step. If you've bought Already and don't know where to start — start here.
Already is a complete, working web application — built with modern tools — that you can use as the starting point for your own SaaS product.
Think of it like buying a fully furnished apartment instead of an empty one. The structure is there, the plumbing works, the wiring is done. You move in and redecorate — you don't lay pipes.
SaaS stands for "Software as a Service". It means a web app people pay to use — usually with a monthly or yearly subscription. Examples: Notion, Figma, Linear. Already gives you the foundation to build one of these.
Specifically, Already gives you: user login, team accounts, Mollie payments, email sending, a database, an admin panel, and a lot more — all pre-built and production-quality. You add the parts that are unique to your product.
A starter kit (also called a boilerplate or template) is a pre-written codebase that solves common, repetitive problems so you can focus on what makes your product unique. Without one, every new project starts with weeks of setting up auth, billing, and email from scratch.
All free to sign up. No credit card required for any of these services to start.
Do this once. Takes about 10 minutes.
A terminal (also called command line or shell) is a text-based way to control your computer. You type commands, press Enter, and things happen. On Mac: open Spotlight (⌘ Space), type "Terminal", press Enter. On Windows: install WSL, then use the Ubuntu terminal.
Node.js lets your computer run JavaScript code. Already is built with JavaScript, so this is required.
Go to nodejs.org and download the LTS version (the one that says "Recommended For Most Users"). Install it like a normal app.
Verify it worked — open your terminal and type:
node --version
You should see something like v20.11.0. Any version starting with 20 or higher is fine.
Your app uses thousands of small pieces of code written by other people (called "packages" or "dependencies"). A package manager downloads and manages all of these for you automatically. pnpm is faster and more efficient than the default npm.
In your terminal:
npm install -g pnpm
Verify:
pnpm --version
Git tracks every change you make to your code, like a detailed save history. It also lets you download code from GitHub. On Mac, Git is usually already installed. On Windows, download from git-scm.com.
Check if you have it:
git --version
If you see a version number, you're good.
This tool lets you run Supabase (your database) on your own laptop while you're building — so you don't need an internet connection to test things.
On Mac (using Homebrew):
brew install supabase/tap/supabase
Don't have Homebrew? It's the standard Mac package manager. Install it first: paste this into your terminal and press Enter:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"On Windows (WSL) or Linux:
brew install supabase/tap/supabase
Verify:
supabase --version
All four commands return version numbers without errors. You're ready to get the code.
After buying Already, Polar (the payment processor) automatically sends a GitHub repository invite to the email address you used at checkout. This usually arrives within 1–2 minutes.
The email is from GitHub (not from Already). Subject line will say something like: "You've been invited to collaborate on a repository".
Check your spam folder first. Still nothing after 5 minutes? Email [email protected] with your order confirmation and we'll sort it.
Click the "Accept invitation" button in the email, or go to github.com/waitwhatco/already-eu-template while logged into GitHub and accept it there.
Important: GitHub invites expire after 7 days. Accept it now.
You can see the private repository at github.com/waitwhatco/already-eu-template and it shows "You are a collaborator on this repository".
A fork stays linked to the original. A template creates a fresh, independent repository — your own history from commit one. That's what you want for a product you'll build on.
On the Already template page on GitHub:
my-saas-app)You now have a repository at github.com/YOUR_USERNAME/YOUR_REPO_NAME that's entirely yours. No connection to the original.
"Cloning" a repository downloads a copy of all the code to your computer and keeps it connected to GitHub so you can sync changes back and forth.
Open your terminal. Navigate to where you keep your projects (e.g. cd ~/projects), then:
git clone https://github.com/YOUR_USERNAME/YOUR_REPO_NAME
cd YOUR_REPO_NAME
Replace YOUR_USERNAME and YOUR_REPO_NAME with your actual values. You can copy the exact URL from the green "Code" button on your GitHub repo page.
Then install all the dependencies:
pnpm install
This downloads all the packages your app needs. It may take 1–2 minutes the first time.
You see a folder on your computer with all the code. Running ls shows files like package.json, CLAUDE.md, app/, lib/.
Supabase is a service that gives you a Postgres database (where all your app's data is stored — users, subscriptions, everything) plus user authentication (login/signup) already built. Already is deeply integrated with it. You can start with the free tier and upgrade only if you need to.
Once your project is ready, go to Project Settings → API. You'll see three values you need:
https://abcdefgh.supabase.coeyJ...Also go to Project Settings → Database to get your connection strings. You'll need the "Connection string" (URI format) — there are two: Session mode (for most things) and Direct (for migrations).
Don't share these keys. The service_role key gives full access to your database. It goes in your private .env.local file only.
Mollie is the most widely used payment processor for internet businesses. It handles credit cards, invoices, subscriptions, and tax. Already uses Mollie for all billing. You develop against "test mode" — fake cards, no real money — until you're ready to go live.
pk_test_)sk_test_)When something happens in Mollie (a payment succeeds, a subscription cancels), Mollie sends a notification to your app. This is called a webhook. Your app needs to listen for these to keep its database in sync with Mollie.
For local development, Already uses the Mollie CLI to forward webhooks to your laptop. Install it:
# Mac
brew install mollie/mollie-cli/mollie
# Windows/Linux: see mollie.com/docs/mollie-cli
Log in to the CLI:
mollie login
When you later run pnpm dev, it will automatically start the webhook listener and print a webhook secret that starts with whsec_. You'll add that to your env file in step 7.
Brevo is a developer-friendly service for sending transactional emails — things your app sends automatically, like "confirm your email", "your payment failed", "you've been invited to a team". Already uses React Email to write these templates. Brevo's free tier covers 3,000 emails/month.
re_For local development, you don't need a verified domain. Emails won't actually send — they'll appear in the React Email preview instead. You only need a real domain when you go live.
An environment file (.env.local) is a plain text file where you store your secret keys and configuration. The app reads from this file when it starts. It's never committed to GitHub — it stays only on your computer (and on Vercel when you deploy). Think of it as the keys to your services.
Already includes a template file called .env.example that lists every variable you need with comments explaining each one. Copy it:
cp .env.example .env.local
Now open .env.local in any text editor (VS Code, Notepad, TextEdit) and fill in the values you collected in steps 4–6.
The file looks like this — replace the empty values:
# Supabase — from Project Settings → API
NEXT_PUBLIC_SUPABASE_URL=https://YOUR_PROJECT.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJh...
SUPABASE_SERVICE_ROLE_KEY=eyJh...
DATABASE_URL=postgresql://postgres:[email protected]_PROJECT.supabase.co:5432/postgres
DATABASE_URL_DIRECT=postgresql://postgres:[email protected]_PROJECT.supabase.co:5432/postgres
# Mollie — from Developers → API keys (use test keys to start)
MOLLIE_SECRET_KEY=sk_test_...
NEXT_PUBLIC_MOLLIE_PUBLISHABLE_KEY=pk_test_...
MOLLIE_WEBHOOK_SECRET=whsec_...
# Brevo — from API Keys page
BREVO_API_KEY=re_...
The .env.example file has every variable with inline documentation. Read the comments — they explain what each one does and where to find it.
Already includes a setup script that checks your config, runs database migrations, and bootstraps Mollie products. Run it once:
pnpm setup
It's interactive — it will tell you if anything is missing from your .env.local and explain what to fix. Follow the prompts.
For Mollie billing, also run:
pnpm setup:mollie
This creates the subscription plans in your Mollie test account and writes their IDs back to your .env.local.
pnpm dev
This starts everything at once: your app, the local database, the Mollie webhook listener, and the email preview server.
Open your browser and go to:
localhost:3000 — your app, showing a marketing pagelocalhost:54323 — Supabase Studio, a visual database browserlocalhost:3001 — React Email preview (your email templates)"Missing env variable X" — you have a typo or missing value in .env.local. Re-check step 7.
"Cannot connect to database" — double-check your DATABASE_URL. Make sure you replaced PASSWORD with your actual Supabase DB password.
"Port 3000 already in use" — something else is running on that port. Quit other dev servers or restart your terminal.
Still stuck? Run pnpm already doctor — it checks your setup and tells you exactly what's wrong.
Here's a map of what Already ships with and where to find each part.
Open the app/ folder. Routes are grouped by who can access them:
app/
(public)/ ← Anyone can see this: marketing pages, pricing
(auth)/ ← Login, signup, forgot password, MFA setup
(app)/ ← Logged-in users with an org account
(billing)/ ← Paid subscribers only
(admin)/ ← Admin users only: user management, impersonation
Already ships 16 complete features. You can use all of them, ignore the ones you don't need, or delete them entirely:
app/(auth)/)messaging/templates/lib/jobs/config/flags.tsdocs/ folder.pnpm db:seed # fill your local database with demo users and data
pnpm db:studio # open a visual database browser
pnpm email # preview your email templates in the browser
pnpm reset # wipe and re-seed the database (safe — local only)
First things to change before you start building your actual product.
Open config/app.ts. Change name, description, and url to match your product.
This value flows through the app — it appears in email subjects, page titles, and the admin panel. Change it once here and it updates everywhere.
Open config/billing.ts. This file defines your pricing tiers — names, prices, and which features each tier unlocks. Change these to match your actual product plans.
Then re-run pnpm setup:mollie to sync the new plan config to Mollie.
The public marketing page lives at app/(public)/page.tsx. Replace the placeholder copy with your product's actual value proposition.
The legal pages (privacy policy, terms of service) are at content/legal/. Update them with your company details before you go live.
Vercel is the hosting service Already is built for. You connect your GitHub repository, set your environment variables, and Vercel automatically deploys your app every time you push code. Free tier is enough for most early-stage products.
The first deploy will fail because your environment variables aren't set yet. That's expected.
In your Vercel project, go to Settings → Environment Variables. Add every variable from your .env.local file.
Important differences for production:
pk_live_, sk_live_) instead of test keyshttps://YOUR_DOMAIN.com/api/webhooks/molliesupabase start)BREVO_FROM_EMAILAfter saving, trigger a new deployment from the Vercel dashboard.
In Vercel project settings, go to Domains and add your domain. Vercel will give you DNS records to add at your domain registrar (wherever you bought the domain — Namecheap, GoDaddy, Cloudflare, etc.).
DNS changes can take up to 24 hours to propagate, but usually take minutes.
Your app is live at your Vercel URL (and your custom domain if you set one). Real users can sign up. Real payments go through Mollie.
Once you have a live Mollie key sitting in .env.local, that file is a liability. A stolen laptop, a careless backup, or one wrong git add and the key is out in the open. The fix takes about three minutes.
Your credentials move from a plain text file into the macOS Keychain — the same secure store Safari uses for your saved passwords. Already's CLI pushes them in, pulls them out as environment variables before pnpm dev, and refuses to let you commit a .env file that contains real production keys.
From your project directory:
pnpm already secrets push
The CLI prompts you for each managed key (Mollie, Supabase, Brevo, Upstash, and so on). Press Enter to skip any you don't have yet. The values never touch the filesystem.
Linux: install pass first (apt install pass on Debian or Ubuntu, brew install pass on macOS Homebrew), then run the same command.
.env.localOpen .env.local and delete the lines for every key you stored. Leave the public ones in place: NEXT_PUBLIC_*, app name, feature flags. Those are not secrets.
Confirm nothing live remains:
pnpm already secrets scan
Exit code 0 means you're clean. Exit code 1 lists the file and line of anything that still looks like a live key.
Add this alias to your shell rc file (~/.zshrc on macOS by default):
alias already-env='eval "$(pnpm already secrets export)"'
Then in any new terminal session:
already-env && pnpm dev
The first time the Keychain serves a value, macOS shows a permission dialog — click Always Allow so it doesn't ask again for that key.
Your secrets live in the Keychain. Your .env.local contains only public, non-credential config. The pre-commit hook blocks any future accident before it leaves your machine.
When your customer is an enterprise buyer (or you're shipping into a regulated industry), the security questionnaire asks one question every time: can the org admin force every member to use two-factor authentication? Already's answer is yes, and it's one toggle.
Multi-factor authentication. The user signs in with their password, then proves they hold a second factor — usually a six-digit code from an app like 1Password or Authy, or a passkey saved in their phone. Already supports both.
Only owners can change this policy. If you're the founder and only member, that's you. If you joined as an admin or member, ask the owner.
Inside the app at /app/settings/security, click Require MFA. Confirm the prompt. The change is instant — Already writes it to the orgs.mfa_required column and reloads the page.
On their next request to any /app/* route, Already's layout guard redirects them to /mfa/verify?reason=org_policy. They set up an authenticator app or a passkey, the redirect lifts, and they're back in the app. No data loss, no forced sign-out, no support ticket.
Every flip of this setting is written to the org audit log so you can prove the policy was active during any given period — useful for SOC 2 and ISO 27001 audits.
Every member of your workspace passes MFA at next sign-in. The "MFA mandate" question on the next enterprise security questionnaire takes ten seconds to answer with a screenshot.
Run pnpm already doctor — it checks your setup and tells you exactly what's misconfigured. Most problems are a missing or wrong value in .env.local.
Your DATABASE_URL is wrong. Go back to Supabase → Project Settings → Database and copy the connection string again. Make sure you replace [YOUR-PASSWORD] with your actual password (the one you set when creating the project).
In local dev, emails don't actually send — they appear in the React Email preview at localhost:3001. If you're in production, check that your Brevo API key is correct and that you've verified a sending domain.
In local dev, make sure pnpm dev is running (it starts the Mollie webhook forwarder). In production, make sure you've created a webhook endpoint in the Mollie dashboard pointing to /api/webhooks/mollie and that MOLLIE_WEBHOOK_SECRET matches the whsec_ secret from that endpoint.
Run pnpm reset (resets the local database) and pnpm dev again. If it's a code change causing a TypeScript error, run pnpm typecheck to see the exact error.
Already ships with deep Claude Code integration. Once you're in the project directory, Claude Code understands the full architecture — you can ask it anything about the codebase in plain language.
From your project directory, open Claude Code (the desktop app or claude in terminal). Point it at your project folder. It will automatically load the CLAUDE.md and connect to the MCP servers defined in mcp.json.
Things you can ask:
Already includes 10 Claude Code skills — slash commands that understand the project structure:
/add-page ← scaffold a new route with correct auth guards
/add-table ← create a DB table + RLS policy + query helpers
/add-plan ← add a Mollie pricing tier
/add-message ← add an email template
/add-job ← create a background job
/add-flag ← add a feature flag
/deploy ← pre-deploy checklist
/run-migration ← run pending DB migrations
/debug-webhook ← diagnose a webhook problem
/already-update ← check for Already updates
Type any of these in Claude Code and it will walk you through the task step by step, creating all the right files in the right places.
Not sure how something works? Just ask. The CLAUDE.md in the project root contains architecture rules, common pitfalls, and module maps — Claude Code reads it at the start of every session and will answer questions about any part of the codebase.