Vibe coding 101 · October 19, 2026

Where Does a Vibe-Coded App Live? Hosting, Domains and Payments

Your AI-built app works on your laptop. Now what? Hosting, domains, databases, logins, payments and API keys, explained for service business owners.

In April 2025, Andrej Karpathy, the person who coined the term "vibe coding," tried to ship a real app with it. He wrote up the experience in Vibe coding MenuGen, and it is still the most honest account of what happens after the demo works.

The app was simple: photograph a restaurant menu and see a picture of every dish. The AI wrote all the code, and the version on his laptop worked quickly. Then he tried to put it on the internet, with logins and payments, and spent most of his time on that. His summary: he felt 80% done, and it turned out to be closer to 20%.

If you are a service business owner with an app idea for your clients, this is the part the YouTube tutorials skip. Here is every piece MenuGen needed, what it is, and what it means for a tool your clients will use.

Why "it works on my laptop" is not the finish line

When an AI builder shows you a working preview, the app runs in one controlled place: your computer or the builder's sandbox. Your clients need it to run somewhere public, at an address they can type, around the clock, with their own accounts and their own data kept separate from everyone else's.

Karpathy compared this to assembling IKEA furniture. Each piece comes from a different vendor with its own account, settings and documentation. The AI can help you with every one of them, but it cannot create the accounts for you, and it often gets the details wrong.

Builders like Lovable, Bolt and Replit bundle some of these pieces, which is a real advantage. Tools like Claude Code and Cursor leave every choice to you. Either way, the pieces are the same.

Hosting: where the app runs

Hosting is the computer that serves your app to the world. For most AI-built apps that means Vercel or Netlify. Lovable, Bolt and Replit host for you, and so does v0, which deploys to Vercel.

Two things to know:

• Read the plan terms. Vercel's free Hobby plan is for non-commercial use only. A tool your business offers to clients is commercial, so it belongs on Pro, at $20 per user a month as of October 2026.
• Watch what gets published. Karpathy found that Vercel had automatically deployed his private, unfinished project to a public and easy-to-guess web address. Hosting services deploy whatever you push, often to a live address, unless you tell them otherwise. Assume anything you deploy can be seen.

Domains: the address clients type

You will want the tool at your own address, such as quote.yourcleaningco.com, not at a builder's default address. That means buying a domain, or using one you already own, and pointing it at your host through DNS settings.

On Lovable and Bolt, a custom domain needs a paid plan. DNS changes can take anywhere from minutes to a couple of days to work everywhere, so do not schedule a launch the same afternoon. Karpathy also found that logging in with Google required a custom domain before it would work in production. Pieces depend on each other in ways no one tells you up front.

The database: where client data lives

If your app saves anything, such as a client's intake answers, uploaded documents or appointment history, it needs a database. For vibe-coded apps that usually means Supabase, which Lovable and Bolt connect to by default.

Supabase's free tier is generous for testing: two projects, a 500 MB database and up to 50,000 monthly active users. It also pauses projects after a week without activity, which surprises many beginners when a demo goes dark before a meeting. A tool clients rely on belongs on a paid plan, from $25 a month.

The bigger issue is access. In apps built with Lovable and similar tools, the browser talks to the database directly using a public key. The only thing stopping one client from reading another client's records is a set of database rules called Row-Level Security. When researchers checked showcased Lovable apps in 2025, about one in ten had those rules missing or wrong, which exposed names, emails, payment details and more.

For a law firm's intake tool or an accounting firm's client portal, that is not a bug. It is a breach. Read our security checklist before any real client data goes in.

Logins: who is who

Authentication is how your app knows which client is signed in. Supabase includes it, and services like Clerk, which Karpathy used, do it too.

This was where Karpathy came closest to giving up. The AI wrote roughly a thousand lines of code using an outdated version of Clerk's tools. Adding "Sign in with Google" meant setting up a Google Cloud project and waiting for Google to approve it. He wrote that he thought about quitting around there.

For a service business, keep the first version simple: email and password, or a magic link sent by email. Add Google or Microsoft sign-in once the tool has proven itself. SaaStr founder Jason Lemkin, after building several production apps without a developer, gives the same advice in his guide: avoid external logins early on, and expect email services to break.

Payments: how clients pay you

If clients pay inside the tool, for a deposit, a booking or a subscription, you will almost certainly use Stripe. Karpathy's experience points to three rules:

1. Link payments to user IDs, not email addresses. His AI first matched Stripe payments to users by email. Emails change and get mistyped. He had it store each user's ID in Stripe instead.
2. Test mode and live mode are separate worlds. Products, prices and keys you set up in test mode have to be recreated in live mode. Plan an hour for this, not five minutes.
3. Only the server decides whether someone has paid. In one of the Lovable apps from the 2025 research, attackers could write a record marking a payment as "paid" without paying at all, because the app trusted the browser. The server must check with Stripe directly.

Environment variables: where the keys go

Your app holds secret keys for the AI model, the database and Stripe. These belong in environment variables: settings stored on your host, outside your code, and never sent to a visitor's browser.

Karpathy kept his keys in a local file called .env.local, which is correct, but that file is deliberately not uploaded with your code. So when the app went live, none of the keys came with it, and he lost about an hour adding them by hand in Vercel's settings. The tempting shortcut, pasting the key into the code, is exactly how other founders have had keys stolen and bills run up within days.

Two rules: every secret goes in your host's environment settings, and every usage-billed service gets a spending limit. Simon Willison has cited people who ran up thousands of dollars on AI APIs with no limit set.

A checklist before your clients see it

For a client-facing tool, such as a clinic's pre-visit questionnaire, a home services quote tool or a client portal, check each of these before launch:

• Hosted on a commercial plan, with nothing unfinished published at a public address
• On your own domain, with DNS set up days before launch
• Database on a paid plan, with Row-Level Security reviewed by someone who understands it
• Logins tested with two different client accounts that cannot see each other's data
• Stripe in live mode, payments linked to user IDs and verified on the server
• Every key in environment variables, with spending limits set
• Backups switched on, and someone who knows how to restore them

What Karpathy wanted, and what a service business needs

Karpathy concluded that vibe coding full web apps was "kind of messy and not a good idea for anything of actual importance." He wanted platforms where hosting, domain, logins, payments and database come already wired together. The builders have moved in that direction since, and the gap is smaller than it was. It has not closed. The pieces still have to be set up correctly, and the consequences of getting them wrong land on your clients.

That is the honest line for a service business. Building the prototype yourself is a great way to learn what your idea is. Putting your clients' data and payments into it is a different job.

If the tool you have in mind is something clients would pay for, not just a faster internal process, that is the work Veyra does. We build a working prototype before any money changes hands, agree one fixed build fee after you have seen it, and are then paid on what the product earns while we stay on as product lead, including the hosting, security and payments described above. Book a call, or read how hard the last stretch really is.