You’ve vibe coded an app. Now what?

Building something with AI has never been easier. Describe an app, and a few minutes later you have a working page: a habit tracker, a sign-up sheet, a tool for your team. Then you try to share it, and you hit a wall 🧱

The file only opens on your computer. When a friend does manage to open it, they don’t see what you added. Close the tab, and your data is gone. And somewhere around here the jargon starts: deploy, hosting, database, backend, React.

AI tools have started to close part of this gap. Claude and others can now publish what you make at a link in one click, and some will even save a little data for you. That’s a great start, but it all lives inside their product. The moment you want your own address, people signing in and data that belongs to you, you need to understand the building blocks underneath.

This post is a map of those blocks, for people who aren’t developers. There’s no code to learn, just enough to know what each piece does, so you can ask your AI for the right thing and notice when it gets something wrong. Then come the guardrails: the habits that keep you, your users and your data safe when AI writes the code. At the end there’s a prompt you can copy, so your AI walks you through it with your own app, one step at a time.

What you have now: a file

A vibe-coded app is usually one HTML file. It’s a text file of instructions for your web browser. The HTML says what’s on the page, the CSS says how it looks, and the JavaScript says what happens when you click.

When you double-click the file, your browser reads it straight off your own computer. Look at the address bar: it starts with file://, not https://. That one detail explains every wall you’ve hit:

• Nobody else can open it. It’s on your computer, not on the internet.
• It can’t share anything. If it saves at all, it saves inside your browser, so everyone who opens it is on their own island.
• It doesn’t know who anyone is. It can’t tell your list from someone else’s.

Each of those problems has a building block that solves it. I use Firebase, Google’s toolkit for building apps, because it puts every block under one roof and it’s free to start. There are good alternatives, but the blocks are the same wherever you go.

The map

Here’s the whole picture before we take it apart. Say your app is for your book club: members add the books they’d recommend, and everyone sees the list. This is what happens when a member opens it on their phone:

And here’s each block at a glance, with the question it answers:

React: the part people see

React is a popular way of building an app’s screens out of pieces, called components: a book card, an “add book” button, the list of books. You design each piece once and reuse it everywhere.

The big idea is that you describe what the screen should look like for the data you have, and React keeps the screen in step with it. Add a book, and the list updates itself.

You don’t strictly need React to go live. Your single file could go online today. But one file gets harder to change with every feature, for you and for your AI. Split into small components, your AI can change the “add book” button without breaking the sign-in. AI tools are also very good at React, because so much of the code they learned from is written in it.

You’ll hear one more word here: build. React is written in a form browsers can’t read directly, so a tool called Vite turns it into plain HTML, CSS and JavaScript files. Those built files are what goes online.

Hosting and deploying: giving it an address

Hosting is a computer that’s always on and connected to the internet, where your app’s files live. Deploying means copying the latest version of your files onto it.

With Firebase Hosting, deploying is one command: firebase deploy. A minute later your app is live at an address like book-club.web.app, with the padlock (HTTPS), and loads quickly anywhere in the world. You can connect your own domain later, and if a new version breaks something, you can roll back to the last one with a click. This site works exactly this way: publishing a change is one command.

My advice is to deploy on day one, before the app does anything useful. Once there’s a link, every improvement is something people can see.

The database: the app’s shared memory

A database is where the app keeps what it knows, on a server rather than inside each person’s browser. It’s the difference between everyone keeping their own notepad and everyone working from the same list.

Firestore, Firebase’s database, organises data like folders of cards. A collection is a folder, such as books. A document is a card in it: one book, with its title, its author and who added it.

The part that feels like magic is that Firestore is realtime. When one member adds a book, it appears on every open screen without anyone refreshing, like a shared Google Sheet. That’s how chat apps, live boards and dashboards work, and you get it built in.

Sign-in: who is this?

Once data is shared, the app needs to know who’s who: who added this book, and who’s allowed in at all.

Firebase Authentication gives you a “Sign in with Google” button, or email, Apple, phone and others, without you ever handling a password. Each person gets a permanent ID, and the app stamps it on everything they create.

Security rules: the bouncer

This is the block most vibe-coded apps get wrong, so it’s worth slowing down.

In a Firebase app, people’s browsers talk to the database directly. That’s what keeps it simple, but it means the database itself has to decide who may do what. Those decisions are the security rules. For the book club, they could be:

