Build and Launch a SaaS With Claude Code

Define the SaaS

Open your project in Claude Code, fill in the three fields, and use this prompt. It only plans — nothing is built yet.

Plan the SaaS

Tell Claude what your SaaS does, who it is for and what users should pay for before anything is built.

I want to build and launch a focused SaaS MVP with Claude Code. SaaS idea: {{SAAS_IDEA}} Target user: {{TARGET_USER}} Paid value: {{PAID_VALUE}} Do NOT build anything yet. First inspect the current project. If this is an existing project, preserve the correct stack, components and working functionality where possible. If this is a new or empty project, plan the smallest appropriate web-app architecture. The SaaS must revolve around ONE useful core user action. 1. PRODUCT What is the one primary thing the user does here? Avoid turning the first version into a feature suite. 2. PUBLIC EXPERIENCE Plan only what is needed: a landing page, a concise product explanation, pricing, and a sign up / sign in call to action. 3. AUTHENTICATED PRODUCT Plan the main dashboard or app area, the core feature, the user-specific data it requires, and an account / billing area. 4. FREE VS PAID Define the smallest understandable boundary — for example a limited or demo experience for free, and the full core feature, a higher useful limit or saved private work for paying users. Do not design a complicated credits system. 5. DATA Identify only the user data the product actually needs. 6. SUBSCRIPTION Use one paid subscription. 7. SECURITY Plan private user data, authenticated ownership, trusted billing state, and the paid feature protected at the real backend, database or server boundary where the valuable work happens. 8. PRODUCTION Plan the path: Claude Code, then GitHub, then Hostinger. CRITICAL SUBSCRIPTION RULE Do not design paid access as a value the browser can change, such as a "paid" flag in localStorage or a plan field the user can edit about themselves. Stripe is the payment authority. The trusted application or backend subscription record is the access authority. The UI reflects access; it never creates access. Return: SAAS MVP PLAN Product: Target user: Core action: Public pages: Authenticated pages: User data: Free experience: Paid experience: Subscription model: Authentication: Data ownership: Paid-access enforcement: Production architecture: Features deliberately excluded: Then return exactly one: READY TO BUILD or: NEEDS A DECISION Do not modify files yet.

What does your SaaS do?

It turns meeting notes into clear action items and lets users save the results...

Who is this SaaS for?

Freelancers, small agencies, creators, local businesses...

What should paying users unlock?

Unlimited saved projects and access to the main generation feature...

Review the plan before continuing. A strong first SaaS should do one useful thing extremely clearly.

Confirm the MVP

Make sure the approved plan includes exactly this:

One clear core feature

Authentication

Private user data where required

One paid subscription

Paid access enforced securely

Production deployment

No unnecessary SaaS features

Build the SaaS Experience

Build the landing page and the one core feature first. Accounts and billing come after.

Build the SaaS Core

Build the landing page and one useful product workflow without adding authentication or billing complexity yet.

Using the approved plan, build the core SaaS product experience. First inspect the current project. Reuse existing components and design where appropriate, and do not redesign unrelated working parts. 1. PUBLIC EXPERIENCE Build the smallest useful public experience — typically a hero, a concise value proposition, the core benefit, a product preview or demo where appropriate, a pricing call to action, and sign up / sign in. Do not turn this into a giant marketing website. Never invent testimonials, user counts, client logos or revenue numbers. 2. CORE PRODUCT Build the ONE primary SaaS feature from the approved plan, as a real product flow. Do not fill the app with dashboard cards that do nothing. If the core feature needs an external API, inspect the safest server-side architecture this project already uses and follow it. Never put a private API key in browser code. If the SaaS does not need an external AI or API, do not add one simply because Claude Code is building the app. 3. PRODUCT STATE Focus on making the core user action understandable and usable. Where persistent user data is required, prepare the UI and data boundaries cleanly for Supabase in the next step. Do not fake completed backend behaviour. 4. DESIGN Keep the app professional, clear, responsive and product-focused. Avoid a neon AI aesthetic, excessive gradients and glows, decorative dashboards and overbuilt animations. Use the existing design system where one is present. When finished, report: - the public pages and components - the authenticated-product UI you prepared - the core feature - any external API the feature needs - the data that needs persistence - the features you intentionally did not add

