How to Get Your First Tool Online

A developer describes how to deploy a first software tool online using AI-assisted workflows. The process involves connecting code in version control, a host, and a domain, with AI tools like Claude or Cursor guiding beginners through each step. The developer notes that AI agents can now handle deployment tasks that previously required manual effort.

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 https://dev.to/mlh/vibe-coding-for-beginners-how-i-built-a-working-photo-booth-web-app-with-claude-8ib 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. Almost every deployment, whatever the tool, comes down to three things working together. 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 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 https://dev.to/mlh/vibe-coding-for-beginners-how-i-built-a-working-photo-booth-web-app-with-claude-8ib 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 https://cursor.com/ , Google Antigravity https://antigravity.google/ , Windsurf https://www.windsurf.dev/ , or VS Code https://code.visualstudio.com/ 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 https://aistudio.google.com/ , 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. 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 https://dev.to/mlh/vibe-coding-demystified-169b sets the stage. 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 https://dev.to/mlh/your-vibe-coded-app-works-is-it-any-good-28co , applied at the exact moment it matters most. Getting a first thing online is a milestone worth not reaching alone. A MLH hackathon https://www.mlh.com/seasons/2026/events is the perfect place to try: build, break, and deploy alongside other people over a weekend. And DEV https://dev.to 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.