Build a SaaS With Bolt.new Tutorial (2026)

Go to bolt.new, sign in with GitHub OAuth (preferred — speeds up Phase 6 when you push to GitHub) or email. The free tier lets you generate an app and iterate ~5-10 times before hitting daily token limits. Use the free tier for the first hour to validate your idea fits Bolt; upgrade once you commit.

**Plan picking heuristic.** First-time Bolt user with one SaaS idea: Pro $20/mo (10M tokens) is the right starting point. Most first-week prompts burn 200-500k tokens; the 10M ceiling typically lasts 3-4 weeks of active building. If you hit the ceiling mid-month, you can upgrade to Pro 50 ($50, 26M tokens) without losing your project.

**The 'three apps in parallel' anti-pattern.** A lot of first-time Bolt users start three SaaS apps simultaneously thinking they'll see which one sticks. Token burn triples; quality per app suffers because the prompt iterations are shallower. Discipline: pick one SaaS, build it to 'demo-ready' (auth + payment + 2 core flows), THEN start the next one. Plan size: Pro $20 for one app at a time; Pro 50+ if you genuinely run parallel builds.

**Team plan signals.** Skip Teams unless you have 3+ collaborators actively editing the same project. The Pro tier supports project sharing with read-only links; you only need Teams when multiple people are actively making code changes concurrently.

**The annual discount question.** Bolt offers ~20% off on annual plans. Same answer as every AI tool in 2026: don't take annual until you've done 30 days of real building. The monthly premium is the cost of optionality on a fast-moving product.

This is the phase where 90% of bad Bolt outcomes get baked in. The good news: writing a spec-shaped prompt is a learnable skill, and once you have a template it takes 10 minutes per app.

**The 7-section spec template that works.**

1. **Product name and one-line description.** 'WaitlistPro — a waitlist landing page builder for B2B SaaS founders.'

2. **Stack constraints.** 'Use Next.js 16 App Router, Tailwind, shadcn/ui, TypeScript. Database: Supabase. Auth: Supabase Auth (email magic link). Payments: Stripe Checkout.'

3. **User personas and core flows.** 'Two personas: Founder (logs in, creates waitlist, shares link, sees signups, exports CSV). Subscriber (visits public waitlist URL, enters email, gets confirmation).'

4. **Data model.** 'Users (id, email, name, created_at). Waitlists (id, user_id, slug, title, description, fields_json, created_at). Signups (id, waitlist_id, email, name, custom_data_json, created_at).'

5. **Routes.** '/ (landing page with marketing copy), /signup, /login, /dashboard (list user's waitlists), /dashboard/new (create waitlist form), /dashboard/[id] (waitlist detail + signups table), /[slug] (public waitlist page).'

6. **Pricing tiers.** 'Free: 1 waitlist, 100 signups. Pro: $19/mo, unlimited waitlists, 10k signups, custom branding, CSV export.'

7. **Visual style.** 'Modern minimal, dark mode by default with light mode toggle. Lots of whitespace. Hero section with bold typography. Trustpilot-style social proof block.'

**Why this template works.** Bolt's generator is much better at executing on specifics than guessing intent. Every spec section narrows the search space. Skip a section and Bolt will fill it in with a generic choice — sometimes fine, often not what you wanted.

