How to Vibe Code an App as a Founder (and When to Hand It Off)

AI Operator ·Published October 22, 2026 ·By Ivan Bunin

Last verified 2026-10-22 against the vendor docs and OWASP pages listed in Sources. Tools and plans in this space change fast, so we review this guide every quarter.

How to vibe code an app, at a glance

Time estimates are the author's planning ranges for a simple internal tool or customer app, not measured benchmarks.

Every week a founder shows me an app they built over a weekend. It looks great. It has a login screen, a dashboard and a button that does the thing. Then I ask three questions. Who can read the database? What happens when someone signs up twice? Who fixes it on Tuesday when it breaks?

That's where the conversation usually goes quiet.

Vibe coding is real. A founder with no engineering background can now get a working prototype in a weekend. I think every founder should try it once, because it changes how you think about what's possible. But the prototype is the easy 80%. The last 20% is the part that touches real customers, real money and real data, and it's a job.

So this guide does two things. It walks you through vibe coding your first app, step by step. Then it shows you the launch and security work most tutorials skip, and where that work should go.

01 · The Definition

What is vibe coding?

Vibe coding is building software by describing what you want in plain language and letting an AI model write the code. You judge the result by running it, not by reading every line. Andrej Karpathy coined the term in February 2025, and Collins English Dictionary named it its Word of the Year for 2025.

In practice it looks like a chat. You type "build me a page where clients upload a contract and get a summary", the tool writes the code, shows you a live preview, and you keep asking for changes until it works.

There are two kinds of tools:

• Browser app builders such as Lovable, Bolt and Replit. You chat on one side and see your app on the other. They host the app for you, and most connect a database and login with a few clicks. Best for founders.
• Coding agents such as Claude Code. It works inside a real code folder on your computer or a server, edits many files at once and runs commands. More power, more setup, and you choose where it's hosted. Best for operators and developers. If you want to know what it costs, see our Claude pricing guide.

The tools are good. The question for a founder is not whether they work. It's which part of the job you should be doing yourself.

02 · The Steps

How do you vibe code an app in 7 steps?

Write the idea in one sentence, turn it into a one-page spec, pick a tool, prototype the main flow, test it with five real users, run the launch checklist, and decide who maintains it. Steps 1 to 5 fit in a weekend and a few evenings. Steps 6 and 7 are where the real work is.

Step 1: Write the idea in one sentence

"[Who] can [do what] so that [result]." For example: "My clients can see the status of every open project without emailing my team." If you can't write the sentence, you're not ready to build. More prompting won't fix a fuzzy idea. It just produces a fuzzy app faster.

Step 2: Write a one-page spec

This is the founder's real job, and the next section covers it in detail. One page. Who uses it, which screens exist, what data it stores, and the one action that has to work perfectly.

Step 3: Pick a tool

If you've never coded, start with a browser builder. They handle hosting and give you a preview in seconds. If someone on your team already works in a code editor, Claude Code gives them more control. Don't spend a weekend comparing tools. Pick one and start.

Comparing tools side by side? Our best vibe coding tools guide puts seven of them in one table, with prices checked this month.

Step 4: Prototype the main flow

Paste your spec into the tool as the first message. Then build one screen at a time. Good prompts are short and concrete:

• "Add a sign-up page with email and password. After sign-up, send the user to the dashboard."
• "On the dashboard, show a table of the user's projects with name, status and due date."
• "When I click a project, open a detail page. Only the project's owner should see it."

When something breaks, describe what you see, not what you think the code is doing: "When I click Save, nothing happens and the record doesn't appear in the table." Commit or save a version every time something works, so you can roll back when the next change breaks it.

Step 5: Test with five real users

Not your co-founder. Five people who have the problem. Watch them use it without helping. You'll learn more in an hour than in another weekend of prompting. Most first prototypes are solving a slightly wrong problem, and this is the cheapest moment to find out.

Step 6: Run the launch checklist

If the test goes well, the app is about to touch real customers. That's the 12-point launch checklist below, plus the 10 security checks.

Step 7: Decide who maintains it

Every app needs an owner after launch. Someone has to read the error alerts, update dependencies, answer "it's not loading" messages and ship the next feature. Decide now whether that's you. For most founders, it shouldn't be.

03 · The Founder's Job

Why should a founder write the spec, not the code?

Because the spec is the part only you can do. The AI can write code. It can't know who your customer is, which workflow costs you the most time, or what "done" looks like for your business. A clear one-page spec makes any tool, and any operator, ten times more useful.

