Vibe coding apps: from idea to a working MVP with an agent
A practical route for building a small web app with an agent, from the idea to deployment. Where a human is required, and what it costs.
6 min · · development · агенты
Vibe coding an app usually doesn't break on the first screen, it breaks on day three: the agent has generated a lot of code and you no longer understand what is in it. Below is a route that helps you take a small web app to an MVP without losing control: how to describe the task, which stack to pick, how to handle the database, when to run tests and where a human is required. For what vibe coding is in general, see vibe coding: what it is and what an hour of agent work costs; this article is only about the build practice.
Pick a small task
An MVP for an agent should fit in one sentence and two or three screens. Good examples: a task tracker for a team of five, an appointment form with a calendar, a personal account with file uploads. Bad examples: "a marketplace", "a social network", "a CRM for everyone". The wider the task, the more the agent invents on its own, and the harder it is to verify the result.
Before starting the agent, write a short brief in SPEC.md:
- who the user is and what they do in 2–3 steps;
- the list of screens and the data that is stored;
- what is definitely not in the first version (payments, roles, notifications);
- how you will know it works (three scenarios you can walk through by hand).
The agent will re-read this file, and you get an acceptance criterion.
Stack: pick the boring one
Agents do best with what appeared many times in open code. For a first MVP, one combination in a single repository is enough:
| Layer | Option | Why |
|---|---|---|
| Backend | FastAPI (Python) or Express (Node.js) | little boilerplate, clear structure |
| Database | SQLite to start, PostgreSQL later | SQLite needs no separate server |
| Frontend | server templates or plain React | fewer build tools |
| Tests | pytest or vitest | the agent runs them itself after edits |
| Deploy | Docker and one small server | reproducible and easy to roll back |
This is not "the one right" stack, just a way to reduce the number of places where the agent can go wrong. If you already know another stack, use it: you are the one who has to review the code, so you must be able to read it.
Connect the agent
For building an app you can use a console agent such as Claude Code or an IDE plugin. Claude Code is configured through environment variables:
export ANTHROPIC_BASE_URL="https://api.zukko.pro"
export ANTHROPIC_AUTH_TOKEN="fetch_your_key"
export ANTHROPIC_MODEL="claude-sonnet-5-5"
claudeThe address has no /v1 because Claude Code appends the path itself, and the variable is specifically ANTHROPIC_AUTH_TOKEN. Details and pitfalls are in the Claude Code documentation. If you prefer an editor such as Cursor, it uses the OpenAI-compatible address https://api.zukko.pro/v1, and you should check the exact settings items against the editor's own documentation.
For the main work you can take a mid-table model: claude-sonnet-5-5, strength index 48. For hard spots (architecture, a tough bug) switch to claude-opus-5-5, index 58. Which model copes with your project, test on your own tasks: the index does not replace a trial.
Rules for the agent
Put a CLAUDE.md file (or your editor's rules) in the project root with short instructions. How to write it is covered in the article on CLAUDE.md. A minimum:
Read SPEC.md before any task.
Work one step at a time and run the tests after each.
Do not add dependencies without asking.
Secrets come only from environment variables, never in code.
Database migrations go in separate files; do not edit existing ones.Work in small steps
The working loop looks like this:
- Ask the agent to create a skeleton: folder structure, empty screens, a database connection, one test.
- Run it and make sure the app opens. Commit.
- Ask for one feature at a time: "add task creation with validation and a test".
- After each feature, walk through the scenario by hand and commit.
- If the agent is stuck on one error for more than two attempts, stop it and describe the problem in your own words, otherwise it will start rewriting things it shouldn't.
Frequent commits solve the main problem of vibe coding: there is always a point to roll back to. If the agent falls into an endless loop of edits, roll back to the last working commit and rephrase the task.
The database
Don't hand the database to the agent entirely. Agree on rules:
- the schema changes only through migration files that you read before applying;
- the agent has no access to the production database, only to a local test one;
- a backup is made before every production migration;
- commands such as
DROPand an unconditionalDELETEyou run yourself.
These rules take five minutes and protect against the most unpleasant mistake: losing user data.
Deployment
Ask the agent to prepare a Dockerfile and a short run guide, but deploy yourself. Check that secrets are in the server's environment variables, debug mode is off, the database sits on persistent disk rather than inside the container, and backups are configured. After deploying, walk through the same three scenarios from SPEC.md on the live address.
Where a human is required
The agent writes code, but responsibility stays with you. Check by hand:
- Authorization and access rights. Try opening someone else's data as another user.
- Money and personal data. Any payments and storage of personal data need a separate review and knowledge of legal requirements.
- Dependencies. The agent may add an unnecessary or unmaintained package.
- Secrets. Keys must not end up in the repository. If that happens, revoke the key in the dashboard right away and create a new one.
- Understanding the code. If you can't explain what a module does, ask the agent to explain it and verify the answer against the code.
What it costs
Prices as of October 18, 2026: claude-sonnet-5-5 costs $0.4 per 1M input tokens and $2 per 1M output tokens, cache read $0.05, cache write $0.5. In the Anthropic format (Claude Code) the gateway sees the cache, so repeated context is charged at the read price.
Example: one feature, 20 agent requests. In each request 27,000 context tokens are read from cache, 3,000 new tokens are written to cache, and the answer is 1,000 tokens (assumptions for illustration, your numbers will differ).
- Cache read: 20 × 27,000 = 540,000 tokens × $0.05 / 1M = $0.027
- Cache write: 20 × 3,000 = 60,000 × $0.5 / 1M = $0.03
- Output: 20 × 1,000 = 20,000 × $2 / 1M = $0.04
- Total: $0.027 + $0.03 + $0.04 = $0.097
The real bill depends on project size and the number of edits. Set spending limits on the key in advance: how to limit an API key's spending. Current prices: GET https://api.zukko.pro/v1/models or the "Models" page in the dashboard.
To start, create a key in the dashboard, top up the balance (SBP, MasterCard or cryptocurrency) and run the agent on an empty repository with a SPEC.md.
FAQ
Can I build an app without knowing how to program?
A simple prototype, yes, but taking it to a working service without understanding the code is hard: the agent doesn't always notice mistakes in access rights, data and deployment. Start small and ask the agent to explain every step.
Which agent should I choose for a first app?
Any that reads project files and runs commands will do. Choose by the interface you are used to: terminal or editor. Connecting both options to the gateway is covered in the Zukko docs.
Why does the agent break what used to work?
Most often because there are no tests and no small commits. Ask it to write a test with every feature and to run the whole suite after edits.
How much does it cost to take an MVP to the end?
It depends on project size and the number of iterations. Price one step with the formula above, multiply by the expected number of steps and set a daily limit on the key.
zukko
Pay 25×
less
for Claude Code & ChatGPT
One fetch_* key and base URL api.zukko.pro — for Cursor, Claude Code, Codex, and any SDK.
Related articles
- Prompt Injection: What It Is and How to Protect a Bot and an AgentHow prompt injection works through user input and third-party documents, and which measures limit the damage: data isolation, tool permissions, key limits.
- Claude Code YOLO: Permission Modes and Working Without PromptsClaude Code has no mode literally called YOLO, but it has several permission modes and flexible rules. How to stop clicking Yes without losing files.
- Claude Code: a checklist of best practices for daily workHabits that make working with Claude Code predictable: a short CLAUDE.md, a plan before edits, small tasks, checking results and keeping spend under control.
- An MCP server in Java: a minimal example with one toolWe write a minimal MCP server in Java with one tool, register it in Claude Code, and learn to find the cause when the agent doesn't see it.