**Worked prompt example (paste this into Bolt as-is and you'll get a working WaitlistPro skeleton):**

``` Build WaitlistPro — a waitlist landing page builder for B2B SaaS founders. Stack: Next.js 16 App Router, Tailwind, shadcn/ui, TypeScript, Supabase (DB + Auth via email magic link), Stripe Checkout for payments. Users (Founder): logs in, creates waitlist, shares link, sees signups, exports CSV. Users (Subscriber): visits public waitlist URL, enters email, gets confirmation. Schema: users(id, email, name, created_at), waitlists(id, user_id, slug, title, description, fields_json, created_at), signups(id, waitlist_id, email, name, custom_data_json, created_at). Routes: / (marketing landing), /signup, /login, /dashboard, /dashboard/new, /dashboard/[id], /[slug]. Pricing: Free (1 waitlist, 100 signups), Pro $19/mo (unlimited waitlists, 10k signups, custom branding, CSV export). Visual: modern minimal, dark mode default with light toggle, bold typography, lots of whitespace, social proof block. Return a working scaffold. Don't bother with email sending or analytics in v1 — placeholder OK. ```

Bolt produces an initial scaffold in ~30-90 seconds. Don't accept it as final — the first version is the starting point. Bolt's edit-in-place flow lets you iterate on specific files or behaviors without regenerating everything.

**The iteration loop:** click a file in the file tree, click the AI chat panel, describe the change you want. Bolt diffs the file, you accept or reject. The diff UX is much better than 'paste your code, get a new version' — you see exactly what changed.

**High-leverage iteration prompts (after the initial scaffold):**

- 'The dashboard's empty state is too sparse. Add a welcome banner with a CTA to create the first waitlist.'

- 'The /[slug] public page needs to show the social proof block from the landing page — extract it into a shared component.'

- 'Add Zod validation to the create-waitlist form. Show inline errors. Disable submit until valid.'

- 'The signups table on /dashboard/[id] should support sorting by signup date and email search.'

- 'Add a confirmation toast (using shadcn/sonner) when a signup is successfully added.'

Each of these is a 5-30k token operation — Pro tier covers 100+ of them.

**What NOT to iterate via prompts:** styling tweaks that are 'change this color' or 'make this 4px bigger.' Faster to edit the Tailwind class directly in the file. Bolt's prompt-based iteration shines for behavior changes, not cosmetic ones.

**Iteration discipline rule:** if Bolt produces output that's worse than what was there before, REJECT and try a different prompt. Don't accept-then-fix. Accepting a regression and trying to patch it forward burns tokens and produces inconsistent code. Iteration on Bolt is 'reject early, prompt better.'

Bolt has first-class Supabase integration. The flow: in the Bolt project sidebar, click 'Integrations' → 'Supabase' → 'Connect'. Bolt OAuth's to your Supabase account, lets you pick a project (or create one), and auto-injects the connection env vars (`NEXT_PUBLIC_SUPABASE_URL`, `SUPABASE_ANON_KEY`, `SUPABASE_SERVICE_ROLE_KEY`).

**What auto-wires:** the Supabase client (`lib/supabase.ts` or equivalent), auth helpers, and the database schema if you generated SQL in your spec prompt. If you didn't, you can prompt Bolt: 'Generate the Supabase SQL migration for the schema in the spec — users, waitlists, signups tables with the relationships and RLS policies.'

**RLS policies — the step that's easy to forget.** Supabase's row-level security must be enabled for production safety. Prompt Bolt: 'Add Supabase RLS policies: users can only read/write their own waitlists. Signups are publicly insertable (anyone can sign up) but only readable by the waitlist owner.' Without RLS, anyone with the service role key can read all data — fine for dev, catastrophic for prod.

**Auth UI integration.** Bolt's scaffold typically uses Supabase's email magic-link flow. Test it by signing up with your real email; Supabase sends the magic-link email; clicking the link should land you on /dashboard authenticated. If the redirect doesn't work, the issue is usually that Supabase's allowed-redirect-URL list doesn't include Bolt's preview URL. Add it in Supabase dashboard → Authentication → URL Configuration.

**Migration discipline.** As you iterate, your schema may evolve. Don't keep regenerating the SQL file — that breaks Supabase migrations. Instead, write incremental migration files: `supabase/migrations/20260621_initial.sql`, `supabase/migrations/20260622_add_signups_index.sql`, etc. Bolt understands this convention when you prompt 'add a new migration to add an index on signups.created_at.'

Same flow as Supabase: Integrations → Stripe → Connect. Bolt OAuths to your Stripe account (use test mode for development), injects env vars (`STRIPE_SECRET_KEY`, `NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY`, `STRIPE_WEBHOOK_SECRET`).

**What auto-wires:** the Stripe Checkout helper (`lib/stripe.ts`), a checkout-session API route (`app/api/checkout/route.ts`), a webhook handler for `customer.subscription.created` and related events (`app/api/webhooks/stripe/route.ts`), and a /pricing page if your spec mentioned tiers.

**The two things you have to set up in Stripe manually.** (1) Create Products and Prices in the Stripe dashboard matching your tiers — 'Pro' product with a $19/mo recurring Price. Copy the Price ID and add it to your Bolt env vars as `STRIPE_PRO_PRICE_ID`. (2) Add your Bolt preview URL to Stripe's allowed redirect domains so Checkout success/cancel pages don't get blocked.

**Webhook testing locally.** Bolt's preview environment is publicly accessible, so Stripe webhooks can hit it directly — better than the typical local-dev experience that requires `stripe listen --forward-to`. The catch: every time Bolt redeploys (which happens on every meaningful change), your preview URL changes. The pragmatic workaround: update the webhook endpoint in Stripe dashboard once when you graduate to your own domain (Phase 6+), and use Stripe's test webhook fixtures for in-Bolt iteration.

**Subscription persistence.** When a user subscribes successfully, your webhook handler should update the `users` table with `stripe_customer_id`, `stripe_subscription_id`, `plan`, and `current_period_end`. Prompt Bolt: 'Update the Stripe webhook handler to persist subscription state to the users table on customer.subscription.created and customer.subscription.updated, and clear it on customer.subscription.deleted.'

**Gating features by plan.** Add a `hasPro(user)` helper that checks `plan === 'pro' && current_period_end > now`. Use it in API routes and UI to gate Pro features. Prompt: 'Add a hasPro helper in lib/billing.ts. Use it in /dashboard/new to block creating a second waitlist on the Free plan, with a CTA to upgrade.'

Bolt's deploy flow goes through Netlify (the partnership announced in 2024 and standardized in 2025). In the Bolt project, click 'Deploy' → 'Netlify' → authenticate with Netlify if first time → pick a site name → deploy.

**What auto-happens:** Netlify creates a new site, links the Bolt project as the source, deploys to a netlify.app URL (e.g., waitlistpro.netlify.app), and sets up auto-deploy on every Bolt project change. Most apps build successfully on first deploy if Bolt's scaffold is unchanged.

**Custom domain.** In the Netlify dashboard → Domain settings → Add custom domain. Add your DNS records (CNAME for subdomain, A record for apex). Netlify auto-issues a Let's Encrypt SSL cert in ~10 minutes.

**Env vars at deploy.** Bolt's integrations (Supabase, Stripe) inject env vars at preview time, but production env vars need to be set in Netlify dashboard → Site settings → Environment variables. Copy them across — don't rely on auto-sync, it sometimes drifts. For Stripe specifically, switch from test keys to live keys in production env vars; for Supabase, the keys are the same across environments.

**Build hooks for rebuilds.** Netlify exposes a build hook URL you can `curl` to trigger a rebuild. Useful for content updates that don't come through Bolt (e.g., your marketing team updates a CMS).

**Limitations of the deploy.** Bolt's deploy flow optimizes for fast iteration, not enterprise infrastructure. You don't get: preview deployments per branch, blue-green deploys, custom CDN config, advanced caching rules. For most SaaS at the 'just shipped' stage, Netlify's defaults are fine. When you outgrow them, you're in Phase 6+ (migration to own infra) territory.

Most Bolt tutorials end at 'deploy.' The honest truth: most successful Bolt apps eventually outgrow Bolt's in-browser editor. The signals you're at the graduation point: your project has 50+ files, you want CI/CD with custom checks, you need preview deploys per branch, you want to use Cursor or Claude Code or your own local AI stack for deeper work.

**The export step is one click.** In Bolt project → Settings → 'Export to GitHub' or 'Download as ZIP.' GitHub export creates a new repo with the full project; ZIP gives you a local file you can `git init` from. Either way, you walk away with a real Next.js codebase you fully own.

**Local-dev setup post-export.** Clone the repo, run `npm install`, copy your env vars from Bolt → `.env.local`, run `npm run dev`. Should run identically to Bolt's preview. If it doesn't, the usual culprit is a missing env var (Supabase keys, Stripe keys) — Bolt's preview had them injected, your local doesn't.

**Pick your IDE post-graduation.** Cursor and Copilot both work well on inherited-Bolt codebases. Cursor wins for refactor-heavy graduation work (Cursor's Composer is great at multi-file changes that the next 6 weeks of your project will need). Copilot wins if you're going to stay in VS Code and just want autocomplete. See migrate from Copilot to Cursor if you're considering the IDE switch.

**Add the things Bolt skipped.** Real CI (GitHub Actions running tests + lint on every PR), preview deploys (Vercel or Netlify per-branch), error tracking (Sentry, Highlight, or Posthog), proper logging (Axiom, Logtail, Datadog). These are non-glamorous but necessary for anything past 'I shipped a demo.'

**The Bolt-to-Vercel migration path.** If you want preview-per-PR and the broader Vercel ecosystem, the migration from Netlify is mechanical: push your repo to Vercel, set env vars, configure the build command (typically `next build`). Vercel auto-detects Next.js. The whole switch is 15 minutes; you get preview-per-PR for free.

**The 'should I have skipped Bolt and started in Cursor' question.** No — Bolt's superpower is the first 90 minutes from idea to running app. Cursor would take you 4-8 hours to reach the same demo-ready state. Use Bolt for the 0-to-MVP phase, graduate to Cursor/Copilot for the MVP-to-1000-users phase. Different tools for different phases.

We built this exact spec in 90 minutes during a Friday afternoon test. Token consumption: 380k for the initial generation + 6 iteration rounds = ~700k tokens total. Cost at Pro tier: well under the monthly 10M ceiling.

**Bolt's first-pass output:** working Next.js 16 App Router app with Supabase auth, magic-link flow, dashboard listing waitlists, create-waitlist form, public waitlist page that accepts signups. Stripe integration was scaffolded but the webhook subscription persistence wasn't quite right (had to iterate).

**Iteration round-trip examples.** Round 1 (15k tokens): 'The signup form on /[slug] is collecting email only. Add an optional name field, and support the fields_json column on waitlists to render custom fields.' Round 2 (20k tokens): 'The waitlist /dashboard/[id] view needs a CSV export button. Implement client-side CSV generation from the signups array.' Round 3 (12k tokens): 'Add a confirmation toast (shadcn/sonner) when a signup is successfully created on the public page.'

**Deploy step:** ~5 minutes from clicking Deploy → Netlify to having a live `waitlistpro.netlify.app` URL with auth, payments, and database working.

**Total time to demo-ready SaaS:** ~90 minutes (60 min on prompt + iteration, 15 min on Supabase setup verification, 10 min on Stripe product setup, 5 min on deploy).

Spec shape: 'Build TagTab — an invoicing app for freelancers that auto-categorizes expenses using AI. Upload a receipt, AI tags it (Travel, Software, Food, etc.), generates an invoice line. Tier: Free 5 receipts/mo, Pro $29/mo unlimited.'

**Stack added beyond WaitlistPro template:** OpenAI API for receipt categorization (Bolt scaffolded the OpenAI client; we provided the API key via env var), file upload to Supabase Storage, PDF generation for invoices (Bolt picked react-pdf).

**Tricky parts:**

1. **Receipt OCR.** Bolt's first pass used OpenAI Vision (gpt-5-mini with image input). Worked surprisingly well for clean receipts; failed on crumpled photos. Mitigation: prompt 'Add a manual-tag-override UI when AI confidence is below 80%.'

2. **Invoice PDF generation.** react-pdf renders on the client by default; large invoices were slow. Iterated to: 'Move PDF generation to a Vercel/Netlify function so it renders server-side and downloads as a stream.'

3. **Stripe metered billing for the free-tier receipt count.** Standard Stripe Checkout doesn't handle 'usage-based' well; we added a custom upgrade prompt in-app when the user hit 5 receipts.

**Token consumption:** ~1.2M tokens total for the build (richer scaffolding + 9 iteration rounds). Still well within Pro tier's 10M monthly budget.

**Time to demo-ready:** ~3 hours, mostly because of the OCR debugging.

Spec shape: 'Build PromptMarket — a marketplace where AI prompt engineers sell prompt packs. Sellers create packs (name, description, prompts JSON, price). Buyers browse, buy via Stripe, download. 30% platform fee.'

**Why this is harder than WaitlistPro or TagTab:** two user types (seller + buyer) with distinct flows, money flow between them (Stripe Connect for sellers, not just Stripe Checkout for the platform), discovery UI (browse, search, filter packs), and digital delivery (license keys or download links).

**Bolt handled the scaffolding well.** First-pass: working seller dashboard (create pack, see sales), public marketplace listing, Stripe Connect onboarding for sellers, Stripe Checkout for buyers, license-key generation on purchase, downloads UI for buyers.

**Where iteration was needed:**

1. **Stripe Connect express vs standard.** Bolt defaulted to Connect Standard (sellers create their own Stripe accounts); we iterated to Connect Express (we manage the account onboarding flow) for a smoother seller UX. Token cost: ~30k.

2. **Search and filter.** Bolt's first pass was a list view; iterated to add category filtering + price range filtering + full-text search via Supabase pg_trgm. Token cost: ~40k.

3. **License key delivery.** Bolt generated random keys but didn't gate downloads on them — buyers could share keys. Iterated to add server-side download authorization. Token cost: ~25k.

**Token consumption:** ~1.8M for the build (most complex of the three).

**Time to demo-ready:** ~5 hours. The marketplace pattern is genuinely harder than the SaaS pattern; Bolt handles it well but you're closer to the edge of what one-prompt scaffolding can do.

**Mistake 1: vague spec prompts.** 'Build me a SaaS for managing client relationships' produces a generic CRM clone. 'Build SmallBizCRM for solo consultants tracking <50 client relationships, with note-taking, last-contact tracking, and a weekly digest email' produces something useful. Always specify persona + scale.

**Mistake 2: iterating instead of regenerating when the foundation is wrong.** If Bolt's first scaffold is fundamentally misaligned with your intent (wrong stack, wrong data model), don't try to patch it forward. Click 'Regenerate' or start a new project with a refined prompt. Forward-patching burns 5-10x more tokens than restarting.

**Mistake 3: skipping the Supabase RLS step.** Bolt scaffolds without RLS by default. Anyone with the service role key can read all data. For production, RLS is non-negotiable. Always prompt 'add RLS policies' as an explicit step.

**Mistake 4: deploying with test Stripe keys.** The Netlify production env vars default to whatever was in your Bolt preview — usually Stripe test keys. Switching to live keys is a manual step you have to remember. Otherwise your production app accepts test cards and never charges real customers.

**Mistake 5: trying to do too much in one prompt.** 'Add OAuth via Google + Twitter, and add billing, and add team collaboration, and add a Slack bot' is too much for one iteration. Each major feature should be its own iteration round. Bolt's output quality drops when you ask for 5+ unrelated changes in one prompt.

**Mistake 6: not committing your work locally.** Bolt's project storage is good but not infallible. Export to GitHub at the end of every meaningful work session. Treat Bolt as the editor, GitHub as the source of truth.