Vibe Coding in Production: AI-Generated Code, EU Sovereignty, and the Stack That Actually Holds

Table of Contents

• What is Vibe Coding? (Definition in 30 seconds)
• In 30 seconds
• The typical vibe-coded stack
• What the data shows in 2026
  • 50% of code has security flaws (Cobalt AI 2025)
  • 69 vulnerabilities in 15 apps (Tenzai 2025)
  • The Enrichlead case (Q4 2025)
  • CVE tracking by Georgia Tech
• Why vibe coding ≠ production-ready
  • 1. Security
  • 2. Tests
  • 3. Dependencies
  • 4. Architectural inconsistency
  • 5. Observability
  • 6. Backup and recovery
  • 7. Cost
• The five pillars of production-readiness
  • Pillar 1: Code review with system
  • Pillar 2: Patch and dependency strategy
  • Pillar 3: CI/CD minimum
  • Pillar 4: Observability
  • Pillar 5: Architectural consolidation
• The EU-sovereign stack reframe
  • Hosting: Coolify instead of Vercel
  • Backend: Self-hosted Supabase, Appwrite, or PocketBase
  • LLM layer
  • Identity: Authentik
  • Mail, storage, cache, payments
• Migration path in three phases
  • Phase 1 - Audit and hardening (2 to 4 weeks)
  • Phase 2 - Backend migration (4 to 8 weeks)
  • Phase 3 - Hosting migration (2 to 4 weeks)
• When it makes sense - and when it doesn't
• Bottom line

What is Vibe Coding? (Definition in 30 seconds)

Vibe coding refers to building software primarily with AI assistants like Cursor, Claude Code, v0, or Bolt - the human describes the goal in natural language, the model generates the code, deploys it, and the user mostly checks whether the result feels right.

The term was coined in early 2025 (Andrej Karpathy on X) and has become the dominant working mode for solo founders and non-technical teams in 2026. Six core characteristics:

• Specification emerges in the prompt thread
• Architecture is suggested by the model, not decided
• Tests are generated more often than they're run
• Dependencies the model names are installed without scrutiny
• Result: a prototype, not a product

What follows is the practical guide to turning that prototype into resilient production software - and why the typical US stack becomes a problem along the way.

In 30 seconds

• AI-generated software is a prototype, not a product. What works, runs. What breaks, breaks silently.
• 24.7% to 50% of vibe-coded code contains exploitable security vulnerabilities (Cobalt AI 2025, Tenzai 2025).
• The default stack (Vercel + Supabase + OpenAI) is fast - but expensive past the first real customer and tricky under GDPR.
• Five pillars make vibe-coded code production-ready: review, patches, CI/CD, observability, architecture.
• For European companies, the sovereign stack reframe is now realistic: Coolify instead of Vercel, self-hosted Supabase or Appwrite instead of managed Supabase, Mistral instead of OpenAI.
• Migration is feasible in 6 to 12 weeks, in parallel with the running app.

The typical vibe-coded stack

In May 2026, a vibe-coded MVP almost always looks the same.

A founder without deep tech background opens Cursor, Claude Code, v0, or Bolt and describes what they want to build. Within hours to days, a working application emerges. The architecture isn't decided - it's suggested. By default:

• Frontend: Next.js, deployed on Vercel
• Backend: Supabase (Postgres + Auth + Storage + Realtime)
• AI: OpenAI API directly from the frontend
• Payments: Stripe
• Email: Resend
• Auth: Supabase Auth or Clerk

It works. It's reproducible. It's impressive what's become possible in this timeframe.

It's also - and this is the uncomfortable truth - a prototype, not a product. The moment the app meets its first ten real users, starts seeing money, or has to explain itself to a German data protection officer, the problems begin. In sequence and in parallel.

What the data shows in 2026

The discussion around vibe coding is often anecdotal. The data is now unambiguous.

50% of code has security flaws (Cobalt AI 2025)