A landing page with sign-up and billing but nothing useful in between is not a SaaS. The core feature is the product.

Test the Core Feature

Use the product the way a customer would, and confirm:

The main user action works

The empty state makes sense

The loading state is clear where the action takes time

A failure is handled instead of breaking the screen

The experience stays usable on a phone

Fix what fails here before adding accounts. You do not need a test suite at this stage.

Add Authentication and User Data

Now give the product real accounts and private, user-specific data.

Add Supabase to the SaaS

Add user accounts and private user-specific data using the established Profit Studio Supabase patterns.

Connect the approved SaaS to Supabase. Inspect the current project first. If it already uses the intended Supabase project, reuse it — do not create a duplicate backend. Use the closest established Supabase authentication and database patterns already present in this project. 1. AUTH Add sign up, sign in, sign out and a protected SaaS app area, using the current established authentication architecture. Do not add social providers unless the project already needs them. 2. USER DATA Persist only the data the SaaS's core feature actually requires. All user-owned data must be scoped to the authenticated user: User A must not be able to read or modify User B's private records. Do not rely only on frontend filtering such as a .eq('user_id', user.id) query without database authorization behind it. Use proper RLS or the established trusted access pattern. 3. PUBLIC VS PRIVATE Keep public marketing and product information public where intended. Keep account data, saved user work, private results and subscription state private, according to the approved plan. 4. SUPABASE KEYS For normal browser usage, use the current project terminology: the Project URL and the Publishable key. Never expose a Secret or service-role key in browser code. Return: 1. Existing Supabase setup reused 2. Auth changes 3. Tables and data added 4. The RLS / data-ownership model 5. Protected routes 6. Environment-variable names 7. Any server-side requirement 8. Any blocker Do not execute destructive database changes blindly. Use this repository's established reviewed SQL and setup workflow, and warn me instead of replacing a table that already exists.

IMPORTANT

The browser only ever gets the Supabase Project URL and Publishable key. A Secret or service-role key belongs on the server, never in client code and never in the repository.

Add User Authentication to Any Website with Supabase

Use this if you want the full authentication walkthrough.

/video/add-user-authentication-supabase

Verify User Isolation

Create two test accounts and check the boundary between them for real:

Account A: create and save test data

Account B: sign in and confirm none of Account A's records are visible

Account B: try to open one of Account A's records by its id — it must be refused

Account B: try to modify one of Account A's records — it must be refused

Account A: sign back in and confirm the data is unchanged

Hidden UI is not proof of isolation. The refusal has to come from the database or the server, not from a screen that simply does not render the record.

Make Sure Users Can Only Access Their Own Data With Supabase

Use this if any of these checks fail.

/video/users-own-data-supabase

Add the Paid Subscription

One product, one recurring price, and paid access that the browser cannot grant itself.

Add Stripe Subscription Access

Connect one Stripe subscription plan and protect the paid SaaS experience using trusted subscription state.

