Vibe Coding for Non-Coders: From Idea to Live App

An hour of typing plain English is enough to put a real web app on the internet. The video below starts on a completely blank Windows machine, nothing installed, not even the basic developer tools, and ends with a working image converter live at its own domain: drag in a JPEG, get a PNG back, pick the quality, download everything as a zip, install it on your phone, sign in and see your conversion history. Not one line of code gets written by a human.

This article is the SOP version of that session. Every step, every service, every gotcha, in order, so you can run the same play with your own idea. If you'd rather watch first, here's the full recording on Loom, or right here:

The stack, and why you shouldn't get creative with it

Claude Code learned to program from enormous amounts of public code, and Next.js, Supabase and Vercel are everywhere in that material. That makes the model unusually good at them. Pick something exotic and you're fighting uphill for no reason. So every project, no matter what it does, starts with a prompt shaped like this:

I want to code a web app for [what it does]. I want to use Next.js. I want to use Supabase for the database and authentication, if they are required. I will deploy to Vercel.

You don't need to understand those names yet. Next.js is the framework the app gets built with, Supabase provides a database, sign-in and file storage when you need them, and Vercel is where the app runs once it's public. For the converter in the video, Claude Code actually pushed back: image conversion can happen entirely in the browser, so version one needed no database at all. Let it make that call. The prompt exists so it never wanders off into something obscure.

Here's the whole route condensed into one interactive map. The rest of the article walks each stop in detail.

Set up: VS Code, a Claude plan, one extension

Three one-time things.

First, VS Code, a free code editor from Microsoft. Install it with the defaults, skip the sign-in prompts, and close the AI chat panel it opens on the right. You won't use it; think of VS Code as a nice text editor that Claude will work inside.

Second, a Claude subscription, which is what actually does the coding. Pro is $20 a month and plenty to start with. If you end up coding for hours every day you'll outgrow it, and the Max plan comes in two sizes, $100 and $200 a month, for roughly 5x and 20x the usage. Prices localize by country, so check the current numbers at claude.com/pricing. Inside the extension you can open Settings, then Usage, and watch your consumption; upgrade when you keep bumping into the ceiling, not before. Heavier models and higher effort settings burn quota faster, so if limits bite early, a lighter model stretches the plan.

Third, the extension itself. In VS Code, open the Extensions panel in the left sidebar, search for "Claude Code", install it, and sign in with your Claude account. It bounces you to the browser once, you click Authorize, and you're done. The Claude Code docs cover the details if anything looks different by the time you read this.

Keep a second Claude window open

Before you write a single prompt, open claude.ai in a browser tab and leave it there for the entire session. This tab is your glossary, kept deliberately separate from the coding session.

In the video that one tab ends up explaining Postgres ("think of it as a very strict, very fast spreadsheet your app talks to"), environment variables, the difference between Git and GitHub, and what an SMTP provider is. The rule is simple: the VS Code session builds, the browser tab teaches. Whenever Claude Code asks you a question you don't fully understand, or uses a term you've never seen, paste it into the chat tab and ask for a plain-English explanation with pros and cons. Don't hijack the coding session with vocabulary questions; the answers are better when Claude isn't mid-task, and your build keeps moving in the background while you learn.

The first prompt and the build

Create a dedicated folder before anything else: something like C:\code\jpeg-png in File Explorer, one folder per app. In VS Code go to File, Open Folder, select it, and click Trust when the restricted-mode banner appears. Open the Claude Code panel, start a new session, and type the tech-stack prompt with your app description.

Two settings matter before you let it loose. Flip the approval toggle from Manual to Auto, so it only interrupts you for genuinely risky actions instead of every single edit. And set the effort slider to taste; higher effort produces better code and consumes more of your plan.

Expect a scoping question almost immediately. For the converter, Claude Code offered three versions: pure browser conversion with no accounts, the same plus optional sign-in and history, or full upload-and-store. Always pick the simplest one. Version one should exist as fast as possible; complexity is a later prompt.

On a fresh machine the first build also installs Node, the runtime everything depends on, and Windows will pop its "allow this app to make changes" dialog once or twice. Approve them. This never happens again.

One more thing worth normalizing: sometimes it wedges. In the video it went silent mid-scaffold for a few minutes. The fix was pressing stop and typing "you seemed stuck, what happened?" It investigated, admitted it had bundled three operations into one fragile command, repaired the damage, and noted the lesson for next time. That exchange is routine, not a crisis.

See it run before you ship it

Press Ctrl and the backtick key (the one under Escape) to open VS Code's terminal, type npm run dev, and hit Enter. That starts a development server, and a few seconds later you get a localhost:3000 link you can Ctrl+click to open in your browser.

This URL exists only on your machine while the server runs. Nobody else can see it, which makes it the right place to be ruthless: drag real files in, click every button, and feed it something wrong on purpose. The converter correctly rejected a .txt file with a visible error message instead of silently swallowing it, which is exactly the kind of thing you want to confirm before strangers show up.

If the terminal complains that npm is not recognized, your terminal was opened before Node finished installing. Restart VS Code and run it again. When something breaks that you don't understand, don't debug it yourself: copy the error, paste it into Claude Code, and let it sort itself out.

Git, GitHub, Vercel: making it public

The mental model that makes this whole section click: Git is like the version history in a document editor, and it runs entirely on your computer. GitHub is like Google Drive for that history, a copy in the cloud so your work survives a dead laptop. Vercel watches your GitHub repository and serves the app to the world.