A 2025 Cobalt AI benchmark study found that more than half of AI-generated code contains at least one exploitable security flaw. Including vulnerabilities long considered fixed in conventional software development - for example, code resembling the well-known Log4Shell vulnerability (CVE-2021-44228).

69 vulnerabilities in 15 apps (Tenzai 2025)

A Tenzai study tested 15 applications built with the five most popular AI coding tools. Result:

• 69 vulnerabilities in total
• Server-side request forgery in every single app
• Zero apps with CSRF protection
• Zero apps with security headers

The study didn't test edge cases - these were all standard vulnerabilities that have been mandatory in OWASP Top 10 reviews for years.

The Enrichlead case (Q4 2025)

The most public example: a startup called Enrichlead launched a SaaS app in late 2025, built entirely with Cursor. The AI placed all auth logic in the browser frontend. Within 72 hours of launch, users discovered they could change a single value in the browser console to gain full access to all paid features. The project had to shut down entirely.

CVE tracking by Georgia Tech

Georgia Tech's Vibe Security Radar has been monitoring CVE entries directly attributed to AI-generated code since May 2025. In March 2026 alone, 35 such CVEs were logged - and the trend is rising.

Bottom line: anyone shipping unreviewed vibe-coded code to production statistically builds an exploitable application.

Why vibe coding ≠ production-ready

The gap between "compiles and does the thing" and "holds up under real load and accountability" is underrated. Here are the most common breaking points, in the order they typically hit.

1. Security

AI assistants are generous with assumptions. Vibe-coded apps regularly contain:

• Service role keys in the frontend. The Supabase service role key - which bypasses Row Level Security and can do anything - visible in the browser. The database, open to anyone who hits "View Source".
• Hallucinated RLS rules. Cursor or Claude Code generate Row-Level-Security policies that look plausible but don't hold in edge cases - for instance because auth.uid() resolves differently in server components.
• CORS wildcards. Access-Control-Allow-Origin: *, because it was "easier" during development.
• Missing rate limits, especially on OpenAI endpoints - a single aggressive bot can run the bill into five figures overnight.
• Hardcoded API keys in the repo - Cursor sessions love to copy them out of .env files into the code.

2. Tests

Tests get suggested. They rarely get run. Even when they run, they typically test trivialities, not the real business logic paths. There's no safety net before deployment.

3. Dependencies

AI assistants hallucinate packages that don't exist - or ones that exist but haven't been maintained for years. On top of that: nobody runs Renovate, nobody subscribes to security advisories, nobody checks npm audit. The app starts secure and ages insecure.

4. Architectural inconsistency

Between two Cursor sessions, the architecture can shift unnoticed. Sometimes the auth provider is named one way, sometimes another. Sometimes API routes go through server actions, sometimes REST, sometimes tRPC. The code works - but nobody can read it anymore.

5. Observability

Logs aren't structured. Errors disappear into console.error. There's no Sentry, no metrics, no alerting. When the app crashes at 3am, no one notices until the next support ticket.

6. Backup and recovery

Supabase Pro takes snapshots, but there's no point-in-time recovery, no replicas, no failover. If a migration error wipes the production database, the team has no plan.

7. Cost

The most dangerous failure mode isn't a crash - it's a cost function. Vercel charges per edge function invocation and bandwidth. Supabase charges active connections, database size, MAU, and realtime messages separately. OpenAI is token-based. Anyone who isn't actively monitoring sees the costs first on the credit card bill.

The five pillars of production-readiness

Anyone moving vibe-coded code into production doesn't need everything at once. But they need all five pillars, in this order.

Pillar 1: Code review with system

Before anything else, someone with senior experience needs to read the code. Manually. At least once, completely. What a good review checks:

• Auth paths: Who can do what, where is it checked, what happens without a token?
• Data flow: What data leaves the backend, who can see it?
• Error handling: What happens during network timeouts, Stripe webhook failures, OpenAI rate limits?
• Edge cases: Empty inputs, very large inputs, special characters, Unicode issues.

