SaaS Builder builds your first SaaS for you. You describe the product you want, our team builds it to a Blueprint you approve, and it is written into your own repository, backed by your own database and deployed to your own hosting account.

The important consequence: you own the result. The code lives in your Git provider, the data lives in your database, and the running application lives on your hosting account. If you stop using SaaS Builder, all of that stays exactly where it is.

• Create an account at saas-builder.com/signup.
• Answer the onboarding questions about your idea, your customer and what the product must do.
• Read your Blueprint. It is generated from your answers before you pay anything.
• Start your build with a single payment, then connect the accounts that will own your SaaS.
• Follow the build, review previews, use your revision round, and receive the handover.

Connections are managed on the Stack page inside the app, and only after payment. A provider this deployment is not configured for says so plainly instead of offering a button that cannot work.

Connecting Vercel lets SaaS Builder create a Vercel project for a generated application, deploy previews of it, promote a reviewed preview to production, and keep the project's environment variables in sync with the rest of the stack.

You choose the scope during installation: a personal account or a specific team. SaaS Builder acts only within the scope you picked. All calls are made from our servers; a Vercel access token is never sent to a browser.

What the integration does

• Reads your Vercel projects, so a SaaS Builder project can be linked to the right one.
• Creates a Vercel project for a generated application, when you ask it to.
• Creates preview deployments from the repository the project is linked to.
• Reads deployment status, so the app can show whether a build succeeded.
• Promotes a deployment you have reviewed to production. Vercel does not rebuild on promote, so what ships is the build you looked at.
• Writes the environment variables a generated application needs in order to run.

What it never does

• Read environment variable values back out of your Vercel projects. Values are written, never retrieved.
• Touch projects that are not linked to one of your SaaS Builder projects.
• Act on an account or team other than the one you selected at install time.
• Delete a project or a deployment.

Start from the Connections page in SaaS Builder and choose Connect Vercel. Vercel asks which account or team to install on, and returns you to SaaS Builder once you confirm. The connection is recorded only after a real call to the Vercel API succeeds, so a connection shown as ready has been proven to work.

Test connection re-checks it live at any time and records the result. To remove access, choose Disconnect. That deletes our stored credential immediately. You can also remove the integration from your Vercel dashboard, which revokes it on Vercel's side. Nothing in your Vercel account, including projects and deployments, is deleted when you disconnect.

GitHub. SaaS Builder uses a GitHub App, not a personal access token. You choose exactly which repositories it may see, and you can audit or revoke it from GitHub at any time. No GitHub credential is stored: access tokens are minted per request, last about an hour, and never leave our servers.

Supabase. Connecting Supabase lets SaaS Builder see the organizations and projects your account can reach, so a generated application can be pointed at the right database. The authorization is stored encrypted.

There is one offer: the Launch Program. It covers one clearly defined MVP built to your approved Blueprint, one structured revision round, quality assurance, a production launch, handover and training. What it costs is shown once, at the end of onboarding, next to the Blueprint of your own product — see what you get.

• Provider credentials are encrypted with AES-256-GCM before they are written, and are readable only by the server components that need them.
• Credentials are stored in a table that no user session can reach, even with a valid session token.
• Access tokens, refresh tokens and client secrets are never sent to the browser and never written to logs.
• Every provider operation is recorded in an audit trail that stores what was done, never the credential used to do it.
• A connection is only ever displayed as connected after the backend has verified it against the provider.

More detail on what is stored and why is in the privacy policy.

Email hello@saas-builder.com.

If the app showed you an error reference in the form SB-XXXX-XXXX, include it. It identifies the exact failure on our side and contains no information about you or your accounts.