Add ONE paid subscription to this SaaS. Before changing anything, inspect the established Stripe subscription pattern already used in this project and reuse its secure architecture. Do not invent a parallel billing system. 1. STRIPE MODEL Use ONE product and ONE recurring price for this MVP. Do not add multiple plans, an annual/monthly toggle, credits, usage billing, coupons or trials unless the approved plan absolutely requires it and it already fits the existing architecture. 2. CHECKOUT Create Stripe Checkout from a trusted server-side path. The browser must never be the authority on the Price ID, the amount, the currency, the subscription owner or the paid status. 3. CUSTOMER IDENTITY Correctly associate the Supabase authenticated user with the Stripe customer and the Stripe subscription, using the established implementation. 4. WEBHOOK Stripe webhook processing must verify the webhook signature, and subscription state must be updated from verified Stripe events. Do not treat the Checkout success redirect as proof that the user is paid. 5. SUBSCRIPTION STATE Use the established subscription lifecycle: active access, cancellation at period end, cancelled, and failed or unpaid behaviour. Do not invent complex billing logic. 6. PAID ACCESS CRITICAL: protect the paid feature where the valuable operation or data actually happens, not by hiding a button. A user must not be able to call the paid operation successfully by bypassing the UI. Reuse the established paid-feature protection approach. 7. CUSTOMER PORTAL Use the Stripe Customer Portal where the established pattern uses it, so the user can manage or cancel the subscription. Do not build a custom credit-card management UI. 8. TEST MODE Everything must work completely in Stripe Test Mode first. Going live with real payments is a later production action, not part of finishing this build. Report: 1. The Stripe product and price model 2. The checkout path 3. The Stripe customer relationship 4. The webhook path 5. How subscription state is persisted 6. How paid-feature access is enforced 7. Billing portal behaviour 8. Environment variables 9. Test-mode status 10. Any blocker

IMPORTANT

The Stripe Secret key and the webhook signing secret are server-side values only. If either one reaches browser code or the repository, roll it in Stripe before going any further.

Add Stripe Subscriptions to Any AI-Built Web App With Supabase

Use this for the full subscription walkthrough, including the webhook and the Customer Portal.

/video/add-stripe-subscriptions-supabase

Test Free and Paid Access

Run these in Stripe Test Mode, in this order:

Signed out: the paid feature is unavailable

Signed in, not subscribed: the free experience works

Signed in, not subscribed: the paid operation stays blocked

Subscribe with a Stripe test card and complete Checkout

The verified webhook updates the subscription record

The paid feature becomes available

Cancel from the billing portal and confirm the behaviour matches the subscription rules

Bypass test: calling the paid operation directly as an unpaid user is still refused

The last check is the one that matters. If an unpaid account can reach the paid operation without the button, the plan is decorative.

Run the Full SaaS Journey

Walk the whole product once, as a new customer would, still in Stripe Test Mode:

Visitor: open the landing page and sign up

User: use the free or initial product experience

User: create and save test data

Billing: open pricing or upgrade and start Stripe Test Checkout

Billing: complete the test subscription

App: paid access appears and the paid core feature works

Account: open billing management and confirm the subscription state

Second user: sign in with another test account and confirm the first user's records stay inaccessible

Verify the SaaS

Run a focused pre-launch check before anything goes to production.

Verify the SaaS Before Launch

Verify authentication, private user data, Stripe billing and paid access before production deployment.

Perform a focused pre-launch verification of this SaaS. Do not add new features. 1. AUTH Verify signup, sign in, sign out, the protected app route, and what happens with an invalid or expired session. 2. USER DATA With two users, verify that private records stay isolated, that guessed or direct record access is blocked, and that ownership is enforced in the backend or database rather than in the UI. 3. CORE FEATURE Verify that the primary user action succeeds, that the expected data persists, and that the failure state behaves correctly. 4. STRIPE In Test Mode, verify that checkout uses trusted price configuration, that the webhook signature is verified, that a successful Checkout redirect alone does not create paid access, that a verified subscription does produce access, and that subscription state stays correct after a refresh and a re-login. 5. PAID ACCESS Verify that an unsubscribed user cannot call the paid operation directly, that a subscribed user can, and that client-side state is not the security boundary. 6. SECRETS Confirm no private credentials are exposed client-side: the Stripe Secret key, the Stripe webhook secret, the Supabase Secret or service-role credential, and any private third-party API key. Return exactly one: SAAS READY FOR DEPLOYMENT or: NEEDS ATTENTION If NEEDS ATTENTION, list only the issues that block this SaaS from being safely deployed. Do not perform a broad unrelated engineering audit.

