I built my MVP with Claude Code. Now I need to deploy it. Here's what nobody tells you.

Disclosure up front: I'm a senior backend tech lead by trade and I run HostingGuru, one of the platforms mentioned at the end. I tried to make this useful even if you pick something else.

In 2026, a strange thing has happened. Hundreds of thousands of people who couldn't write a for loop two years ago are now shipping working software. They open Claude Code, Cursor, Lovable, or Bolt, describe what they want, and a few hours later they have a working app on their laptop.

I've watched this from up close. Friends who run agencies, founders who used to pay €30k for an MVP, business school grads with no engineering background — they all show me the same screen: a Mac terminal, an app running on localhost:3000, and a face that's half pride, half panic.

The pride: "I built this myself."

The panic: "How do I put it on the internet?"

That panic is what this post is about. Because the gap between "it works on my laptop" and "people can use it from a phone in another country" is wider than you think — and almost no one is writing for the person facing it for the first time.

The deployment cliff nobody warns you about

Building software with AI got 10x easier in 2 years. Deploying it didn't.

When you ask Claude Code to build a feature, it works. Maybe not perfectly, but it works. When you ask it "how do I deploy this?", you get one of three answers:

1. A list of commands that assume you already know what Docker is
2. A reference to "your hosting provider" — implying you have one
3. A polite suggestion to "consult your DevOps team"

You don't have a DevOps team. You don't have a hosting provider. You have a laptop and a working app and a launch date.

This is the deployment cliff. It's the moment where the AI assistant that taught you to code stops being useful, because deployment is half technical knowledge and half operational vigilance — and operational vigilance is exactly what AI is worst at.

The four things you actually need

Stripped of jargon, putting an app on the internet is four things:

1. A computer that's always on

When your app runs on localhost:3000, your laptop is the computer. The moment you close the lid, the app is gone. To stay online 24/7, your code needs to live on a computer that someone else keeps running. That's hosting.

2. An address people can type

localhost:3000 only works for you. To let other people in, the computer needs a public address — usually a domain like myapp.com. You buy this from a registrar (Namecheap, OVH, Gandi). Then you point it at the computer.

3. A place to store your secrets

Your app probably has API keys — to OpenAI, to Stripe, to whatever payments service you're using. These can't live in your code (anyone could see them). They live in environment variables — a secure storage that your hosting platform provides.

4. A way to know when something breaks

This is the one nobody mentions. Once your app is live, things break. APIs go down, retries fail, payments don't go through. The question isn't whether something will break — it's whether you'll know about it before your users do.

That's what monitoring is. It's the layer that watches your app and tells you when something's wrong.

If you're a non-technical founder, item #4 is the part that will quietly kill your launch. Not because the bug is hard to fix, but because you won't know it happened. Three days later a user emails "hey, your signup form has been broken since Tuesday" and you realize you've lost 70% of the people who tried to sign up.

Why most platforms aren't built for you

Now you Google "deploy app" and you hit a wall of options. Heroku, Vercel, Render, Railway, Fly.io, AWS, Google Cloud, DigitalOcean. Let me save you the research:

AWS, Google Cloud, Azure: Skip. These are infrastructure-as-toolboxes. They're powerful and cheap if you're willing to spend three weeks learning them. You're not. Don't even click.

Heroku: Was the easy answer for a decade. Entered "sustaining engineering mode" in February 2026 — meaning the company stopped shipping new features. Still works, but the trajectory is downward and the free tier is gone.

Vercel, Netlify: Great for frontends. If your app is purely a Next.js / React / static site, these are excellent. The moment you have a backend (a Node.js API, a Python script, a database connection), you're going to fight against the Serverless Functions abstraction. If you're not technical, this fight will exhaust you.

Render: The closest to old Heroku. Solid product. The catch: the free tier sleeps after 15 minutes of inactivity. Cold starts are 30 seconds. For a demo or a small product, that's a problem — your users see a blank screen for 30 seconds and many leave.

Railway: Slick UX, usage-based pricing. Good for small projects. The catch: usage-based billing is fair when traffic is small and surprising when traffic spikes. A runaway script can produce a 4-figure bill quietly.

Fly.io: Powerful, multi-region. Requires a fly.toml config file you'll have to learn to write or paste from documentation. Fine if you're a developer, more friction if you're not.

Self-hosted (a VPS on OVH/DigitalOcean + something like Coolify): Cheapest. You manage the server: OS updates, security patches, backups, SSL renewals, monitoring setup. Everyone tells you it's "not that hard." It actually is — when you're trying to focus on your product, not on Linux.

You see the pattern. Every option assumes you know one or two things you don't yet.

What "deploying for non-developers" actually needs to look like

Here's the honest list of what someone shipping their first AI-built MVP needs:

