VIBECODER: this is the ONLY stack you need

You no longer need a team to build a whole application. You do not really need technical knowledge either (for an MVP).

Just follow these steps. At the end of the guide I explain a few automations you should know about.

Index

1. The whole stack

Before touching anything, look at the map. Claude or ChatGPT write the code. GitHub stores it. Vercel shows the frontend (what people see) and Railway holds your server. Supabase gives you the database and the login (authentication methods). Stripe charges, Resend sends the emails, GoDaddy sells you the domain (you can use another provider), Cloudflare adds the security layer, and PostHog with GA4 show you all the analytics.

The classic vibecoder mistake is spending the week comparing tools instead of building the application. Do not do it. This is what I use in all my applications. Stop wasting time and go build your application.

2. Create the repository on GitHub

The first thing to do is set up the code repository. Create a private repository on GitHub, where your code and every version of it will be stored (so each update stays tracked).

Go to github.com, create the account if you do not have one and hit New repository.

Lowercase name with hyphens, tick Private and add the README.

3. Clone it with GitHub Desktop

Cloning means downloading the repository to a folder on your computer that stays connected to GitHub. For that, install GitHub Desktop: it is the way to use git without learning git, and to start out that is exactly what you want.

Sign in, hit Clone a repository, pick the one you just created and a folder for it to live in. From now on the cycle is always the same: you change things, GitHub Desktop shows you what changed, you write one line saying what you did and you hit Commit and then Push. Changes saved and uploaded, two clicks.

In fact, creating the commit (the message with the files that changed) and the push (uploading to the repository) is something your AI can do too, if you give it the permissions.

4. Claude or Codex (ChatGPT) write your code

This is the part that has really changed: the code is written by Claude Code, or Codex, which is ChatGPT's coding agent. The circuit is the same with both. You open the project, tell it what you want to achieve and it writes the files. Your job is no longer typing: it is explaining well, testing what it gives you and deciding whether it stays.

Installing them takes a minute and both live in the terminal. First you need Node: go to nodejs.org, green button, next, next. After that it is two commands each: one installs, the other starts it inside the project folder. With Claude Code you sign in with your Claude account; with Codex, with your ChatGPT one. And if the terminal is not your thing, both have a web version: claude.ai/code and chatgpt.com/codex.

# Claude Code
npm install -g @anthropic-ai/claude-code
claude

# Codex (ChatGPT)
npm install -g @openai/codex
codex

Two rules that saved me months. One: ask for the plan before the code; have it tell you what it will touch and why, and when the plan makes sense, let it execute. Two: slice it. "Build me the app" goes wrong; "build me the sign-up screen" goes right. After every piece that works, commit, and on to the next.

The code stack, so there is no doubt: I always start with the latest version of Next.js for the application and, when a dedicated server is needed, with Fastify. Tell Claude in the first message and everything it writes is born in the right place.

To avoid starting from a blank page, right below you have the prompt that initializes the project with the full stack of this article. Fill in the gaps at the top, paste it as is and let it ask for whatever is missing.

With this the application runs on your computer, on localhost. The rest of the article is about getting it out into the world.

5. The rules folder: what the project learns

At the root of every project of mine there is a rules/ folder with a few Markdown files, short, concrete and in the project's language:

• architecture.md: which folders exist and what lives in each one.
• components.md: how a component is written in this project.
• styles.md: the styling and class-naming convention.
• conventions.md: the names, the imports and the commits.

The circuit has two halves. Before touching code, Claude reads rules/ in full: that way new code comes out in the project's style, not its own. And before closing the day, it writes down what it learned: the decision that was made, the trap that was found and the why. If a rule changes, the file gets corrected; versions do not pile up.

The rule that holds it all together is one: if you catch yourself explaining the same thing twice, it goes to rules/. A month in, the project has real memory, and every new session starts where the last one ended instead of starting from zero.

And to avoid writing it by hand: the button below has another copy-paste prompt that generates the whole rules/ folder by looking at your project.

6. The frontend goes to Vercel

Vercel is where your frontend stops being localhost. Sign in with your GitHub account, hit Add New Project, pick your repository and press Deploy. Two minutes later you have a public URL like your-app.vercel.app with your application running.

And this is the reason for the whole repository setup: every push deploys itself. You hit Push in GitHub Desktop and Vercel rebuilds and publishes without you doing anything. No servers, no uploading files over FTP like it is 2009. Deploying stops being an event and becomes a habit.

7. Supabase: the login and the database

Almost every application needs two things that are boring to build: letting people sign up and a place to store the data. Supabase gives you both, done. Create the project, copy the two keys it gives you and paste them into your application. Claude knows exactly where they go.

