You Built an App With AI. Now What?

The demo worked. You described what you wanted, the AI built it, and there it is on your screen — a real, working application. That part genuinely is as easy as it looked.

Then you try to show it to someone else, and the questions start. Where does it live? What happens when you close your laptop? Where does the data go? Why is it asking for a "connection string"?

This is where a lot of people stall. Not because it's hard, exactly, but because it's a set of unfamiliar problems arriving all at once, in vocabulary nobody explained. Here's the map.

What you actually have right now

Almost certainly one of two things.

A preview inside the tool that built it. Lovable, Replit, Bolt, v0, Claude artifacts — all of these run your app on their infrastructure so you can see it. That preview is not a deployment. It may sleep, it may reset, and it usually isn't built to serve real users.

Code on your computer. Files in a folder, running when you start it and stopping when you don't. Nobody else can reach it. localhost means "this machine only."

Either way, the code existing is roughly half the job. The other half is everything that keeps it running when you're not watching.

The five things that have to be true

Any real deployment needs these, no matter which platform you pick.

1. A computer that stays on

Your app needs to run somewhere permanent. That's what hosting is — renting a computer that doesn't sleep and has a public address.

Sounds obvious, but it explains a lot of confusion. When people say "it worked yesterday and now it's down," it's often because they were relying on a preview environment that was never meant to stay up.

2. Somewhere to keep data that isn't the app

This is the one that catches almost everyone.

Your app and your data are separate things. If they're not, every time you update the app — every redeploy — you lose everything users entered. This is the single most common catastrophic mistake in AI-built apps, and it usually surfaces the first time someone ships a fix.

You need a database: separate, persistent storage that survives redeploys. PostgreSQL is the sensible default. A managed one means someone else handles backups and updates.

When your app asks for DATABASE_URL, it's asking where that database lives. A managed platform fills that in for you.

3. Secrets that aren't in your code

Your app probably has API keys — for payments, email, the AI service itself. If those are written directly in the code, then anyone who sees the code has them. If the code goes on GitHub publicly, bots find those keys within minutes. This is automated and constant.

They belong in environment variables: values you set on the platform, separate from the code, never committed to git.

Worth knowing: AI-generated code has a documented habit of hardcoding credentials and defaulting to broad database permissions. It's not being careless on purpose — it's producing the shortest thing that works. Check for this specifically, because nobody else will.

4. HTTPS

The padlock. Without it browsers show warnings, logins are interceptable, and payment providers refuse to work with you.

The certificate that provides it is free (Let's Encrypt) and expires every ninety days. Any decent platform issues and renews it automatically and you never think about it. If a host asks you to manually install certificates in 2026, pick a different host.

5. A domain people can type

your-app-x7f2.some-platform.dev works but doesn't inspire confidence. A real domain costs about $10–15/year and gets pointed at your app through DNS settings.

Do this last. It's the easiest step and the least urgent.

The options, honestly

Deploy inside the tool that built it — Lovable, Replit, and similar have a deploy button, and for a prototype or an internal tool this is genuinely the fastest path. The trade-off is lock-in and limited control when you outgrow it.

A deployment platform — Vercel, Netlify, Railway, Render, Fly. You connect a GitHub repo and they build and host it. Vercel and Netlify are excellent for frontends; Railway and Render handle databases and backends more naturally. Expect $5–20/month for something small.

A managed development platform — the app and the environment it's developed in live in one place, so the AI can keep working on it after it's live. Useful when you expect to keep iterating rather than ship once. (This is what EasySpawn does.)

A VPS — DigitalOcean, Hetzner, a raw Linux box. Cheapest and most flexible, and you are now responsible for security updates, backups, web server configuration, and certificates. If you're reading this article, this is not your starting point.

What to expect it to cost

Roughly, for a small real app:

Item	Typical
Hosting	$5–20/month
Managed database	$0–15/month (often bundled)
Domain	$10–15/year
SSL	Free

Sub-$25/month is normal for something small and real. Free tiers exist and are fine for testing — they typically sleep when idle, which is a bad surprise if you've shared the link with someone.

The thing that actually costs money later is traffic and storage, and if you get there, that's a good problem.

The mistakes worth avoiding

1. Assuming the preview is a deployment. It isn't, and it will disappear.
2. Storing data inside the app. Redeploy, data gone. Use a real database from day one.
3. Committing API keys. Bots scan public repos continuously. Rotate anything you've exposed — don't just delete it.
4. No backups. "The database is managed" doesn't always mean "someone is backing it up." Check.
5. Skipping HTTPS. Non-negotiable if there's a login or a payment.
6. Shipping AI-generated auth or payments unreviewed. Everything else, ship and iterate. These two are where mistakes are expensive and irreversible. Use a known provider — Stripe, Auth0, Clerk — rather than something bespoke.
7. Not using git. Version control is your undo button. Without it, one bad AI edit can destroy work with no way back.

A reasonable order to do this in

1. Get the code into a GitHub repository. Everything else assumes this, and it's your safety net.
2. Move secrets out of the code into environment variables.
3. Pick a platform and connect the repo.
4. Add a managed database; set DATABASE_URL.
5. Deploy. Confirm HTTPS works.
6. Test the whole flow on the live URL, not locally.
7. Point a domain at it.
8. Verify backups exist and that you know how to restore one.

Steps 1–5 are an afternoon. Nobody gets through them without something failing — that's normal, and the error messages are usually more literal than they look.

The honest summary

Building the app was the part AI made dramatically easier. Everything above is the part it made look easy, and it's mostly plumbing: a machine that stays on, a database that survives redeploys, secrets kept out of code, a certificate, a name.

You can learn all of it, or pick a platform that handles it. Both are legitimate. What isn't legitimate is hoping it doesn't matter — that's how people lose their users' data on the first update.

---

EasySpawn is a managed platform where the app and the environment it's built in live together: managed PostgreSQL, automatic SSL, environment variables, daily backups, and deployments handled for you. We're pre-launch — join the waitlist.