So you’ve done it. You built your first tool. And it works. The button does the thing. Now’s the moment. It’s time to get your tool online, but how? A project running on a laptop is real, but it lives in exactly one place, the machine it was built on. Nobody else can open it.

Getting that project online is its own small skill, separate from building, and it trips up more beginners than the building did. A new coder can finish a working photo booth app in an afternoon and still have no idea how to hand it to a friend short of pulling up the GitHub link while sitting together over coffee. The good news is that the part that used to eat a whole weekend now takes a conversation.

Three Things Every App Needs to Go Live

Almost every deployment, whatever the tool, comes down to three things working together.

• Version control: This is a place to store the code and track every change made to it. For most people that means GitHub, which we’ve talked about before. The same way Google Docs keeps a version history, GitHub keeps one for a project. This piece does not re-explain it; the GitHub walkthrough covers the whole thing.
• A host: A host is really just a computer that stays powered on and connected to the internet with a public address of its own. When a visitor types in the app's address, their browser sends a request across the internet to that machine, the machine runs the code, and it sends the finished page back. A laptop was quietly doing both jobs during the build, the server and the only visitor allowed in; a host is that same server moved onto an always-on machine the whole world can reach. Services in this category include Cloudflare Pages, Render, Vercel, Netlify, and they often have a free tier that is plenty for a first project. But do your research on what restrictions come with that tier and think about whether they hold you back more than you want.
• An address: The domain people type to find the app. A host hands over a working web address on day one. A custom domain is an optional upgrade that swaps something generic for a name the builder owns, which can give you more control over how people perceive your tool (aka branding). Custom domains typically cost a few dollars a year and can be purchased on services like Hover, Netlify, Vercel, Cloudflare, Dreamhost, Porkbun, and GoDaddy.

Going live is mostly the act of connecting these three. The code lives in version control, the host reads from it, and the domain points at the host. Three things to check off a to-do list and you’re live!

The Path of Least Resistance When You’re Building Your First Tool

The simplest way to get started just requires a chat window. You describe what you want, the AI writes the code, and a back-and-forth shapes it into something that works. That is exactly how the photo booth project came together. Getting it online publicly is the same move, continued. The builder asks how to put the project on the internet, and Claude would have handed back a short list of steps: download the code to your own machine, create a GitHub account and push the project to it, then connect that repository to a host. Each step is something the builder runs themselves, with the AI explaining the unfamiliar parts as they come up.

On this path, the person is the courier. The code travels from the chat, to their computer, to GitHub, to the host, and the software creator carries it across each gap by hand. It sounds like more work than it is. Another example from one of DEV’s co-founders described a friend with no technical background who got a full website live exactly this way, using nothing but a consumer AI chat. He described what he wanted, followed the numbered instructions, and it worked. The courier path is the whole job for plenty of first projects, and it asks for no new software beyond a browser and an account.

The step up from there is an editor with a built-in agent like Cursor, Google Antigravity, Windsurf, or VS Code with a coding extension. These are code editors with an AI agent living inside them, and the difference is the responsible party for getting things from place to place. Instead of the software creator shuttling code between windows, the AI agent edits the project files directly and runs the GitHub and deploy steps independently. The flow looks like this: start in a conversational build tool like Google AI Studio, describe the thing in plain language, tweak it until it looks right, then open the code in the editor. From there it is a conversation. Connect to GitHub. Pick a host. When it is time for a custom domain, tell the agent where the domain was purchased and ask which fields to update.

That last detail is the real shift, and it holds on either path.

What makes deployment to life intimidating is rarely the concepts. It’s a dozen tiny configuration fields with names a beginner had never seen…and in their mind, each one is a chance to get something wrong. Now those fields come with a guide that explains each one on request, whether that guide lives in a chat window or inside the editor.

AI Editor or Terminal?

A common fork shows up here. You can do this through a visual editor, or through the terminal, the black command-line window many beginners dread simply because they haven’t used it before, and it looks like you could do real damage if you mess up. For a first deploy, the editor usually wins, and the reason is as much psychological as technical.

In an editor, a beginner can see the files and watch the changes happen. The terminal gives back only text, and when something goes wrong it can feel like a black box. Seeing the project is more grounding, and grounding is what keeps a first-time developer in the chair instead of closing the laptop.

Don’t fear the terminal. It’s worth learning eventually. It does not have to be day one. For more on how this conversational, agent-led way of working took hold, the vibe coding explainer sets the stage.

Don’t Hit Deploy With the Door Open

The moment an app goes live, it stops being private. So this is a valuable moment to stop, review, and check all your work.

Anyone can reach a live thing, including people looking for an unlocked database to exploit. There are real news stories, more than one in the past year, about apps that shipped with their data wide open and leaked every user’s information within hours of launch.

Senior builders run a pre-flight checklist before every launch for exactly this reason. A beginner does not need a hundred items, but they do need the habit. Some AI coding tools now run a basic security pass on their own and will flag an exposed database before it ships. The rest is asking the right questions. What did this skip? What would a real product lock down? Is anything sensitive sitting somewhere public? That is the same build-then-audit move covered in the auditing guide, applied at the exact moment it matters most.

Where to Build This With Other People

Getting a first thing online is a milestone worth not reaching alone. A MLH hackathon is the perfect place to try: build, break, and deploy alongside other people over a weekend. And DEV is always here for the other parts, open all the time, where a new coder can post the project, ask for feedback, and read how someone else cleared the same hurdle.

(The thing that goes live is better for having an audience that was rooting for it.)

FAQ

Do I need to know how to code to deploy an app?

No. A non-technical person can get a site live using a consumer AI chat that hands over step-by-step instructions. Knowing the underlying concepts helps later, especially for security, but it is not a barrier to a first deploy.

What is the difference between GitHub and a host?

GitHub stores the code and tracks its changes. A host runs the code and serves it to visitors. They are two different jobs, and a typical setup connects them so the host reads the latest code from GitHub. More on version control in the GitHub walkthrough.

Do I have to buy a domain?

No. A host provides a working web address as soon as the app is live. A custom domain is an optional upgrade for a name the builder owns for a few bucks a year.

Do I have to use the terminal?

Not for a first deploy. An editor with a built-in AI agent is friendlier and easier to follow, because the files and changes stay visible the whole way through.

What is the most common first-launch mistake?

Going live without checking security, especially leaving a database open to the public. A quick audit before deploying prevents the worst of it. See the auditing guide.