Automated tools complement the review, they don't replace it:

Tool	Purpose
Semgrep	Pattern-based security scans
CodeQL	Deeper static analysis, GitHub-integrated
Snyk / Trivy	Dependency and container scans
eslint-plugin-security	JavaScript-specific smells

In vibe-coded codebases, the first review is often the most expensive. After that it becomes routine. A diff-based review strategy with Claude Code or Cursor has proven itself in practice: don't paste full files, just have it review the PR diff against a fixed checklist.

Pillar 2: Patch and dependency strategy

Three things to establish without further discussion:

1. Renovate or Dependabot for automated dependency pull requests. Daily frequency, auto-merge for patch versions with green tests.
2. Container image scans with Trivy or Grype as a step in CI. Build fails on critical CVEs.
3. Lockfile hygiene. A package-lock.json lives in the repo, doesn't get destroyed by a stray npm install, and gets maintained consistently on merge.

In addition: subscribe to security advisories for the frameworks in use (Next.js, Supabase, etc.) or route them via a Slack bot into a channel. Zero-days in Next.js are real and affect every standard vibe-coded app.

Pillar 3: CI/CD minimum

The minimum pipeline state from which production operation is responsible:

lint → typecheck → unit tests → integration tests
       → build → security scan → preview deploy → smoke tests
       → manual approval → production deploy → health check

Concretely:

• Linting and typechecking prevent the obvious typos.
• Tests don't need 100% coverage but need to exercise every path to the database, payment, and the LLM at least once.
• Preview deployments for every pull request - not "merge to staging", but a dedicated preview per branch.
• Manual approval before production. Anyone without it eventually deploys without realizing.
• Health check after deploy - if the /health route doesn't respond, automatic rollback.

Pillar 4: Observability

Three layers, all mandatory:

1. Structured logs. JSON logs with trace IDs. Once you have it, you don't go back.
2. Error tracking. Sentry is the standard, self-hosted is possible. Every production error lands in the dashboard with stack trace and user context.
3. Metrics and alerting. Prometheus + Grafana + Alertmanager as a stack. CloudWatch only when AWS is unavoidable. At minimum four alerts: 5xx rate, latency, database connection pool, disk usage.

Without observability, you're not in production - you're in hope.

Pillar 5: Architectural consolidation

The most invisible pillar, but the most expensive long term. Vibe-coded code grows polymorphically: three auth patterns, four data access styles, two UI component libraries side by side. That works for a while. Then every bugfix becomes detective work.

Consolidation means: block out time once a quarter, pick three patterns (one per layer), and move the rest into those patterns over the course of the next features. Architecture Decision Records (ADRs) document what was decided and why - so the next Cursor session respects them.

The EU-sovereign stack reframe

Up to here, this is hosting-agnostic. Now comes the part most posts on this topic skip: where does this actually run?

The default vibe stack is optimized for speed, not sovereignty. Vercel sits in California, Supabase in the US with AWS backbone, OpenAI in the US, Resend in the US. Every single data flow crosses the Atlantic. The CLOUD Act and FISA 702 give US authorities access to data - even when physically stored in the EU - without judicial review in the EU and without notifying affected parties. Schrems II hasn't invalidated this; it has shifted the risk onto the data processor.

For companies with GDPR obligations, with public sector or healthcare clients, or with investors asking now about European sovereignty: the parallel stack exists. It's not "less convenience" anymore. It's different convenience.

