Skip to content
vibecodershq.Submit a tool

14 Oct 2026

How to Vibe Code Your First App: A Step-by-Step Tutorial

How to vibe code a real first app: pick a tiny project, write your first prompt, fix one thing at a time, add logins and data, then publish.

To vibe code your first app, pick one browser app builder, describe a small app in three to five plain sentences, test what it builds, and fix problems one change at a time. Connect a database only when the app needs to remember something between visits. Then publish it to a live URL.

New to this? Start with the 15-minute walkthrough in our What is vibe coding guide. This tutorial covers what comes next: a backend, logins, publishing, and getting unstuck.

Pick a tiny project

Step 1: Choose an app that does one job for one kind of person, such as a shared reading list for a book club. In our view, a good first project fits on one screen and offers at most two actions.

Step 2: Write down what "done" looks like before you open a tool. Use results you can see: "after I press Add, the new book appears at the top of the list." Replit's first-app guide calls these observable success criteria.

Choose a tool

Prices checked Oct 14, 2026.

Step 3: Pick one browser app builder and stay with it for the whole project. None of these needs an install:

  • Lovable builds web apps from plain-language prompts and includes a built-in backend, Cloud, with a database, logins, storage, and functions. Its free plan includes five build credits a day, up to 30 a month.
  • Bolt builds websites, web apps, and mobile apps, and its Bolt Cloud adds databases, hosting, and domains. Paid plans start at $25/month.
  • Replit has its Agent build, run, and check the app, which you then test in Preview.

In our view, learning one tool well beats picking the perfect one. Compare them in Lovable vs Bolt vs v0. For a wider shortlist, see our best vibe coding tools for beginners.

Write the first prompt (copy-paste template)

Step 4: Describe the app in three to five sentences: what it is, what a person can do, what success looks like, and what to leave out. Fill in the brackets:

Build a [type of app] for [who it is for].
On the main screen, a person can [action 1] and [action 2].
It is working when [something you can see happen].
Use realistic sample data, keep the design simple, and make it work on a phone.
Do not add login, a database, payments, or outside services yet.

For example: "Build a shared reading list for a small book club. A person can add a book and mark it finished. It is working when a new book appears at the top of the list after I press Add."

The last line matters: Lovable's quick start says skipping logins and databases at first means less can go wrong, and Replit's guide postpones them too.

The test and re-prompt loop

Step 5: Test the app like a stranger would. Click every button, try every form, check a phone-sized preview, and compare against your Step 2 list.

Step 6: Fix one thing per prompt, and describe the symptom, not the code. Replit's guide says to describe what is broken instead of diagnosing the code yourself. A pattern that works, in our view:

When I [do this], [this happens]. I expected [this instead]. Change only this.

Step 7: Learn how to undo before you need to. Lovable saves every change as a version you can restore. Bolt has version history and connects to GitHub for version control.

Adding logins and data, with Supabase or Convex

Step 8: Add a database only when the app has to remember something between visits. Lovable's built-in Cloud backend is enabled for your workspace by default and built on Supabase's open-source foundation, or you can connect a Supabase project you own. Lovable's docs say there is no one-click migration between the two, so decide early. Bolt creates a database automatically when your app needs one, and you can claim it and connect it to Supabase.

Step 9: If you move your code into an editor, choose Supabase or Convex by how you want to protect data. Supabase relies on Postgres Row Level Security, and its docs say to enable it on every table in an exposed schema. Convex is a reactive database where queries are TypeScript code; its docs say the most common approach is to check, at the start of each public function, whether the user is signed in and allowed to act. In our view, Supabase suits people who like a dashboard and tables; Convex suits people comfortable with TypeScript.

Step 10: Add logins as their own change, then test with two accounts. Convex's docs list Clerk among third-party sign-in options and call their own Convex Auth library beta. In our view, the test that matters is signing in as two people and confirming neither sees the other's private data.

See more in our backend and deploy category.

Publishing, with Vercel or Netlify

Step 11: Publish from your builder first. Lovable publishes to a lovable.app address on every plan; its docs warn that later changes don't go live on their own, so republish after each round of edits. Bolt gives every project a free bolt.host subdomain.

Step 12: Move to Vercel or Netlify once your code lives in a Git repository. On Vercel, you create a New Project, pick the repository, set environment variables, and deploy; each push gets a preview deployment. Netlify builds automatically every time you push to a connected repository, or publishes a project folder you drop onto Netlify Drop. Convex's docs explain the extra CONVEX_DEPLOY_KEY setup for Vercel.

Common mistakes

  • Asking for several features at once. When something breaks, you can't tell which change caused it.
  • Skipping the phone test. Lovable's quick start notes most people will open your link on a phone.
  • Letting the AI go in circles. If the same fix fails twice, stop re-sending it (our rule of thumb). Lovable's docs suggest this instead:
    1. Ask the AI to investigate and explain what is happening.
    2. Revert to the version before the problem appeared, then write a clearer, narrower prompt.
    3. Ask for a plan first (Lovable has a Plan mode), review it, then build step by step.

Safety checklist

  • Keep secret keys out of the browser and your code. Supabase's docs say a secret key bypasses Row Level Security and must never go in a browser, a shipped app, or source control.
  • Know which keys are public. Supabase's publishable key is safe to expose because Row Level Security limits it. In Lovable, private keys go in Secrets, which never reach the browser. VITE_ values are browser-visible by design, so Lovable's docs say they belong in the project's .env file, not in Secrets, and that .env must stay committed (don't add it to .gitignore, or the preview breaks).
  • Store keys in your host's settings. Vercel makes Secret environment variables write-only after saving. Netlify recommends its UI, CLI, or API over storing sensitive values in your repository.
  • Turn on Row Level Security on every Supabase table before real users arrive.
  • Check permissions in every Convex public function. Convex's docs note its deployment endpoints are exposed to the open internet.
  • Rotate a leaked key right away: create a new key, replace the old one everywhere, then delete it, as Supabase's docs describe.
  • Never paste secret keys into chat or email. Supabase lists both as ways a secret key must never travel.

FAQ

How long does it take?

Our own estimate: an evening for a small app, a weekend once you add logins and saved data. Lovable's quick start says you can build and publish a first app in about ten minutes. In our view, each feature adds time, and getting unstuck often takes longer than building.

What should my first prompt say?

Say what the app is, who it is for, what a person can do, and what success looks like, in three to five sentences. Then say what to leave out: no login, database, or payments yet. Add those later, one change at a time, once the main screen works.

What if the AI keeps going in circles?

Stop repeating the request. Ask the AI to explain what is happening, then revert to the last version that worked and write a narrower prompt describing the symptom and what you expected. If it still fails, ask for a step-by-step plan first, review it, and build one step at a time.

Do I need GitHub?

No, not to start. Lovable's docs say you don't need Git to build and launch, and Lovable keeps a version history. You will want a Git repository to deploy through Vercel's Git integration or Netlify's continuous deployment, to back up your code, or to work with a developer.

How do I keep API keys safe?

Keep secret keys out of your code, your browser, and your chats. Store them in your tool's secrets settings or your host's environment variables. Use a public key, such as Supabase's publishable key, only where it is meant to be public, with Row Level Security on. If a secret key leaks, rotate it.

Sources

Vendor pages, all loaded Oct 14, 2026: