How to actually ship the apps you build

The big picture: what a live app is actually made of

When you build something with Claude, it runs on your computer. To let other people use it, the same pieces need to live somewhere on the internet that's always on. Almost every app is some combination of these five layers:

A simple landing page might only need layer 1. A dashboard where people log in, see their data, and download reports needs all five. The good news: you don't have to assemble five separate companies. A few modern platforms bundle several layers together so a beginner can run a real app with one or two accounts.

The rest of this guide walks through each layer, names the easiest tools, and explains when you'd reach for each.

Where to host: the one distinction that explains everything

Before comparing logos, understand the single fork in the road. Hosting platforms fall into two camps, and picking the right camp matters more than picking the right brand.

The four platforms you'll reach for most

Which host do I pick? A 10-second decision

You don't have to commit forever. Moving a small app between hosts later is normal and usually painless — so start with whatever gets you live fastest.

GitHub: the backbone that ties it all together

GitHub is where your code lives online. It's four things at once: a backup, a history of every change, a collaboration space, and the source that hosts like Vercel and Railway deploy from. Set this up first — everything else plugs into it.

The mental model

Your project is a repository ("repo") — a folder of code that GitHub tracks. As you work, you save snapshots called commits, then push them up to GitHub. When you connect a repo to Vercel or Railway, every push automatically deploys the new version. That's the magic loop: code → commit → push → live.

The handful of commands worth knowing

Claude can run most of these for you, but here's what they mean so the words aren't a mystery:

# copy a repo from GitHub down to your computer
git clone https://github.com/you/your-project

# see what you've changed since the last snapshot
git status

# stage your changes, then save a snapshot with a note
git add .
git commit -m "Add the upload button"

# send your snapshots up to GitHub (this triggers a deploy)
git push

# pull down changes someone else (or you, elsewhere) pushed
git pull

# branch = a safe parallel copy to experiment in
git checkout -b my-experiment

If you remember only two: commit saves a snapshot, push uploads it. That's 90% of day-to-day work.

Building with Claude on your repo

You can connect Claude directly to your GitHub so you can build, edit, and ship without leaving the conversation:

• Easiest sign-in: when a platform offers it, use "Continue with GitHub" (or Google). It skips creating yet another password and links your accounts cleanly. This is what we recommend for new builders — fewer credentials to lose.
• Connect the GitHub connector (or use Claude Code) so Claude can read your repo, propose changes, and open them as commits you review.
• Want to work together? You can add a collaborator to a repo (Settings → Collaborators) and invite a partner by username. Then you can both push to the same project and pair on the code live.

Databases 101: where your app remembers things

A database is where structured information lives between visits — users, orders, bookings, messages, settings. If your app needs to remember anything after the page reloads, you need one.

Two flavors, and when each fits

What we recommend for beginners

Supabase is the easiest on-ramp. It's a hosted PostgreSQL database plus login/auth plus file storage — three of our five layers in one friendly dashboard, with a real free tier. For most apps it's the single best first choice because Claude knows it well and it covers data, users, and files together.

Authentication: logins, and who's allowed in

Two words that sound alike and do different jobs. Authentication = "who are you?" (logging in). Authorization = "what are you allowed to see?" (permissions). You almost always need both, and you should never build the password-handling part from scratch — it's a security minefield. Use a proven tool.

Your options, easiest first

Our beginner recommendation

• Already using Supabase for your database? Use Supabase Auth — it's free, included, and connects to your data permissions automatically.
• Want the absolute smoothest setup? Use Clerk — you can have a real login screen working in well under an hour.
• For your users, always offer "Sign in with Google" (and/or GitHub). Social login is the lowest-friction option — no new password for them to forget, and the auth provider handles the security.

Files & storage: sharing the right file with the right person

This is the layer people get confused about most — so let's be concrete, because it's exactly the situation many builders hit: "I want a dashboard where I can post Excel files (or PDFs, images, exports) behind a login, and only certain people can open them."

First: database vs. file storage

So the answer to "what if they just need storage alongside their app?" is: yes, that's a normal, separate piece, and it works hand-in-hand with the database and login.

How "files behind an auth wall" actually works

The pattern is the same everywhere, and it's simpler than it sounds:

1. The file goes into private object storage (it is not publicly linkable).
2. A row in the database records what the file is and who may access it.
3. When a logged-in user clicks "download," your app checks the rules: is this person allowed?
4. If yes, the app hands out a signed URL — a temporary, expiring link that works for that person, for a few minutes, then dies. If no, they get nothing.

That signed-URL step is the whole trick. Files are never just sitting at a public address; access is granted per-person, per-moment, and checked against your permission rules.

The tools, beginner-friendly

Tell Claude that's the shape you want and it can scaffold the whole thing. The point for you is to recognize the pattern — login + permission rules + private files + signed links — so you know what to ask for.

Recommended starter stacks

Rather than choosing ten tools, pick one of these three recipes based on what you're making. Each one is something Claude can set up well.

Five habits that save you real pain

1. Private repos, always. Worth repeating: new GitHub repos go to Private. Don't paste API keys into code that gets pushed.
2. Keep secrets in environment variables. API keys and passwords belong in your host's "environment variables" settings, never typed into the code itself. Claude can show you where.
3. Watch usage-based bills. Railway, Vercel overages, and Supabase egress are usage-priced. Glance at the dashboard occasionally so a viral day isn't a surprise invoice.
4. Free tiers sleep. Free databases and some servers pause when idle. For anything a client relies on, budget the ~$5–25/mo to keep it awake.
5. Ship small, ship often. Commit and push frequently with short notes. If something breaks, you can always step back to a working snapshot.

Mini glossary