Layer	US Default	EU-Sovereign	Note
Hosting	Vercel	Coolify on Hetzner / IONOS / OVH	Git push deploys, comparable DX
Backend	Supabase	Self-hosted Supabase / Appwrite / PocketBase	Full Postgres + Auth + Storage
LLM	OpenAI	Mistral / OVHcloud AI Endpoints / Self-hosted vLLM	EU-only, DPA available
Auth	Auth0 / Clerk	Authentik / Keycloak	Self-hosted, OIDC + SAML
Email	Resend	Postmark EU / Self-hosted Listmonk	GDPR DPA
Payments	Stripe	Stripe (EU entity) / Mollie	Stripe with EU entity is acceptable
Cache/Queue	Vercel KV / Upstash US	Self-hosted Redis / Upstash EU
Object Storage	Supabase Storage / S3	Hetzner Storage Box / OVH Object Storage / MinIO	S3-compatible

Hosting: Coolify instead of Vercel

Coolify is the most honest Vercel replacement. Open source, self-hostable on a Hetzner Cloud server starting at €5/month. Git push deploys, preview branches, automatic TLS certificates, Docker-based build system.

What Coolify doesn't offer: Vercel's global edge network. For 95% of vibe-coded apps, that doesn't matter. For apps with truly global traffic, Cloudflare or bunny.net can sit in front.

Realistic cost difference for a mid-sized app: Vercel €3,000-8,000/month vs. Coolify on Hetzner Cloud €80-250/month, plus an hour of setup per week. That's a 70-98% reduction with comparable developer experience.

Detailed comparison coming in the cluster post: Coolify as an EU alternative to Vercel.

Backend: Self-hosted Supabase, Appwrite, or PocketBase

Three paths, depending on maturity:

• Self-hosted Supabase. Full feature parity with the hosted version, runs as a Docker Compose stack. Effort: 1-2 days of setup once, then 2-4 hours of maintenance per month. Sensible when the app is already deeply tied to Supabase and you want to avoid migration. Hetzner has an official community guide for Coolify + self-hosted Supabase.
• Appwrite. BaaS from Berlin (a German GmbH). Similar DX to Supabase, with its own Postgres backing it, its own auth implementation. Significantly more performant per Hetzner euro in benchmarks: on a €5 server in tests, Appwrite handled up to 2,000 daily users while Supabase struggled under heavier load.
• PocketBase. Single-binary BaaS, a Go executable with embedded SQLite. Ideal for solo founders or small apps. Doesn't scale to arbitrary heights, but for 95% of vibe-coded MVPs it's enough and easy to operate.

Detailed comparisons coming in the cluster posts: Appwrite vs. Supabase and Self-hosted Supabase on Hetzner.

LLM layer

For those who need to leave OpenAI for GDPR or sovereignty reasons, 2026 finally offers serious alternatives:

• Mistral (France) for general chat and reasoning tasks. API pricing comparable to GPT-4 levels, DPA available, data stays in Europe.
• OVHcloud AI Endpoints for Llama, Mistral, Qwen, etc., hosted in France.
• Self-hosted vLLM or Ollama on a GPU machine. Higher operational effort, but fully sovereign and dramatically cheaper at sufficient volume.

For many apps, a hybrid strategy makes sense: sensitive data goes to Mistral, generic helpers to the cheapest API.

Identity: Authentik

Authentik is open source, self-hostable, supports OIDC, SAML, MFA, and social logins, and ships with an admin UI that doesn't look like 2009. Migration from Supabase Auth is possible (export user data, transfer hashes or trigger a reset flow).

If Authentik is too much, Keycloak is the established alternative. For most vibe-coded apps, though, Authentik is more modern and leaner.

Mail, storage, cache, payments

Detail questions, quickly settled:

• Email: Postmark has an EU endpoint with DPA. Self-hosted Listmonk for newsletters. Resend announced an EU endpoint in 2025 - as of 2026 not yet production-ready.
• Object storage: Hetzner Storage Box (cheap, simple) or self-hosted MinIO (S3-compatible, fully controlled). Both work with any aws-sdk-compatible code.
• Cache/queue: Self-hosted Redis is trivial. For queues, BullMQ works without an additional third-party system.
• Payments: Stripe with EU entity is an acceptable default. Mollie is the Dutch alternative with identical DX.

