Ship Fast, Stay Safe: AI Prototyping That Survives Production

From vibe-coded demo to production-grade — the discipline in between. Based on the Supabase webinar featuring Zimo (Brthrs Agency), Harry (Imaginary Space), and Victor (Performanze).

There's a gif that Zimo from Brthrs Agency opened his demo with. A train, running at full speed — but not on tracks. Just barrelling across open ground, functional and chaotic. That's what most vibe-coded prototypes look like after six weeks in production.

The AI build wave is real. Timelines that once meant six months and a proper engineering team now mean an afternoon and a Lovable account. That's not hype — it's the operating reality for the agencies, founders, and CTOs on this webinar. But speed without architecture is just expensive debt that compounds quietly until something breaks in front of a customer.

The same pattern shows up in AI-powered customer service. Deploying Fin or any AI agent on top of a fragmented knowledge base produces the same result — fast start, early plateau, growing frustration. The tools are different. The failure mode is identical.

Here's what the people actually shipping production AI systems are doing differently.

The 80/20 Rule Nobody Talks About

Zimo's framing was blunt: "I spend 80% of my time planning. The remaining time implementing."

That's the inverse of how most founders approach AI tooling. They open Lovable, type a feature request, and accept the output. The result is what he calls "average intelligence" — the model pattern-matches against its training data and gives you the most generic version of what you asked for.

The unlock is context engineering, not prompting skill. The distinction matters. Prompting is about phrasing. Context engineering is about loading the AI with the right environment — user intent, technical documentation, business constraints — before it touches a single line of code.

His specific workflow: pull the relevant Supabase documentation before planning, have the model research the right implementation approach, generate a structured plan, then run a second pass by telling it "you're a junior engineer tasked with implementing this plan — review the documentation and bring back every question you have." That loop catches architectural problems before they become production problems.

The key insight: documentation is context. Supabase's docs are human-readable, but they're also AI-readable. Feeding them into the planning phase means the output reflects actual best practices, not statistical averages.

"Slow is smooth, smooth is fast. It takes a long time to think about what you actually want to build — but if you give all of that as context to the AI, you can go really quickly into implementation."

Lovable has since made this the default. Plan Mode (February 2026) shows you a structured build plan before any code is generated. Chat Mode (June 2026) goes further — you start every new project in a planning conversation, and Lovable asks clarifying questions about your target audience, features, and technical requirements before touching a line of code. The AI mistakes that waste the most credits almost always trace back to a vague prompt. The tool now nudges you to fix that upfront.

The projects that stall are almost always the ones that skipped the planning step. Lovable has now built that friction in by design.

Security Isn't a Later Problem

Every panelist circled back to this independently: security work done after launch is ten times harder than security built into the plan.

We now have a documented case study of exactly what happens when it isn't. CVE-2025-48757, disclosed in mid-2025, exposed more than 170 production Lovable apps due to missing Row Level Security policies. The Supabase anon key is embedded in client-side JavaScript by design — without RLS, anyone who opens browser DevTools can query your entire database directly. Emails, payment records, API keys, personal data — all accessible without authentication. A Q1 2026 assessment of over 200 vibe-coded apps found 91.5% contained at least one vulnerability traceable to AI-generated code. "The S in vibe coding stands for security" became the joke on every developer forum. The incident isn't an argument against using Lovable — it's an argument for treating the security checklist as non-negotiable before any app touches real users.

The OWASP Top 10 remains the baseline reference. Before AI tooling, 80% of applications shipped with some form of role-based access control vulnerability. That number hasn't improved with AI — it's gotten harder to spot because the code looks correct until someone queries it adversarially.

Three things that came up repeatedly:

RLS policies are your last line of defense. Supabase's Row Level Security isn't a nice-to-have — it's the mechanism that stops your AI agent from accidentally returning customer data it shouldn't have access to. Lovable sets up basic RLS policies automatically, but you need to review and tighten them before going live. It's much easier to change policies before real data exists.

Never store secrets in frontend code. This one is basic but catches more vibe-coded projects than any other issue. API keys, Stripe secrets, anything sensitive — it belongs in server functions, not in your React components where any browser inspector can read it. Secrets in frontend code should be considered compromised.

