Build a SaaS App with AI Coding Tools: Real Guide

The number one mistake people make when they build a SaaS app with AI coding tools? They treat the AI as a senior developer. It isn’t. It’s a fast, confident junior contractor who has read every public GitHub repo – including the ones with passwords committed in plaintext – and will happily reproduce those patterns in your app.

That framing changes everything about how you should work. Once you stop expecting architectural judgment from the model and start treating its output the way you’d treat a pull request from a coder you’ve never met, the rest of the workflow falls into place.

The blast radius nobody warns you about

Before picking tools, look at what’s actually shipping. Veracode tested 150+ AI models and found 45% of generated code introduces OWASP Top 10 vulnerabilities, with an 86% failure rate on cross-site scripting defenses. That’s not a rounding error – it’s the baseline.

28.65 million. That’s how many new hardcoded secrets landed in public GitHub commits in 2025 – a 34% year-over-year jump, per GitGuardian’s State of Secrets Sprawl 2026. Drilling into the AI-specific numbers: commits generated with AI assistance leak secrets at 3.2% versus a 1.5% baseline for human-only commits – more than double the rate. Supabase credential leaks specifically? Up 992% in 2025.

One story makes it concrete. A SaaS founder built his entire product with Cursor, shared it publicly, and was attacked within days. Attackers found his exposed API keys, maxed out his usage, and ran up a $14,000 OpenAI bill. He shut down permanently. The UK’s National Cyber Security Centre – not a vendor, not a consultant – described AI-generated code in a March 2026 post as presenting “intolerable risks” for many organisations.

Why the standard “build it in 5 hours” advice falls apart

Speed-first tutorials have the priorities backwards. AI tools generate functional code and skip security questions entirely – so by the time you’re “hardening” your MVP, the secrets are already in your Git history and the attack surface is already public. Hardening at the end isn’t hardening. It’s archaeology.

Configure Gitleaks as a pre-commit hook on day one – before you write a single feature. It takes ten minutes and stops the most common failure mode (hardcoded credentials hitting your repo) at the only point where it’s still cheap to fix.

The stack that actually works (and why)

There’s no single “best” AI coding tool. There are tradeoffs, and the right answer depends on what part of your SaaS you’re building. Here’s how the three serious contenders stack up as of early 2026:

The benchmark that matters most, though, isn’t speed. In a head-to-head test where each tool built the same task management app, Windsurf was fastest by 25 minutes – but shipped 11 bugs and 4 security issues, including hardcoded API keys sitting in the frontend. Claude Code was the slowest. It also produced the best architecture: only 5 bugs, zero security issues, and handled a 23-file authentication migration without any human intervention.

My recommendation for a real SaaS build: use Cursor or Claude Code for backend and auth (where bugs cost you money), and reserve Windsurf or Lovable for landing pages and marketing surface (where speed wins and the blast radius is small). Don’t pick one tool. Pick the right tool per layer.

The actual workflow, step by step

Forget the generic “validate idea → build MVP → market” framework. Here’s the workflow that survives contact with reality:

1. Set up the security floor before any feature code. Install Gitleaks pre-commit hook. Add .env, .env.local, .env.production to .gitignore on your first commit. Configure GitHub secret scanning. If you’re using Supabase, enable Row Level Security on every table before adding a single row – the default is off and the AI will not enable it for you.
2. Write a project rules file. Cursor reads .cursorrules, Windsurf reads .windsurf/, Claude Code reads CLAUDE.md. Spell out: “never hardcode secrets, always use env vars, validate all webhook signatures, enable RLS on every Supabase table.” The model follows instructions you give it, not instructions you assumed it knew.
3. Build feature by feature, in branches. One feature, one branch, one PR. No “build me a SaaS app” prompts – that’s how you end up regenerating your whole codebase every iteration.
4. Run a secrets scan before every push. Gitleaks catches them at commit time; TruffleHog verifies which ones are still live. Both are free.
5. Audit the five things AI gets wrong. RLS status, secrets in code, webhook signature verification, exposed error messages, missing input sanitization. These five account for most serious findings in AI-generated apps.

A real example: where it goes wrong

Here’s a sample of what AI tools default to when you ask them to “connect Stripe to my Next.js app.” Look closely:

// pages/api/checkout.js - generated by AI on first prompt
import Stripe from 'stripe';

const stripe = new Stripe('sk_live_51Hxx...redacted...');

export default async function handler(req, res) {
 const session = await stripe.checkout.sessions.create({
 line_items: [{ price: req.body.priceId, quantity: 1 }],
 mode: 'subscription',
 success_url: `${req.headers.origin}/success`,
 });
 res.json({ url: session.url });
}

Three problems in nine lines. The Stripe secret is hardcoded – not in an env var. There’s no webhook signature verification on the corresponding webhook handler (which the AI will generate next, also unverified). And req.body.priceId is passed straight through with zero validation, meaning anyone can checkout against any price ID in your Stripe account, including the ones you set to $0.01 for testing.

The fix isn’t complicated. It’s just that the AI won’t do it unless you ask. Turns out there’s a deeper reason this keeps happening: AI coding tools hardcode credentials because that’s what “working code” looked like in their training data. And per Invicti’s research (via ToxSec’s analysis), each LLM has its own set of favorite placeholder secrets – the same JWT signing secrets, the same placeholder passwords like password123 and admin123 – appearing across different generated apps. An attacker who knows which model built your app can try those model-specific defaults before brute-forcing anything.

Pro tips from the trenches

• Don’t trust AI to audit AI. Self-audit cycles catch surface issues but consistently miss context-specific problems. Run Semgrep or SonarQube as a CI gate, not just an AI review.
• Watch the commit size. AI-assisted developers produced 3-4x more commits than non-AI peers yet generated 10x more security findings (SoftwareSeni, 2025). Larger commit volume means more concentrated risk per review – force smaller PRs.
• Pick your model per task. Use Claude Code for architecture and refactors. Use Cursor’s auto mode for autocomplete-heavy work. Don’t pay $200/month to write CSS.
• Acquisition risk is real. Windsurf was acquired by Cognition AI in 2025 after OpenAI’s $3 billion bid fell through and Google poached its CEO. Tooling consolidates fast – keep your code portable, don’t tie your build process to one vendor’s proprietary features.

FAQ

Can I really build a production SaaS with AI coding tools if I can’t read code?

No. You can build a prototype, sure. But every documented disaster – the $14K OpenAI bill, the leaked Supabase databases, the Stripe refund exploits – happened to people who couldn’t read what the AI was generating. If you can’t audit a 50-line file for hardcoded secrets, you’re not building a SaaS, you’re building a liability.

Which is better for SaaS: Cursor or Claude Code?

Both, used together. Cursor for daily editing – the autocomplete and UI scaffolding are noticeably ahead. Claude Code for anything that touches more than ten files at once: authentication flows, schema migrations, full-app refactors. Many experienced builders run Cursor open in their editor and Claude Code in a terminal pane next to it. Pricing-wise, you’re looking at $40/month combined for Pro tiers, which is less than one billable hour of a freelance developer.

What’s the single biggest config gotcha?

Supabase Row Level Security – off by default. Roughly 70% of Lovable-built apps ship that way, meaning any authenticated user can query or delete any other user’s data through a simple API call. Enable it on every table before you ship, then run the Supabase Security Advisor to verify.

Next action: open your last AI-generated project right now. In your terminal, run git log -p --all -S 'sk_' and grep -r 'sk_live|AKIA|password' src/. If anything comes up, rotate those credentials before you read another article.