Login with email or Google takes hours, not weeks. And the database is real Postgres, not a toy: what you learn here stays useful forever. The piece you cannot skip is called Row Level Security: the rules that make each user see only their own data. Ask Claude to write them and, above all, to explain them to you before you turn them on.

8. The backend goes to Railway (if you need it)

One warning: you may not need this piece on day one. Plenty of applications live perfectly well with the frontend on Vercel talking straight to Supabase. The backend shows up when you need things that cannot happen in the browser: scheduled tasks, receiving Stripe webhooks, jobs that take minutes.

Why not run the backend on Supabase, since we already use it for the data? Because Supabase does not let you keep a server running: what it offers are Edge Functions, functions that wake up on each request, do their job under a time limit and shut down. Fine for a stray webhook; not for an always-on server with its queues, its WebSockets and its jobs that take minutes.

That is exactly what Railway does give you: a process of yours running all day. It works just like Vercel: you connect the repository, it detects what it is and deploys it, and every push updates it. Same habit, another piece. And the server that goes there, in my case, is always Fastify: light, fast, and Claude knows it by heart.

9. Stripe does the charging

Do you need Stripe? Only if your application charges: a subscription, a one-off payment, whatever. A landing page or a free app does not need this.

Rule number one of payments: you never see a card. The user pays on a Stripe page (Checkout), and Stripe notifies your application with a webhook: "this user paid for this". Your database records who is premium. That is the entire system.

The basic steps, in order:

• Create the account at stripe.com. You start in test mode, no paperwork: real activation comes at the end.
• In the dashboard, create your products with their price: "Pro plan, $9/month" and done.
• Copy the two test keys (the public one and the secret one) into your project's .env.
• Ask Claude for the Checkout and the webhook: it knows them by heart.
• Try the whole circuit with the fake card 4242 4242 4242 4242: it moves no money.
• Everything works? Activate the account with your business and bank details, switch to the real keys and start charging.

10. Emails, with Resend

Your application will need to send email: the welcome, the password-reset link, the receipt. And the temptation is to send them from your Gmail, which you already have. Do not.

Gmail is built for people, not applications: it caps out at around five hundred sends a day, and automated email leaving a personal account is exactly what spam filters are trained to catch. Send a few dozen in a row and you get flagged, and once the account is flagged even your normal email starts landing in spam. On top of that, the customer gets mail from yourname@gmail.com instead of your-app.com, which reads as amateur hour.

Resend exists for this: it sends from your domain, signs every email with SPF and DKIM (the seals Gmail and Outlook check before trusting anyone) and gives you one key, one call and a log of every send. Running your own mail server, by the way, is the wrong hobby.

The step that matters is verifying your domain: a few DNS records that prove the email genuinely comes from your site. You will add them wherever your DNS lives: in GoDaddy as is, or in Cloudflare if you do the step two below. With the domain verified your emails reach the inbox. Without it, spam. That is the entire difference between the password-reset link arriving or not.

11. The domain, on GoDaddy

your-app.vercel.app is fine for showing a friend; for the world you want your-app.com. And it does not have to be GoDaddy: any registrar works (Namecheap, Porkbun, Cloudflare itself); I use GoDaddy and the steps are the same everywhere.

Search for the name, check the domain you like is available and buy it: it goes for about 10-12 euros unless it is specific words or a .ai/.rich, which tend to be the pricey domains.

Now the important part: the cart. GoDaddy will offer you hosting, professional email, premium protection, a website builder and three more things. No, no, no, no and no. Everything you need is already in this stack, free and better. Buy the bare domain and get out of there.

12. Cloudflare, in front of everything (optional)

DNS is the phone book of the internet: when someone types your-app.com, DNS says which server to go to. GoDaddy manages it by default, and that is enough: point the records at Vercel and your site is in production with its SSL, because the padlock comes from Vercel on its own, without moving anything.

So what is Cloudflare for? It is a proxy: if you hand it the domain, your traffic crosses its network before reaching Vercel, and that is where the extra layer lives: protection against attacks and bots, caching and the best DNS panel there is. It is not mandatory; it is the insurance you appreciate the day you hit the front page or someone takes a dislike to you.

If you decide to put it on, the move happens once: create the Cloudflare account, add your domain and it gives you two nameservers, which are two addresses. Go to GoDaddy, paste them where it says Nameservers, and from that moment DNS is governed from Cloudflare with the proxy in front. And if you skip it, no problem: GoDaddy pointing at Vercel and on to the next thing.

13. PostHog and GA4: knowing what happens

Without analytics you are flying blind: you do not know whether people come in, where from, or on which screen they leave. You install both on day one, each is a snippet the tool itself gives you or something you ask Claude for, and they answer different questions.