Here's the template I use. Fill it in before you open any tool:

Line 2 matters more than it looks. "What each user is allowed to see" becomes your database rules, and wrong database rules are the most common way vibe-coded apps leak data. Lovable's own security docs say misconfigured row-level security rules "are a common cause of data leaks." Write the rule in plain English in your spec, and you've done half the security work before writing a line of code.

Line 7 matters too. Every feature you leave out is a feature nobody has to secure, test or maintain.

04 · The Launch Checklist

What do you need before you launch a vibe-coded app?

You need twelve things: a domain, real login, database rules, server-side secrets, tested payments, transactional email, analytics, error monitoring, backups, rate limits and spend caps, privacy and terms pages, and a named owner. A prototype usually has two or three of these. A launched app needs all twelve.

The checklist is the author's, built from the vendor and OWASP guidance in Sources: Supabase on row-level security and backups, Stripe on webhooks, Lovable on publishing and domains, and OWASP API4:2023 on rate and spending limits.

Two of these catch founders out most often.

Backups. On Supabase, the database behind many browser builders, daily backups cover Pro, Team and Enterprise projects. Free projects aren't backed up automatically, and Supabase recommends exporting them yourself. Pro keeps the last 7 days. If your prototype is on a free database and real customers start using it, that's a gap.

Payments. Stripe recommends testing your webhook handler in a sandbox or with test events before going live, and verifying every webhook's signature. Without verification, Stripe warns, an attacker could send fake events to "trigger actions like fulfilling orders, granting account access, or modifying records." A vibe-coded checkout that skips this step works perfectly in a demo and fails expensively in production.

05 · Security

Is your vibe-coded app secure?

Not by default. A vibe-coded app is as secure as the rules someone told the AI to write, and a prototype rarely has any. Run these ten checks before real users arrive. Most map to the OWASP Top 10:2025, where broken access control is number one.

Sources: OWASP Top 10:2025, OWASP Top 10 for LLM Applications 2025, OWASP API Security Top 10 2023, the OWASP Secrets Management Cheat Sheet, Supabase and Lovable docs. Links in Sources.

Secrets

An API key is a password for a service. The OWASP Secrets Management Cheat Sheet notes that many organizations still have secrets "hardcoded within the source code in plaintext," and advises rotating them regularly "so that any stolen credentials will only work for a short time." The vibe-coding version of this mistake is pasting a key into the chat and asking the AI to "just make it work". Lovable now detects API keys pasted into project chat and points you to its Secrets store instead. Use it. If a key was ever pasted into a public place, rotate it.

Row-level security

Row-level security is a database rule that decides which rows each user can see. Supabase's docs are blunt: "Enable RLS on every table in an exposed schema," because "a table in an exposed schema without RLS is readable and writable by any role with a grant on it." Once it's enabled, no data is reachable through the public key until you write policies. Supabase's secret key, which uses the service_role role, bypasses those rules, which is why Supabase says to never use it in the browser. This is the single most important check on this page. Your spec's "users" line is the input.

Rate limits and spend caps

OWASP's API Security Top 10 lists unrestricted resource consumption as API4:2023. The fix it gives is to rate limit how often a client can call the API, and to "configure spending limits for all service providers/API integrations." If a spending cap isn't possible, set up billing alerts. If your app calls an AI model for each user action, this is not optional. One bad actor or one bug in a loop can turn into a large invoice.

Prompt injection

If your app sends user input, emails, files or web pages to an AI model, read this. OWASP ranks prompt injection as LLM01, the top risk in its 2025 list for AI applications. Direct injection is a user typing instructions that change the model's behavior. Indirect injection is the model reading a web page or file that contains hidden instructions. OWASP's mitigations include constraining what the model is told to do, validating its output with ordinary code, and giving it least-privilege access, so that a fooled model still can't delete records or send emails on its own.

Dependency risk

OWASP added Software Supply Chain Failures to its Top 10 in 2025, as A03. Every package an AI tool installs is code from a stranger that now runs in your app. Keep the lockfile, prefer well-known packages, and run the tool's dependency scan. Lovable's Quick scan checks npm dependencies and database access rules automatically every time you publish, and a Deep scan reviews the code on demand. Lovable is also clear that these tools "cannot guarantee complete security", and recommends a professional review for apps that handle sensitive data. I agree.

06 · Deploying

How do you deploy a Lovable, Bolt or Replit app?

Each browser builder has a Publish button that puts your app on a free subdomain in minutes. Connecting your own domain usually needs a paid plan and a couple of DNS records. In all three, changes you make after publishing don't go live until you publish again.

