Deploying online

Going live: what it means

Until now, your app lives in your tool or on your computer: only you can use it. Deploying means copying your app to a server reachable from the Internet, which serves it to anyone who opens the right address. The concrete result: a URL like my-app.vercel.app that Tom can write on the board, and that every student opens on their phone.

Good news for an app like yours: it's free, fast, and largely automated. "Static" apps (HTML, CSS, JavaScript, with no server of your own) are the simplest in the world to host — which is exactly why we chose that technical foundation in chapter 3. The simple choices made early are paying off now.

The free platforms

Three big names dominate free web app hosting, and you can't really go wrong: they are all reliable, fast and used by millions of projects. Here's how to choose:

Special case: if you built your app on Lovable, v0, Bolt or Replit, these platforms offer a built-in "Publish" or "Deploy" button that does everything in one click. It's the simplest route — use it for your first launch, you'll explore Vercel or Netlify when you need them.

The simplest method: no command line

If Git and the terminal still intimidate you, there's a path with zero commands: the Netlify drag-and-drop. You ask your tool to export or download your app's files (a folder with your index.html and the rest), you open Netlify's drop page, and you drag the folder into the designated zone. Thirty seconds later, your app has a public URL.

This method has one limit: every time you modify your app, you have to re-drag the folder by hand. It's perfectly fine for a first launch or an app that rarely changes. As soon as you modify things often, the Git path becomes more comfortable — every pushed commit updates the site automatically.

The full path with Git and Vercel

"Professional" deployment always follows the same logic: your code lives in a Git repository hosted on GitHub, and the platform (Vercel or Netlify) watches that repository. Every time you push an update, it rebuilds and republishes your site automatically. That's the famous "push to deploy" — you never deal with going live again, it follows your work.

You don't need to memorize the procedure: ask the AI to guide you, step by step, stating your level. Here's the prompt Tom uses:

Guide me through deploying this app on Vercel, step by step, starting from zero.
I have never used Git or Vercel. I have a brand-new GitHub account.
For each step: tell me where to click or which command to type, and explain in one sentence what it's for.
Wait for my confirmation before moving on to the next step.

The last line is a precious trick: by asking the AI to move one step at a time, you turn an intimidating procedure into a calm conversation where you can flag the slightest blocker the moment it occurs. For reference, the commands you'll see go by look like this:

# Link your local project to the repository created on GitHub:
git remote add origin https://github.com/your-account/my-app.git

# Send your code to GitHub:
git push -u origin main

# Then, on vercel.com: “Add New Project” → import the repository → Deploy.

flowchart LR
  L["App on your computer"] --> G["Git repository"]
  G --> V["Vercel / Netlify"]
  V --> U["Public URL"]
  U --> F["User feedback"]
  F -.->|"Improvements"| L

Verifying your app online

A successful deployment doesn't mean everything works: the online environment differs slightly from your local preview. Take five minutes for a serious check. Open the public URL in a browser in private browsing (to start from scratch, with no local data), redo the complete user journey, then open the URL on your phone — that's where your users will be.

• Does the app load, with no blank page or 404 error?
• Does the main journey work end to end (add, check off, see the streak)?
• Does the data persist after reloading the page?
• Is the display correct on a phone: readable text, buttons tappable with a thumb?

If something breaks online when it worked locally, don't panic: it's a classic. Copy the error from the console (F12, even online) and describe the difference to the AI: "locally it works, online on Vercel I get this error: …". The usual causes — an incorrect file path, a capital letter in a file name — get fixed in one message.

Sharing and gathering feedback

Once online, share the URL. Real feedback is the best fuel for progress: Tom gives the link to a few students and watches how they use it. And there, guaranteed surprise — users never do what you expect. One student tries to add twenty habits, another looks for an "undo" button that doesn't exist, a third asks why his data isn't on the home computer (remember: localStorage = per-device data).

Gather this feedback simply: watch people use the app without helping them, note what blocks them, and ask two questions — "what annoyed you?" and "what do you miss the most?". Three users are enough to spot 80% of the obvious problems. Add their answers to your "later" list, and sort: whatever comes up several times moves to the top.

What next?

You have a real app online. Iterate: pick from your "later" list enriched with user feedback, add one feature per session following the chapter 4 method, and republish — with "push to deploy", every validated improvement goes live on its own. The classic v2 projects: a better design, a custom domain name, data export, or syncing between devices (the famous user account, now that you know what it costs).

And above all, do it again. Pick a second project, a bit more ambitious, and redo the complete journey: mini-PRD, iterative construction, methodical debugging, deployment. Each project makes you more comfortable driving the AI, faster at diagnosing, more precise in your descriptions. That's exactly how building is learned today — and you've just completed the full loop for the first time. Welcome to the club.