Vibe Coding for Amateurs

A Complete Workflow from Idea to Production for Non-Technical Founders

"Amateur" comes from the Latin amator, the one who loves. It is not an insult. It is the person who builds something because they care about it, not because it is their job. Coding agents gave amateurs a real workshop for the first time. A physiotherapist can build the booking tool they always wanted. A football coach can build the training planner their club needs. A shop owner can replace three spreadsheets with one app.

The workshop is real, but it has sharp tools. Without a method, the first weeks feel like magic and the next months feel like quicksand. Every new feature breaks an old one, nobody knows where the data lives, and the agent starts to "fix" things by deleting them.

This post is the method I give to friends who ask. It has five steps: Setup, Planning, Building, Improving, Deploying. Each step names tools that are free or cost about the same as a lunch per month.

Private Tool or Commercial Product?

Before the first prompt, answer one question: who will use this?

A private project serves you, your family, your team or your club. The users are people you know. If it breaks on a Sunday, you fix it on Monday and they forgive you. You can vibe code a private tool from start to finish, and that is a good result.

A commercial product serves strangers who pay, or who trust you with their data. Here the software is only one part of the solution. The rest is:

• Legal: terms of service, a privacy policy, GDPR, invoices, sometimes regulation of your sector.
• Support: somebody answers the email when a customer cannot log in.
• Operations: backups, monitoring, updates, somebody who wakes up when the server is down.
• Sales and marketing: the product does not sell itself.

A vibe coded product can prove that the idea works. It can find the first customers and pay the first bills. But if it succeeds, it will need a professional team. That is not a failure, it is the plan. The goal of this workflow is to make that handover smooth: a team that opens your repository should find a documented, tested, consistent project, not a pile of generated code that they must rewrite.

Every step below produces something that the future team will read. Keep that in mind and the handover is already half done.

1. Setup

Setup is about the workshop, not the product. You need four things.

A coding agent. This is the assistant that reads and writes the code. Good options:

• Claude Code, in the terminal, in VS Code or in the desktop app. Included in the paid Claude plans.
• GitHub Copilot in VS Code, with a free tier.
• Gemini CLI, open source, with a generous free quota.
• OpenCode or Aider, open source agents that work with many model providers.

Pick one and stay with it for the whole project. The differences between them matter less than your consistency.

An editor. VS Code is free and every agent supports it. Zed is open source, very fast, and has an agent panel built in that also runs external agents like Claude Code and Gemini CLI. You will read more code than you write, so a good editor is still useful.

Version control. Git with a private repository on GitHub (free). Git is the "undo" button for the whole project. If the terminal scares you, GitHub Desktop does the same with buttons. Rule: every working state gets a commit. You will thank yourself the first time the agent breaks something.

Calibration. This is the step most people skip, and it is the most important one. An agent without project rules writes the average code of the internet, and it writes it differently every day. Before any feature, add an AGENTS.md file and a few skills to the repository, so every session starts from the same rules. I describe this in detail in Agent Calibration. Read it first. It is the prerequisite for everything below.

If you know a developer, this is the best hour to buy from them. Ask them to choose the stack with you and to write the first AGENTS.md. A boring, popular stack is the right choice: the agent knows it well, and the future team will too.

2. Planning

Most failed vibe coding projects fail here, not in the code. "Build me an app for my gym" gives the agent too much freedom, and the agent uses all of it.

Write the Brief

Start with one page in plain language. Write it by hand, not with an agent. THIS IS IMPORTANT. Save it in the repository as docs/BRIEF.md:

# Brief

## Problem
Members book classes by phone. The phone is busy and classes get overbooked.

## Users
- Members: book and cancel classes from their phone.
- Trainers: see who is coming to their class.
- Owner (me): create classes and see attendance per month.

## Done Means
- A member books a class in less than 30 seconds.
- A class never has more bookings than places.
- The owner exports the monthly attendance to Excel.

## Not Now
Payments, a mobile app, chat.

The "Not Now" list is as important as the rest. Every idea you move there is a week you do not lose.

A chat assistant (Claude, ChatGPT or Gemini, all with free tiers) is a good interviewer for this step. Do not ask it to write the brief. Ask it to question you:

I want to build a class booking tool for my gym. Interview me one question
at a time until you understand the users, the problem and what "done" means.
Then write a one-page brief. Put everything that is not essential for the
first version under "Not Now".

Sketch the Screens

Draw every screen, badly, before any code exists. Excalidraw and tldraw are free and open source. Penpot (open source) and Figma (free tier) are there if you want more. A photo of a paper sketch also works. Agents read images, and a sketch removes a hundred words of ambiguity.