How to deploy a Lovable app

Click Publish in the top-right corner of the editor. Lovable runs a quick security scan, then deploys to an address on lovable.app, with HTTPS included. Custom domains are available on paid plans: you add an A record pointing to Lovable and a verification TXT record at your DNS provider. When you keep working on a published project, you have to republish for visitors to see the changes.

How to deploy a Bolt app

Click Publish, then Publish again. Bolt deploys in about a minute to a free bolt.host address, with no separate hosting account needed. On paid plans you can attach your own domain. New changes go live only when you click Update.

How to deploy a Replit app

Replit calls it publishing, and the published app is separate from the version you're editing. You choose a deployment type: Autoscale, which scales with traffic, Static for sites that don't change based on user input, Reserved VM for apps that must run continuously, or Scheduled for jobs that run at set times. Custom domains connect from the publishing settings.

What about Claude Code?

Claude Code builds the app but doesn't host it. Someone has to choose a host, set up the database, connect the domain and set up deploys from a code repository. That's more work on day one and more control after it. It suits apps that will grow, and someone who builds every day.

"Lovable to production" means the checklist, not a button

Publishing makes the app reachable. Production means the 12-point checklist is done and somebody owns it. Those are different days.

07 · The Last 20%

Where do founders get stuck with vibe-coded apps?

Founders get stuck in the last 20%: login edge cases, data rules, deploys and maintenance. The AI can write each of these, but only if someone knows to ask, knows what good looks like and checks the result. That knowledge is the job, and it doesn't fit in a weekend.

Here's what the last 20% usually looks like in practice:

• Auth. Sign-up works. Then someone signs up twice, forgets a password, changes their email or gets invited by a teammate. Each one is a flow nobody prompted for.
• Data. The demo had one user. Now there are fifty, and the question "who can see this row?" has a real answer that has to be enforced in the database, not the screen.
• Deploys. A change that worked in preview breaks the live app. There's no staging copy, no rollback plan, and the fix gets made live, in a hurry, at 11 pm.
• Maintenance. A dependency updates, an API changes its terms, a model is retired, an email provider starts landing you in spam. None of this is a feature. All of it breaks things.

The pattern I see: the founder builds the prototype in a weekend, spends the next three weekends on the last 20%, and the actual business, the thing only they can do, waits. The tool didn't fail. The founder spent founder hours on operator work.

There's also a quieter cost. When the founder is the only person who understands how the app works, the founder is now the app's single point of failure. That's the bottleneck problem in a new costume.

08 · The Decision

When should you stop building and hand it off?

Hand it off the moment the app will touch real customers, real money or real data, or when you've spent two weekends on it and the business is waiting. Keep building yourself only if the app is a private tool for you, nobody else logs in, and you enjoy it.

A simple test. Answer yes or no:

1. Will anyone outside my company log in?
2. Will it store customer data or take payments?
3. Will something in the business depend on it working every day?
4. Have I spent more than two weekends past the prototype?
5. Would I rather be selling, hiring or talking to customers right now?

One yes, and it's time to hand it off. A developer builds a product. An operator runs your business on AI, and a launched app is one part of that.

09 · The Handoff

What should you hand an operator?

Hand over five things: the one-page spec, the prototype, access to every account in your company's name, the results of your five user tests, and the one action that has to work perfectly. Then the operator owns the build, the launch checklist, security and upkeep, and reports to you every week.

What you give

• The spec. The one page from section 3. It's the most useful thing you'll hand over.
• The prototype. Even a broken one. It shows what you meant faster than any meeting.
• Accounts in your name. The builder, the database, the domain, payments, email. Your company owns them, and the operator gets access. Never the other way round.
• What users said. Notes from the five tests, including what confused them.
• The one action. The thing that must never break.

What the operator owns

• Turning the prototype into a launched app, and running the full launch checklist.
• Database rules, secrets, rate limits and the security checks.
• Deploys, error alerts, backups and dependency updates.
• The next feature, scoped against your spec.
• Documentation, so that the app never depends on one person's memory.

At Pareto Talent, that's how an AI Operator works. You start with an AI Activation Call, where we map how your business runs and decide where AI goes first. Your operator builds from your Business Second Brain, so they know your offers, processes and voice from day one. Every automation they ship is watched under Run Watch, and every Friday you get the Friday Note: what shipped and what's next. Everything is documented in your Ownership Binder, and every account stays in your name.

What a bootcamp final project looks like