match /books/{book} {
  allow read: if request.auth != null;
  allow create: if request.auth.uid == request.resource.data.addedBy;
  allow update, delete: if request.auth.uid == resource.data.addedBy;
}

In plain English:

• Anyone who’s signed in can see the books.
• You can add a book, but only in your own name.
• Only the person who added a book can change or delete it.

⚠️ When you create a database, Firebase offers to start it in test mode. Test mode means anyone on the internet can read, change and delete everything for 30 days. Many of the leaks you read about from vibe-coded apps come down to a database anyone could read. Ask your AI to write real rules and to explain each one back to you in plain English. If it can’t, stop there.

Functions: work done out of sight

Anything that runs in the browser can be seen by whoever opens the app: right-click, Inspect, and it’s all there. Usually that’s fine. For secrets, it isn’t.

The classic case is an app that calls an AI service, with the secret key for it sitting in the HTML. Anyone can copy the key and run up your bill. The fix is a Cloud Function: a small piece of code that runs on Google’s computers, keeps the key, and makes the call on your app’s behalf. Functions also send emails, run jobs on a schedule and handle payments.

Two things to know. Functions need Firebase’s pay-as-you-go plan, which means adding a card, though the free allowance still applies. And not every key is a secret: your app’s Firebase settings include something called an apiKey, which is meant to be public. It only says which project to talk to. Your security rules are what protect it.

Most first versions don’t need functions at all. Add them when you have a secret to keep.

What it costs

Nothing, to start. Firebase’s free plan covers hosting, the database and sign-in for a small app, with no card needed. Firestore alone allows 50,000 reads and 20,000 writes a day. If you ever move to pay-as-you-go, set a budget alert on the first day, and know that it warns you rather than stopping the spending.

Guardrails: building safely with AI

AI writes code quickly and confidently, and it makes mistakes just as confidently. It also aims to please. Ask it to make an error go away and it will, sometimes by removing whatever caused the error, even when that was a lock you needed. An experienced developer spots this. When you’re starting out, you need a few habits instead.

Common pitfalls

• Fixing an error by removing the lock. “Missing or insufficient permissions” is Firebase telling you the security rules did their job. Ask the AI to fix it, and the quickest fix is to open the rules to everyone. The error disappears, and so does your security. Whenever a fix touches the rules, ask why.
• Security that’s only on the screen. Hiding the delete button from everyone but you isn’t protection. The button is only a shortcut, and anyone can talk to the database directly. Only the rules protect your data.
• Secrets in the wrong place. A key pasted into the chat tends to end up in the code, and bots scan code pushed to GitHub for keys within minutes.
• Only the happy path. AI tends to build for one person, on good wifi, typing sensible things. Real people double-click, paste an essay into the name box, use a phone, and lose signal halfway through saving.
• “Done!” without checking. Agents sometimes say something works without having tried it. Believe the live link, not the message.
• Installing what you don’t recognise. AI occasionally recommends a package under a name that doesn’t exist, and attackers register those names. Ask what a package is before you install it.

Never

• Never paste a secret key or password into the chat or into your code. When you need one, ask the AI where secrets go (for Firebase functions, a command that stores them with Google) and type it in there yourself.
• Never leave the database in test mode, or accept a rule that says if true.
• Never let an agent delete data, your database or your Firebase project without asking you first. There are well-known cases of AI agents wiping a live database.
• Never put real people’s personal data in before the rules are written and tested. If you collect names or emails, you’re responsible for them.
• Never turn off your agent’s “ask before running” prompts until you understand what it’s asking to do.

Always check

• Try to break in. Open your live app in a private browser window, signed out. Can you see anything you shouldn’t? Then sign in with a second Google account. Can it see or change the first account’s data?
• Hunt for secrets. Ask your AI to search the project, the built files and the git history for secret keys. Most AI services’ secret keys start with sk-, so that’s a good thing to search for.
• Read the rules in plain English. Ask for them line by line, and check they say what you would say.
• Ask what changed. Before each deploy, ask “what did you change, and why?” If you don’t understand the answer, don’t deploy yet.
• Use it like a stranger would: on your phone, on bad wifi, typing nonsense.
• Look at your data and your usage. The Firebase console shows what’s in the database and how much you’re using. A quick look each week catches surprises early.

Ask for a review before you trust it