GA4, the latest version of Google Analytics, answers where people come from: Google, a tweet, a newsletter. PostHog answers what they do inside: which buttons they press, where they get stuck, even session recordings to watch the mouse move. GA4 to decide where to promote yourself; PostHog to decide what to fix. Both free, with plenty of room to start.

Trust me on this one. It takes very little to add and it genuinely gives you a lot of data to make better decisions down the road.

14. Coding from your phone with Claude Dispatch

This was science fiction two years ago. Dispatch is Claude working in the cloud: you send an order from the phone app, a "fix the payment button, it does not respond in Safari", and an agent spins up on Anthropic's servers, reads your GitHub repository, makes the change, tests it and leaves the result ready for review. Your computer can be off: everything happens elsewhere.

Setting it up is short: install the Claude app on your phone, go into the Code part and connect your GitHub account when it asks, choosing which repositories it may enter. From that moment any chat works for ordering: describe the change the way you would describe it to a person and review the result when it pings you.

15. OpenClaw: your agent on your machine

OpenClaw is the homemade version: an open-source agent that runs on your computer and that you talk to over WhatsApp or Telegram, like one more contact. The difference with Dispatch is where it lives: here everything happens on your machine, with your keys and your files, without going through anyone's cloud.

Setting it up, step by step: open the terminal and run the two commands below; the second one is a wizard that asks you everything. When it offers, connect Telegram or WhatsApp by scanning a code, just like WhatsApp Web. And send it a message from your phone to check that it answers. Ten minutes, without touching a config file.

npm install -g openclaw@latest
openclaw onboard

It is basically like having your own virtual assistant available 24/7. It actually works better than Claude Dispatch (based on my own experience).

The important warning: OpenClaw lives on the machine where you install it, and that machine has to be on 24/7. If it shuts down or goes to sleep, your agent shuts down with it and is useless until you turn it back on. That is why people end up putting it on a Mac mini plugged in in a corner, or on a VPS, a virtual server you rent for a few euros a month.

16. Computer-use: let it drive the browser for you

Computer-use is Claude or Codex (ChatGPT) driving your browser: it sees the screen, moves the mouse, clicks and types. And it works for any panel chore, not just one: the DNS records in Cloudflare, setting up products and prices in Stripe or PayPal, checking a deploy on Vercel. All that hopping between tabs copying values, it does while you watch.

Two rules you must ALWAYS follow. Nothing sensitive goes through it: you start the session, and no passwords, no cards, no keys; it finds the panel already open. And always under supervision: you see every click on your screen, and anything delicate, saving, paying, publishing, you confirm yourself after reading what it filled in.

17. MCPs: the plug for your tools

An MCP is a standard connector between Claude and a tool: your database, your repository, your Stripe, your Canva. Instead of copying and pasting between tabs, Claude queries and acts on the tool directly from the conversation. It connects once and stays connected.

The example that makes it obvious is Canva's: "make me the three ad images with the usual template" and they appear in your account, without opening Canva. With GitHub's it reviews your PRs, with Stripe's it pulls this week's payments, with Supabase's it queries your tables. The rule to avoid building a theme park: connect only what you use weekly. Two or three good MCPs beat fifteen installed ones.

Summary

• GitHub first: the repository comes before the code.
• GitHub Desktop: git without learning git.
• Claude writes; you ask for the plan, test and decide.
• The latest Next.js up front; Fastify on the server.
• rules/: read when you start, updated before closing the day.
• Vercel: publishing is pushing.
• Supabase: login and Postgres, done. RLS always.
• Railway: only when something cannot live in the browser.
• Stripe: the webhook is the truth, and test mode first.
• Resend: verified domain or your emails go to spam.
• GoDaddy sells the domain; Cloudflare, optional, adds the proxy.
• PostHog and GA4 from day one: inside and outside.
• Dispatch from the phone: concrete errands, review at the computer.
• OpenClaw at home: the machine on 24/7 or there is no agent.
• Computer-use: any panel, supervised, nothing sensitive shared.
• MCPs: connect only what you use weekly.

Nothing on this list is exotic or expensive: everything starts free and everything is proven across thousands of projects. The difference between having an idea and having an application with a domain, payments and analytics is no longer a team or a year: it is knowing the order of the plugs. Now you know it.

Build it this weekend

My advice is not to read this twice: build it. Saturday morning: repository, clone, and Claude writing the first screen. Saturday afternoon: Vercel and Supabase. Sunday: domain, Cloudflare, Stripe in test mode and the analytics. On Monday you have an application on your own domain, charging in test mode and counting visits.

And before showing it to anyone, two reads that come right after this one: the 9 security skills, so you are not the door they walk in through, and the 13 checks before going to production, so your debut is not breaking it.

And when you have it, send me the link on Instagram. Those messages make my day.