So the sequence is: create a free account at github.com and make a new repository. Set its visibility to private; there's no reason to publish your source. Then go back to Claude Code and type "commit and push to" followed by your repository's URL. It installs Git if needed, makes the first commit (a local save point), and hands you one command to run in the terminal. That command opens a browser window where you authorize Git Credential Manager against your GitHub account, a one-time step. Every future "commit and push" just works.

Deployment is the easy part. Create a free hobby account at vercel.com, click Import Git Repository, continue with GitHub, authorize it, pick your repo, and hit Deploy. Under a minute later your app is live at a your-app.vercel.app URL that anyone on earth can open. From this point on, shipping an update means telling Claude Code "commit and push"; Vercel redeploys automatically on every push.

A domain of its own

A vercel.app subdomain works, but a real domain costs about $10 a year and changes how the whole thing feels. Buy it on Cloudflare, not on Vercel, for two reasons: Cloudflare is cheaper, and it's a proper registrar, so later you can hang email sending, storage and other services off the same domain. Vercel isn't built for that.

Once you own the domain, go to your Vercel project, then Settings, then Domains, and add it. Vercel responds with a short list of DNS records, a couple of CNAMEs and TXT entries. Copy each one into Cloudflare's DNS panel for your domain, exactly as shown, with the proxy toggled off. Back in Vercel, hit refresh until every record shows a green check.

The word exactly is doing real work there. In the video, a single typo ("converter" instead of "convert") sent every sign-in link to a page that didn't exist. Copy and paste, never retype, and if a record refuses to verify, screenshot both dashboards and paste them into Claude Code.

Install it on your phone

One prompt covers this entire upgrade: "I want to be able to use the app on my phone with a nice icon, so I can install it from the browser. Also make the icon the favicon, I don't want Vercel's icon in the browser tab."

The term of art here is PWA, a progressive web app. Claude Code adds a manifest, generates icons, and wires up a small service worker so the app even works offline. After it commits and pushes, open your domain on a phone, tap the browser's three-dot menu, and choose Add to home screen (or Install). You get an icon, a name, and an app that opens full screen and survives airplane mode. If you care about the logo, generate one you like first (any image tool works), save it in the project folder, and tell Claude Code the filename before this step.

Accounts, saved history, file storage

Now the version-two prompt, the one you deliberately postponed: "I want to keep the app free for anonymous use, but add sign-in so logged-in users get a history of their conversions and can re-download past files. Use Supabase for the database, the auth, and the file storage."

Claude Code will surface a real product tension before writing anything, which is worth pausing on. The converter's selling point was "your images never leave your device", and storing files breaks that promise unless it's explicit. The resolution it proposed, and the right default: conversions stay local even when signed in, and only an explicit Save button uploads anything. Its other two questions got sensible defaults too: magic-link sign-in (an emailed link, so no passwords and no forgot-password flow to build) and storing both the original and converted file so users can re-convert later.

The setup is almost entirely hands-off. Create a free account at supabase.com but don't create a project; when Claude Code asks, run npx supabase login in the terminal and paste the code from your browser. It then creates the project itself, in a region near you, along with the tables, the storage bucket, and the security policies, and writes the secret keys into a local .env file without ever printing them on screen.

Two manual chores remain before sign-in works in production, and Claude Code will spell out both:

1. In Supabase, under Authentication and then URL Configuration, set the Site URL to your real domain and add it to the redirect URLs. Otherwise every magic link bounces users back to localhost.
2. In Vercel, under Settings and then Environment Variables, paste the two NEXT_PUBLIC Supabase values (Claude Code hands them to you; anything prefixed NEXT_PUBLIC is safe to expose, so untick Sensitive). Then trigger a Redeploy, because env vars only take effect on a fresh build.

Email that actually arrives

There's a trap waiting at the end, and it's better to disarm it before real users find it. Supabase's built-in email sender allows roughly two emails per hour across your whole project. It exists for development only, so the second person who tries to sign in gets "email rate limit exceeded" and gives up.

The fix is an SMTP provider, a service whose entire job is getting email delivered instead of spam-foldered. Claude Code suggested Resend, which has a generous free tier; the video used Postmark, which has a free plan of 100 emails a month and a very good reputation for transactional email (sign-in links, receipts, resets). Either works, and the wiring is the same shape:

1. Create the account and a server, then add a sender signature for your domain.
2. The provider gives you two DNS records (a DKIM TXT and a CNAME). Add them in Cloudflare, wait a minute, verify.
3. Copy the SMTP credentials (host, port 587, and an API token that doubles as username and password) into Supabase under Authentication, Emails, SMTP Settings, with a sender like noreply@yourdomain.com.

From then on magic links arrive from your own domain, branded, fast, and with a delivery log you can actually inspect when someone claims they never got the email.

When it gets stuck, and what this actually costs

A few working rules carried the entire session, and they generalize to any project. Paste every error verbatim into Claude Code instead of trying to interpret it. Screenshot any dashboard where the instructions don't match what you're seeing, and paste the screenshot. When it stalls, interrupt and ask what happened rather than waiting. And never fix by hand what a ten-second message can fix for you.

The one thing no model does for you is knowing what you want. The video worked because a throwaway demo can let Claude make every product decision. Your real app can't. Before the first session, write down the features, the screens, and how things should behave, even roughly, and feed precise instructions instead of shrugs. Vague in, generic out.

The bill for everything above: about $10 a year for the domain, plus the Claude subscription. GitHub, Vercel, Supabase, Cloudflare and Postmark all have free tiers that comfortably cover a first app with real users. That converter from the video runs on exactly that stack, at exactly that cost, and it didn't exist an hour before it went live.

---

Further reading

• The full video walkthrough on Loom
• Claude Code documentation
• Claude plans and pricing