The habit that catches the most is also the simplest: ask. AI tends to answer exactly the question it’s given. Ask for a delete button and you get a delete button, and it won’t always mention that anyone can now delete anyone’s books. Ask it to look for security holes and edge cases (the unusual situations: an empty form, two people editing at once, a connection that drops) and it switches from builder to critic. It’s good at that job, and will often find problems in code it wrote a minute earlier.

Two things make the review better. Do it in a fresh conversation, so the AI reads the code without the story of how it got there. And ask it to report before it fixes anything, so you decide what changes. This is the one I’d paste before every deploy:

Before I deploy, review this app as if you were trying to break it.

Security: could someone who isn't signed in, or a different signed-in user, read, change or delete data that isn't theirs? Is any secret key visible in the browser or saved in git? Do the security rules match what the app promises, and are they tested?

Edge cases: what happens with empty input, very long input, a double-click, two people changing the same thing at once, a slow or dropped connection, and a small phone screen?

List what you find, most serious first, and explain each in plain English. Don't change anything until I've said which ones to fix.

What you need

• A Google account, for Firebase.
• Node.js, the engine that runs developer tools on your computer. It’s free from nodejs.org.
• An AI tool that can work on your computer, such as Claude Code or Cursor, which can create files and run commands for you. An ordinary chat works too: you’ll just copy and paste more.
• The terminal, the text window where commands are typed. On a Mac it’s called Terminal, and on Windows it’s PowerShell. Your AI will tell you what to type.

Try it: a prompt to copy

Paste this into your favourite AI, fill in the line about your app, and follow along. If you use a tool that works on your computer, like Claude Code, open it in the folder with your HTML file first. The prompt takes you through every block in this post, in order, and explains each one as you go.

I'm not a developer, and I'm new to all of this. I've built an app as a single HTML file with an AI tool, and I want to turn it into a real web app that other people can use from a link, with their data saved. Be my patient teacher, and do the technical work with me.

My app: [paste your HTML here, or tell me which file in this folder it is. No app yet? Write: "I don't have one yet, help me make a simple one first."]

What we're building:
- The app rebuilt in React with Vite, looking and working like my HTML version
- Hosted on Firebase Hosting, so it has a public web address
- Data saved in Firestore, so it's shared and isn't lost when someone closes the tab
- Sign in with Google, using Firebase Authentication
- Firestore security rules, so people can only see and change what they should
- All on Firebase's free Spark plan

How to work with me:
1. Assume I've never used a terminal or written code. Explain every technical word in plain English the first time you use it, and if I'm confused, explain it another way.
2. Before anything else, ask me which computer I'm using (Mac or Windows) and whether you can run commands on it. Then check it has what we need (Node.js and the Firebase command line tools), and help me install anything missing.
3. Read my app and ask me two questions: what should it remember, and who should be able to see and change what?
4. Go one step at a time. Before each step, tell me in a sentence or two what we're doing and which building block it is. After each step, check that it works before moving on.
5. If you can run commands on my computer, run them and tell me what they did. If you can't, show me how to open the terminal, give me one command at a time, and wait for me to paste back what happened.
6. When I need to do something myself, like creating the Firebase project or turning on Google sign-in in the Firebase console, tell me exactly what to click.
7. Put the app live as early as possible, even before it saves anything, and deploy again after each big step.
8. Never use Firestore's "test mode", and never loosen the rules to make an error go away. Write real security rules, explain each one in plain English, and test them.
9. Don't put secret keys in the app. The Firebase web config is fine, because it's meant to be public. If my app uses a secret key, for example for an AI service, stop and explain my options.
10. Ask me before deleting anything: data, files, the database or the Firebase project.
11. Before each deploy, review the app for security holes and edge cases, tell me what you found in plain English, and fix the serious ones with me.
12. Save a checkpoint with git (save points for code) after each step that works, so we can go back if something breaks.

When we're done, give me the live link and a short summary to keep: what each building block does in my app, and the one command I run to publish changes.

The gap is smaller than it looks

Between “I made a thing” and “people use my thing” there are six building blocks and a handful of habits, not a computer science degree. You don’t need to master any of them. You need to know what each one is for, so you can ask for it, and notice when it’s missing.

If you try it, I’d love to see what you put live 🚀 And if you get stuck, tell me where. I’ll write a follow-up in a few weeks with the places people got stuck and how they got past them, so the next person has an easier time.