Break It Down

Now split the brief into features, and every feature into tasks that one agent session can finish. A good task is small enough that you can check the result yourself in five minutes.

## Feature: Class Booking

- [ ] Owner creates a class (title, trainer, date, places).
- [ ] Member sees the list of classes for the next 7 days.
- [ ] Member books a class. Show "full" when there are no places.
- [ ] Member cancels a booking up to 2 hours before the class.
- [ ] Trainer sees the list of members for a class.

Order the features so that each one is useful alone. Login and the data model come first because everything depends on them. The monthly export comes last because nothing depends on it.

Put the tasks where you can track them. GitHub Issues and Projects are free and live next to the code, so the history of every decision stays with the repository. Trello and Notion have free tiers if you prefer them. A docs/PLAN.md file with checkboxes is enough for a small project.

Ask the agent to review the plan before you build anything:

Read docs/BRIEF.md and docs/PLAN.md. Do not write code. List the tasks that
are too big for one session, the tasks in the wrong order, and anything the
brief needs that the plan does not cover.

3. Building

Building is a loop. One task, one session, one commit.

1. Start a fresh session. A long chat collects old mistakes and misunderstandings. A new session reads AGENTS.md and starts clean.

2. Ask for a plan first. Most agents have a plan mode. If yours does not, ask for it in words:

Task: members can cancel a booking up to 2 hours before the class.
Read the related code first. Then tell me your plan: which files change,
what the data looks like, and how I can test it myself. Do not write code yet.

Read the plan. You do not need to understand every line. You need to understand the behaviour. If the plan says "delete the booking" and you want to keep the history, this is the cheap moment to say it.

3. Let it build. Approve the plan and let the agent work. Ask it to write tests for the new behaviour and to run all the tests at the end. Tests are how the agent (and later the professional team) knows that feature 12 did not break feature 3.

4. Check it yourself. Open the app and do what a user does. Book, cancel, try to cancel too late, try to book a full class. The agent's "all tests pass" is not your acceptance. Your five minutes of clicking are.

5. Commit. When it works, commit with a clear message ("Members can cancel bookings up to 2 hours before class"). Tick the task in the plan.

Some rules for the loop:

• Revert, do not argue. If the agent goes in circles after two or three attempts, stop. Go back to the last commit with Git, start a new session and describe the task differently. Arguing in a long chat usually makes the code worse.
• Fix the rules, not only the code. If the agent makes the same mistake twice, the fix belongs in AGENTS.md or a skill, not in the chat.
• Describe behaviour, not code. Say "a member cannot book two classes at the same time", not "add a check in the controller". You know the business. Let the agent know the code.
• Never paste secrets into a chat. API keys and passwords go in a .env file that Git ignores. The calibration rules should already say this.
• Keep the data boring. For a first version, SQLite is a file on disk and needs no server. If you want a database with user login included, Supabase (hosted, with a free tier) and PocketBase (open source, you host it yourself) are good choices.

4. Improving

When the features work, the project is a demo. The difference between a demo and a product is in the things that no user asks for: security, observability, performance and maintainability. You did not think of them while building. That is normal. Now is the time.

The method is the same for every area: review first, fix later. Open a fresh session, give the agent a role, and ask for a list, not for changes:

Act as a senior security engineer reviewing this project before launch.
Do not change any code. List the problems you find, ordered by severity,
with the file and a one-line explanation for each. Say what you did not check.

Run the same prompt two or three times, each time in a clean session. One review never finds everything: every run reads the code in a different order and notices different things. Save the list of every run in a file and merge them. When a new run finds only problems that are already on the list, you are close to the end.

Then turn each finding into a task and fix it with the normal building loop. Ask a second agent, or the same one in a new session, to review the fixes. A reviewer that did not write the code is more critical.

Security

This is the area where amateur projects hurt real people. The minimum:

• Passwords are hashed, never stored as text. Better: do not store passwords at all and use a login service.
• Every page and API checks who the user is and what they are allowed to see. "Member 12 can see the bookings of member 13 if they change the number in the URL" is the most common bug in generated code.
• No secrets in Git.

Free tools that help: Dependabot and secret scanning on GitHub warn you about vulnerable libraries and leaked keys. Semgrep and OWASP ZAP are open source scanners the agent can run for you. My Ten Dealbreakers Every Web Engineer Must Know is a good checklist to hand to the reviewing agent.

Observability

When a customer says "it does not work", you need to know what happened without asking them for screenshots.