• One simple action: connect your GitHub repo, click deploy. No fly.toml, no Dockerfile, no YAML, no terminal commands.
• A free tier that doesn't sleep: because if you're showing a demo to your first 10 users and the site takes 30 seconds to load, you've lost the demo.
• Domain + SSL handled for you: you should never have to type certbot. Type your domain, the platform deals with HTTPS.
• Environment variables in a clean UI: paste your API keys, save, done.
• Monitoring built in, not bolted on: when something breaks at 3am, the platform should tell you. Ideally on a channel you actually check (Telegram, email, Slack).
• Predictable pricing: a flat monthly tier. €19, €29, whatever. Not "usage-based" that surprises you. You know your bill before the month starts.
• A human you can ask: when you're stuck, you don't want a 200-page documentation site. You want someone who replies in a Discord or by email and says "oh, paste this in your env vars."

The platforms above each tick some boxes. None tick all of them, with one exception I want to be honest about.

What I built (and why I built it)

I'm a senior backend tech lead. I've shipped production systems for BeReal, Oney, Ringover. I've watched hundreds of friends try to deploy side projects and either give up or burn money on infrastructure they don't need.

So I built HostingGuru — a managed PaaS positioned exactly at this gap. It's not the cheapest. It's not the most powerful. It's the one I'd want my non-technical friends to use:

• Free tier that never sleeps. Your demo stays online, period.
• Connect GitHub, hit deploy. No Dockerfile. No YAML. No CLI required.
• 14+ frameworks supported out of the box: Next.js, Django, Rails, FastAPI, Express, Go, Rust, plus Docker if you want it.
• Built-in AI monitoring with Telegram alerts. It tails your production logs and pings you when something looks off — retry loops draining your tokens at 3am, anomalous error spikes, response time degradation. This is the feature I'm proudest of, because it's the one most often missing.
• EU + US data centers (Germany + Oregon). ISO 27001, GDPR-compliant. Important if your users are in Europe.
• Predictable pricing. €19/mo Hobby (3 services). €35/mo Pro (10 services, custom domains, encrypted env vars, background workers).
• Human support. I read every Discord message myself.

For non-technical founders specifically, we also offer white-glove setup for the Hobby tier: you tell us your repo, we set up the deployment and the domain, and you start with a working app. €19/mo + a one-time setup. You touch nothing.

If you're shipping your first Claude Code or Lovable app and you've been staring at AWS pricing tables for an hour, this is built for you.

What to do next, regardless of which platform you pick

Whether you go with HostingGuru, Render, Railway, or anything else, this is the order of operations that won't get you stuck:

1. Push your code to GitHub. If you don't have a GitHub account yet, make one. Every modern platform deploys from there.
2. Pick a platform that matches your tech. Next.js → most platforms work. Django/Rails → Render or HostingGuru. Static site → Netlify or Vercel.
3. Buy a domain. Cheapest from Namecheap or OVH (€10–15/year). Don't buy through your hosting platform — domains and hosting should be separate, so if you ever switch hosts you keep the domain.
4. Set up environment variables BEFORE deploying. Look at your .env file (the one you don't push to GitHub). Every line in there needs to be set on the platform.
5. Deploy a "hello world" version first. Not your full app — just confirm the platform can build something. Then add complexity.
6. Set up monitoring on day one. Even just an UptimeRobot ping every 5 minutes to your homepage. You want to know when the site is down before users tell you.
7. Set up alerts on a channel you check. Email is fine. Telegram is better. Slack if your team uses it. Not an internal dashboard you'll forget exists.

That's it. That's the whole thing. The first time you do it, it'll take an afternoon. The second time, twenty minutes.

A note on Claude Code specifically

If you built your app with Claude Code, you have one big advantage: the codebase tends to be cleaner and more conventional than what a beginner would write by hand. Most modern PaaS platforms can deploy it without modification, because Claude tends to use standard project structures (a clear package.json, a sensible requirements.txt, environment variables already factored out).

What you should not do: ask Claude Code to "deploy this for me." It can't. Deployment requires real-time interaction with the platform's API or dashboard, which an AI agent can't reliably do unattended yet. Claude Code is for building. Deployment is for you (or for a managed service that handles it on your behalf).

Closing

If you're reading this because you finished your first MVP last weekend and your laptop is uncomfortably warm, congratulations. The fact that the deployment step feels overwhelming is a sign you're about to learn something most engineers spent years learning. You'll do it once, it'll feel impossible, and then it'll be done.

If you want to skip that learning curve and have someone do it for you while you focus on the product, we offer that — that's HostingGuru. If you want to do it yourself with maximum DX, Render is also a great call. Either way: don't let the deployment step block your launch. Pick a platform tonight, ship something visible tomorrow.

What did you build? I'm curious what people are shipping with Claude Code these days. Drop a link in the comments.

If you found this useful, the previous post in this series was "Heroku just went into 'sustaining engineering mode'. Here are 5 alternatives whose free tier actually doesn't sleep" — a comparison of 5 PaaS options for the developer side of the same question.