Shipping for real: databases, domains, deployment
Moving past the prototype: what a database actually gives you, how deployment works, and how to put your project on a custom domain.
9 min read · Last verified
There's a moment when a project stops being a demo and starts being a thing people use. It usually arrives with three needs at once: data has to survive a refresh, the app needs a grown-up address, and "I'll re-deploy it when I remember" stops being acceptable. This guide is those three topics, minus the folklore.
Databases: where your app's memory lives
The tell that you need one: information vanishes on refresh, or exists only in one user's browser when it should be shared. Variables and browser storage are short-term memory; a database is the durable, shared kind — a structured store that lives on a server, holding tables of rows (users, posts, scores) that every visitor reads and writes through your app.
What you actually need to decide:
- Which one? For vibe coders the popular answer is a hosted platform — Supabase (Postgres, plus auth and file storage; generous free tier, and what VibeStar itself runs on) or similar services like Neon, Turso, or Firebase. Hosted means no server maintenance, dashboards instead of config files, and free tiers that comfortably cover a launch. Some app builders bundle one in — that's fine too until graduation day.
- What's the shape? Before asking the AI to wire it up, describe the data in plain words: "The app stores users. Each user has many playlists. Each playlist has many songs, each with a title and a link." That paragraph is your schema design — the AI translates it into tables.
- Two non-negotiables the moment real users appear: access rules enforced by the database itself (RLS — the heart of the security checklist), and knowing where the backup/restore button is in your platform's dashboard before you need it.
One habit that will save you: when the AI changes the database's structure, have it write the change as a migration — a saved, ordered script — rather than clicking things in the dashboard by hand. Migrations put your database's history in git alongside your code, where you know how to rescue things.
Deployment: from "works here" to "works everywhere"
Deployment is copying your app to computers that serve the internet. The modern setup, in one sentence: push code to GitHub → the hosting platform notices, builds, and ships it — automatic on every push, forever.
- Hosts: Vercel and Netlify are the defaults for web apps (free tiers fine for launch). App builders handle this internally with a Publish button — the GitHub flow is what replaces that button when you leave the sandbox.
- Environments: your app now runs in two places — your machine (development) and the internet (production) — and they need different settings, especially secrets. That's what environment variables are: per-environment configuration entered in the host's dashboard, not written in code. When something "works locally but breaks in production," a missing environment variable is suspect number one.
- The habit: deploy early, not at the end. A boring half-finished app that's live beats a polished one that's never left your laptop — because every subsequent push is verified against reality, one small change at a time.
Custom domains: your project's real name
encore-o-matic.vercel.app works; encore-o-matic.com gets remembered.
The mechanics are simpler than their reputation:
- Buy the name (~$10–15/year for a
.com) at a registrar — Cloudflare, Namecheap, Porkbun are the usual suspects. - Connect it: in your host's dashboard, "Add custom domain." It hands you one or two DNS records — think of DNS as the internet's contact list, and the records as telling it "this name points to that server." Paste them into your registrar's DNS page.
- Wait a bit (minutes usually, occasionally hours) and — that's it. HTTPS certificates are automatic on modern hosts. If your app sends email or handles logins, ask the AI: "we moved to a custom domain — what settings and DNS records need updating?" (Auth redirect URLs and email-sending records are the classic stragglers.)
The full stack, assembled
Database + auto-deploy + domain is the complete kit: data that persists, shipping that's automatic, an address that's yours. Congratulations — you now operate infrastructure, and what you build on it is entirely your problem in the best possible way.
Two closing moves: run the security checklist now that data and domains are real, and — since it's on an easy-to-share URL anyway — the gallery is right there.