Complete one final signup → subscription → paid-feature test before deploying.

Deploy the SaaS

Before pushing to GitHub, check:

The project builds successfully

No .env or other secret files are being published

No Stripe Secret key, webhook secret or Supabase service-role credential is in browser code

You know the production environment variable names

You know which production callback and webhook URLs will be needed

Push the project to GitHub with Claude Code or your normal GitHub workflow. If the SaaS already has a repository, use it.

Deploy on Hostinger

Recommended plan: Business

USED IN TUTORIAL

https://www.hostg.xyz/SHK1P

Hostinger Websites Add Website Node.js Web App

Choose Import Git repository Connect GitHub and select the SaaS repository Review the detected framework and build settings Add the environment variables with your project's exact names Click Deploy and wait for the result

IMPORTANT

Keep public client configuration and private server secrets separate, under the names the project already uses. Never rename a private key to a VITE_ or NEXT_PUBLIC_ variable to make a deployment work.

Fix a Failed Website or Web App Deployment With AI

Use this if the Hostinger deployment fails.

/video/fix-a-failed-website-or-web-app-deployment-with-ai

Verify the Live SaaS

Once the live URL exists, point Supabase at it so sign-in works in production:

Supabase Authentication URL Configuration

Set the Site URL to your live URL and add it to the Redirect URLs. Then update Stripe for production: the app URL it returns customers to, and the webhook destination pointing at the deployed backend endpoint this project actually uses. Keep Test Mode and Live Mode clearly apart — the tutorial is complete in Test Mode, and switching to live keys is a separate decision. Then open the live app and check:

Public: the landing page loads and production routing works

Auth: create a production test account and sign in

Product: the core feature works and the data persists

Billing: Checkout opens and the webhook reaches the production endpoint

Billing: a verified subscription unlocks paid access

Billing: the billing portal opens where it is configured

Security: an unpaid account still cannot reach the paid operation

Security: a second account cannot see the first account's private data

Mobile: landing, signup, the core product and upgrade all work on a phone

Verify the Live SaaS

Test the complete production app from account creation through billing and paid access on Hostinger.

Perform a focused production verification of this SaaS. Do not add features. 1. GITHUB Verify that the intended source is current and that no secret files are committed. 2. HOSTINGER Verify that the correct repository and branch are connected, that the deployment succeeded, that the build and runtime configuration are correct, and that the required environment variables exist. 3. PUBLIC SITE Verify that the landing page loads, that production routing works, and that the signup and sign-in links work. 4. SUPABASE Verify that the production app connects to the intended project, that signup and sign-in work, that the redirect URLs are correct, and that private user data stays isolated. 5. CORE SAAS FEATURE Verify that the main user action works in production and that the required persistence works. 6. STRIPE Using the mode this app is currently in, verify that Checkout opens correctly, that the webhook reaches the production endpoint, that a verified subscription changes access, and that the billing portal works where it is configured. If the app is still in Test Mode, say so clearly — do not call the app real-payment-live merely because Test Mode works. 7. PAID ACCESS Verify that an unpaid user stays blocked from the paid operation, that a paid test or live user receives access, and that a direct unauthorized request cannot bypass it. 8. SECURITY Confirm that the production browser code exposes no Stripe secret, no webhook secret, no Supabase Secret or service-role key and no private third-party API credential. 9. RESPONSIVE Verify the critical flows on mobile: the landing page, signup and sign in, the core product, and pricing or upgrade. Return exactly one: SAAS LIVE or: NEEDS ATTENTION Use SAAS LIVE only when the deployed product workflow is functioning correctly. If the product is still using Stripe Test Mode, keep that verdict word but say "SAAS LIVE — STRIPE TEST MODE" in the summary line, so nobody reads it as accepting real payments. If NEEDS ATTENTION, list only production blockers.

Create one final production test user, complete the intended subscription test and verify paid access before sharing the app publicly.