• Errors: Sentry has a free tier and tells you about every crash, with the page and the user.
• Uptime: UptimeRobot or Better Stack (free tiers) email you when the site is down, before your customers do.
• Logs and metrics: Grafana Cloud has a free tier. For a small project, the logs of your hosting provider are often enough.
• Analytics: Umami and Plausible are open source and respect privacy, so you do not need a cookie banner for them. PostHog is open source too, with a generous free tier, and goes further: product analytics, session replays that show what a user did before they got stuck, and feature flags to turn a new feature on for a few users first.

Ask the agent to add structured logs to the important actions (login, booking, payment) and to connect error tracking. It is a one-session task.

Performance

Run PageSpeed Insights (free, uses Lighthouse) on your main pages and give the report to the agent. Ask it to check for the classic problems: images that are too big, a database query inside a loop, a missing index on a table that grows every day. Fill the database with fake data (a thousand members, a year of bookings) and try again. Many problems only appear with real volume.

Maintainability

This is the part the professional team will judge you on.

• A linter and a formatter: Biome (open source) or ESLint with Prettier. The agent sets it up in minutes, and every file looks the same after that.
• Continuous integration: GitHub Actions runs the tests and the linter on every commit. It has free minutes every month for private repositories.
• Documentation: ask the agent to write a README.md that explains how to install, run, test and deploy the project, and to keep it current.
• Clean-up: once in a while, ask for a review of dead code, duplicated logic and files that are too long. Fix it in small steps, never in one big "refactor everything" session.

5. Deploying

Deploying is when the project leaves your computer and lives on the internet. Do it early, even before the project is finished. A small, real deployment teaches you more than a big, local one.

Choose a Host

For most small projects, one of these is enough:

• Static sites and front ends: Cloudflare Pages and Netlify have generous free tiers. Vercel is excellent too, but its free Hobby plan is for non-commercial use only.
• Apps with a server: Render has a free tier (the app sleeps when nobody uses it, fine for a private tool). Railway starts at a few dollars per month.
• Your own small server: a VPS at Hetzner costs a few euros per month. Install Coolify or Dokku (both open source) and you get a simple dashboard that deploys from GitHub.
• Databases: Supabase, Neon and Turso have free tiers. Read the limits: some free databases pause after a week without use.

Free tiers change often. Check the limits before you depend on them, and keep a note in the repository of what you use and why.

Let the Agent Prepare, You Approve

Ask the agent for a deployment plan before it touches anything:

We will deploy this project to Render with a Supabase database.
Do not deploy yet. Write docs/DEPLOY.md with every step: accounts I need,
environment variables, database setup, how to deploy a new version,
how to go back to the previous version, and how to restore a backup.

Then do the steps with the agent, one by one. Your calibration rules already say "warn before you deploy or run a migration". This is where that rule earns its place.

The Launch Checklist

• Environments: at least two. A preview (or staging) copy where you test, and production where users are. Most hosts create preview deployments for every branch for free.
• Secrets live in the host's dashboard, never in the code.
• A domain: about 10 euros per year. Cloudflare Registrar sells them at cost. HTTPS is free and automatic on every host above, through Let's Encrypt or similar.
• Email: to send login links or receipts, Resend and Brevo have free tiers.
• Backups run every day, and you have restored one at least once. A backup you never restored is a hope, not a backup.
• Automatic deployment: a commit to the main branch runs the tests and deploys only if they pass. GitHub Actions or the host itself does this.
• A way back: you know how to return to the previous version in less than five minutes.
• Monitoring from the Improving step is connected to production, not only to your laptop.
• Legal pages if strangers use it: privacy policy and terms. For a commercial product, pay a lawyer to read them. The agent can write a draft. It cannot take responsibility for it.

The Handover

If the project stays private and useful, you are done. Keep the loop going: one task, one session, one commit.

If it succeeds as a product, the day will come when you hire developers, or an agency, or a technical co-founder. Look at what they receive:

• A repository with the full history of every change.
• AGENTS.md and skills that say which rules the code follows.
• A brief that says what the product does and for whom, and a plan that says what was built and in which order.
• Tests that prove the features work, and CI that runs them.
• A security, performance and observability review, with the fixes.
• A deployment document that says how production works and how to recover it.

That is more than many professional projects have on the day they change teams. The new team does not start with an archaeology dig. They start with a conversation about what to build next.

Vibe coding does not replace the professional. It lets the amateur arrive at the professional's door with something that works, customers who use it, and a project that is ready to be taken seriously.