Every operator we certify finishes 40+ hours of training, then a 5-day final project: a full funnel built with AI, scored on a 25-point rubric, plus an interview. One builder's final project was the 6-Minute Inbox Audit. Others built the Founder Freedom Calculator and the Law Firm Capacity Audit. That's the standard: not "can you prompt", but "can you take an idea to a working, scored build in five days".

What it costs

An AI Operator is $3,600/month, month to month, plus a one-time $3,000 placement fee. It's paid once, on your call, and comes back in full if none of your 3 profiles fit. Quarterly ($10,000) and annual ($36,000) plans are also available. For scale, the US Bureau of Labor Statistics puts the median software developer salary at $135,980 a year, before benefits. If you're weighing a developer instead, compare hiring an AI developer.

Two guarantees, word for word from the offer:

• Pick before you pay. Meet 3 certified AI Operators within 24 hours of your call and choose yours. Your subscription starts only when you pick. The $3,000 placement fee, paid on your call, comes back in full if none of the 3 fit.
• The Replacement Guarantee. If your operator can't build what you need, or ever stops being the right fit, we replace them fast, with a full handover, for as long as you're with us.

FAQ

Frequently asked questions

Sources

Sources

• Wikipedia, "Vibe coding", opened 2026-10-22: term coined by Andrej Karpathy in February 2025; named Collins English Dictionary Word of the Year for 2025.
• Supabase Docs, "Row Level Security", opened 2026-10-22: enable RLS on every table in an exposed schema; no data reachable through the publishable key until policies exist; the secret key uses the service_role role, which bypasses RLS, and must never be used in the browser.
• Supabase Docs, "Database Backups", opened 2026-10-22: daily backups for Pro, Team and Enterprise projects; Pro keeps 7 days, Team 14, Enterprise up to 30; free projects should be exported manually.
• Lovable Docs, "Security overview", opened 2026-10-22: Quick scan at every publish (database access rules, npm dependencies, MCP exposure); on-demand Deep scan; API key detection in chat; misconfigured RLS as a common cause of data leaks; no guarantee of complete security.
• Lovable Docs, "Publish your Lovable project" and "Set up a custom domain", opened 2026-10-22: lovable.app subdomain, HTTPS included, republish to update; custom domains on paid plans with an A record and a verification TXT record.
• Bolt Support, "Publish your project to a live website", opened 2026-10-22: Publish deploys in about a minute to bolt.host; custom domains on paid plans; Update to push changes.
• Replit Docs, "Publishing", opened 2026-10-22: Autoscale, Static, Reserved VM and Scheduled deployment types; published app separate from the editor version; custom domains.
• Stripe Docs, "Receive Stripe events in your webhook endpoint", opened 2026-10-22: test in a sandbox before going live; verify webhook signatures; HTTPS required in live mode.
• OWASP, "Top 10:2025", opened 2026-10-22: A01 Broken Access Control, A03 Software Supply Chain Failures, A07 Authentication Failures, A09 Security Logging and Alerting Failures.
• OWASP Gen AI Security Project, "LLM01:2025 Prompt Injection", opened 2026-10-22: direct and indirect injection; mitigations including constrained behavior, output validation and least privilege.
• OWASP API Security Project, "API4:2023 Unrestricted Resource Consumption", opened 2026-10-22: rate limiting and spending limits on service providers and API integrations.
• OWASP Cheat Sheet Series, "Secrets Management Cheat Sheet", opened 2026-10-22: hardcoded secrets in source code; regular rotation.
• U.S. Bureau of Labor Statistics, Occupational Employment and Wage Statistics, May 2025: median annual wage for software developers $135,980.
• Pareto Talent, the AI Operator offer and the live /ai-operator page, opened 2026-10-22: training and final project standard, final project names (shared with the builders' consent), pricing and guarantees.
• The 7 steps, the one-page spec, the 12-point launch checklist, the 10 security checks, the handoff test and all time estimates: the author's own framework, built from the sources above.

Written by Ivan Bunin, who builds Pareto Talent's internal tools with Claude Code. Reviewed and updated quarterly. Last verified 2026-10-22.

Ivan Bunin

Co-founder & CEO, Pareto Talent

Ivan started in 2018 as Kasim Aslam's executive assistant at Solutions 8, rose to CTO and then CEO, and ran the company's eight-figure exit in 2022. He built Pareto Talent's internal operating system with Claude Code and teaches the AI curriculum in Pareto's bootcamp. He posts what he's building with AI on YouTube and LinkedIn. More about Ivan and Pareto Talent.