Prompt injection is an AI-specific attack vector most people miss. If you're building a chatbot or AI interface — whether in a Lovable app or a Fin deployment — actively try to break it. Find lists of adversarial prompts, paste them in, and watch what your AI returns. The question isn't just whether your database is secure — it's whether your AI can be manipulated into surfacing data or taking actions it shouldn't.

"It's not that vibe coding is inherently insecure. It's about having the muscle to remember to check — and not just vibe code and forget about security."

AI-assisted security reviews are now accessible enough that there's no excuse to skip them. Lovable now runs a basic security scan automatically on every publish — covering RLS policies, database configs, and known misconfigurations in about 10–15 seconds. A deep scan is available on demand, analyzing your full codebase in roughly 3 minutes. Workspace admins on Business and Enterprise plans can block publishing on critical findings entirely. Supabase's Security Advisor surfaces database-level issues directly in the dashboard. None of these replace penetration testing for serious production systems — but they've raised the floor substantially since the CVE.

The Selfware Shift

Victor's framing from Performanze introduced a concept worth sitting with: selfware — software built around a company's own workflows, data, and operations instead of adapted from generic SaaS.

The pitch to clients is straightforward. You're using one menu in Salesforce. You're paying for the full product, locked into their roadmap, locked out of features they reserve for enterprise tiers. With the current AI build environment, there's a viable alternative: own your stack, own your data, own the roadmap.

The objection writes itself — you can't replace Salesforce. Victor agrees. That's not the claim. The claim is that for a growing number of workflows, the cost-benefit has shifted. You're not buying a Salesforce competitor. You're buying a tool that does exactly what your business does, with your data in Supabase, extensible on your timeline.

His example: a human resources platform with configurable AI-powered assessments, built as a complete alternative to a generic enterprise copilot, with SharePoint and Outlook context baked in. The client's data stays in PostgreSQL tables they control. Features ship in weeks. No license escalation.

The infrastructure choice is central to this model. Everything consolidated in Supabase — structured data in PostgreSQL, embeddings in the vector store, files in storage buckets, auth out of the box. The consolidation isn't aesthetic preference. It's what makes text-to-SQL queries and RAG retrieval actually work consistently.

"The AI is a mirror to ourselves. If you input great context, you're going to have great results. If you input poor context, it's going to tend to average — or below average."

The same logic applies to AI agents in customer service. Fin's resolution rate isn't determined by how you configure it on day one — it's determined by the quality and structure of the knowledge base underneath it. The content architecture has to come before the AI configuration, every time.

What Changes When You're Building for Real Users

The production gap is mostly invisible until it isn't. A few specific failure modes that came up:

Context window degradation. As conversations grow, model instruction quality drops. This is why Victor's team doesn't use the same model for every task — complex planning tasks get Opus, simpler operations get smaller, cheaper models. Knowing your context window limits is basic infrastructure thinking most vibe-coders skip entirely.

Expectation drift at scale. A prototype that performs well for one user behaves differently with hundreds of concurrent requests hitting a poorly indexed database. Supabase's performance advisor surfaces these before launch. Most people don't look at it.

The visibility problem. Harry put this well: "Clients see fast visible progress at the beginning. When you move to backend security work, they stop seeing results. They think you slowed down." Being explicit about what non-visible work involves — and why it's non-negotiable — is part of the delivery.

The Principle Underneath All of It

The build time has compressed. The architecture requirements haven't. The teams winning right now are the ones who treat AI as a force multiplier on careful thinking, not a replacement for it.

This is the same principle that shapes both sides of what we do at dot2.solutions. When we build production apps with Lovable, the planning phase — data model, user types, integration constraints, security posture — comes before the first prompt. When we deploy Fin for customer service teams, the knowledge architecture comes before the AI configuration. A Lovable project without a coherent data model stalls the same way a Fin deployment without a structured knowledge base does. It's also worth noting that since May 2026, new Lovable projects default to TanStack Start with SSR — the same stack this site runs on, and the right foundation for anything that needs to be crawlable, fast, and production-ready from day one.

Content before configuration. Architecture before code. The tools have changed dramatically. That part hasn't.

Related reading: the Lovable SEO reality check, Intercom Fin vs custom AI chatbots, and working with an Intercom consultant in Switzerland.