Migration path in three phases

The most common fear: "We have to rebuild everything at once." You don't. Three phases, runnable in parallel.

Phase 1 - Audit and hardening (2 to 4 weeks)

Here the existing stack gets fixed without changing it. Concrete steps:

1. Audit against the five pillars - what's missing entirely, what's halfway there?
2. Remove service role keys from frontend bundles.
3. Verify RLS policies and write them manually (don't let them be generated).
4. Activate Renovate, update critical dependencies.
5. Set up Sentry or equivalent.
6. One smoke test per user flow.

Result: the app runs more securely without anything having been migrated.

Phase 2 - Backend migration (4 to 8 weeks)

This is the biggest step. Options:

• Supabase → self-hosted Supabase: least code effort, highest operational effort. Migrate the database via pg_dump/pg_restore, export and re-import auth users, copy storage buckets via script.
• Supabase → Appwrite: more code changes, less operational effort. Auth layer rebuilt entirely, database migrations via Appwrite CLI.
• Supabase → PocketBase: for smaller apps, biggest architectural cut. Recommended only for MVPs under 10,000 users.

During the migration, old and new backend instances run in parallel, with the frontend build switched via feature flag.

Phase 3 - Hosting migration (2 to 4 weeks)

The simplest phase, because the app itself barely changes.

1. Provision a Coolify server at Hetzner / OVH (Hetzner CCX23 is a good default).
2. Configure domains in parallel (a subdomain for the Coolify build, then DNS cutover).
3. Set up the build pipeline in Coolify (GitHub integration, auto deploy).
4. Certificates via Caddy/Let's Encrypt.
5. Cutover via DNS TTL reduction and gradual traffic shift.

Realistically, the app is fully on Coolify after 2 weeks, with Vercel as emergency rollback for another 4 weeks.

Detailed walkthrough coming in the cluster post: Migrating a vibe-coded app from Vercel to Coolify.

When it makes sense - and when it doesn't

Honest list, because advisory doesn't mean recommending everything.

Makes sense when:

• The first paying customer is here or coming in the next few months.
• A Series A is being prepared, tech due diligence on the horizon.
• Cloud costs have hit a four-figure monthly bill.
• GDPR inquiries are coming, DPAs being requested.
• The industry is healthcare, finance, public sector, education, legal.
• The team is growing - new devs need to understand the code.

Doesn't make sense when:

• The app is still in validation, no product-market fit.
• Cloud costs are below €200/month.
• Solo founder without near-term compliance requirements.
• The app might be discarded in 6 months.

In those cases, the default stack is the right choice - time-to-market beats architectural purity. Migration can come later, with a plan.

Bottom line

Vibe coding has changed time-to-market dramatically. What it hasn't changed: the requirements for production operation. Anyone shipping a vibe-coded app to market quickly has a product - but rarely one that scales without hardening. The data is unambiguous: 50% security flaws on average, 69 of 69 possible vulnerabilities in 15 tested apps - that's not residual risk, that's the default.

The five pillars - review, patches, CI/CD, observability, architecture - aren't negotiable. What's negotiable is the hosting underneath. For companies in Europe, with compliance requirements and an eye on cloud costs, the sovereign stack reframe is no longer a fringe idea in 2026. Coolify has nearly reached Vercel's DX. Appwrite and self-hosted Supabase deliver the backend layer. Mistral and OVHcloud close the LLM gap.

Anyone hesitating because of "everything at once" hasn't seen the migration path yet. In 6 to 12 weeks, the parallel world is up, the old system is the backup, and monthly costs are often cut in half.

If you're considering whether your vibe-coded MVP should make this step now - or not yet - a triage call is the simplest next step. 15 minutes, free, an honest assessment. If you have tech due diligence on the horizon or are weighing a fractional CTO, the call doubly pays off.