How to build a vibe-coded app that actually ships.

1. How Viski works, in one minute

You describe what you want in the chat. A coding agent writes the code inside your project, and a minute later the change is live on your project's own preview address. When you are happy, Publish copies that exact version to your real site. Everything around the code (hosting, HTTPS, a database, secrets, logs, analytics, email, scheduled jobs, a work-item board) is already set up, so you can spend your time on the product instead of on infrastructure.

The one idea to remember: the preview is your workshop and production is your shop window. Work freely in the workshop, and only publish when what you see in the preview is what you want customers to see.

2. Before your first prompt

The biggest difference between apps that ship and apps that stall is decided before anyone types a prompt. Spend ten minutes answering these five questions. Write the answers down, because they become your first prompt.

1. Who is it for? "Dog walkers in my city", not "everyone".
2. What is the one job it does? "Let owners book a walk and pay", not "a pet platform".
3. What does success look like on day one? "A stranger can book and pay without asking me anything."
4. What must it never do? "Never double-book a walker. Never show one customer another's address."
5. What does it look and feel like? Name two or three sites you like, or attach screenshots.

Then cut the list down. Pick the smallest version that someone would actually use (the first slice). Payments, admin panels, notifications and a mobile app can all come later, and each will go better once the core works.

3. Writing prompts that work

An AI agent is a very fast, very literal colleague who has just joined the project. It can read all of your code but it does not know your customers, your intentions or what you saw on screen. Good prompts close that gap.

A clear prompt usually has four parts:

• Where: the page, button or feature ("the pricing page", "the sign-up form").
• What: the change you want, described as behaviour ("when X happens, Y should happen").
• Why: the problem it solves. This lets the agent make sensible small decisions for you.
• Limits: what must stay the same ("don't change the layout", "keep it working on phones").

Some habits that pay off:

• One change per message for anything important. Small requests are faster, cheaper and easier to undo.
• Describe outcomes, not code. "Users should stay signed in for 30 days" works better than guessing at technical terms.
• Paste the exact error. Copy the whole message, not a summary of it.
• Say what "done" means. "Done when a new user can sign up, get the welcome email, and land on the dashboard."
• Correct instead of repeating. If a result is close, say what is still wrong ("the button is right, but it should be on the left") rather than resending the original prompt.

4. The build loop

Successful vibe coding is a rhythm, not one heroic prompt. Repeat this loop:

Every run is saved as its own version automatically, so you never need to "save" and you can always go back. Viski also shows the credits a run uses, so you can see what each change costs.

Watch the dashboard's Next steps. When a project can't preview, a run failed, a security fix is needed, or work was left unpublished, it appears there with a suggested prompt you can edit and run on the spot.

5. Worked example: a to-do app in six prompts

Here is the whole method on the smallest useful app there is. Each step is one prompt, and the demo below is a working to-do list that grows as you step through them. Try it: add a few tasks, then move to the next prompt.

What this example teaches

• Start with the smallest slice that works (add, tick, delete) and look at it before asking for more.
• One feature per prompt. Each step is easy to check, and easy to undo if it goes wrong.
• Say why. "I lose my tasks when I reload" tells the agent what problem it's solving, not just what to type.
• Plan before anything that touches accounts or data. Step 5 changes nothing. It just gets the approach agreed.
• Publish only after using it in preview, on a phone as well as a laptop.

Your turn. Paste prompt 1 into a new Viski project, change "to-do list" to your own idea, and follow the same six steps.

6. Build, Plan and View: pick the right mode

A good default for anything that touches money, sign-in or data: Plan first, then Build. Reading a plan for two minutes is much cheaper than untangling a wrong guess.

7. Bigger work: let the board carry it

When you ask for something feature-sized, Viski doesn't just start typing. A small fix runs straight away. A task-shaped request is filed on the project's board so there is a record of it, and a big feature comes back as a proposed breakdown for you to confirm. Once confirmed, the pieces can run in parallel.

• Use the board as your product's to-do list: features, bugs and ideas, each with a clear title.
• Write acceptance criteria on important items, like "done when…". The agent works to them.
• Run a selection of items together when they are related, and separately when they are not.
• Keep finished items closed. The board then becomes a readable history of why the app is the way it is.

8. Show, don't describe

The fastest way to fix something visual is to let the agent see it.

• Attach a screenshot of the problem, or of a design you like, with the paperclip in the chat.
• Attach files such as a logo, a spreadsheet of products or a brand guide, rather than retyping them.
• Name the device. "On iPhone, the menu covers the logo" is much easier to fix than "the menu is broken".
• Give the steps. "Sign in, open Settings, press Save, and the page goes blank" lets the agent reproduce it.

9. Users, data and secrets

This is where casual prototypes and real products part ways. Three rules keep you safe:

1. Ask for a real database as soon as your app needs to remember anything, such as accounts, orders or bookings. Each Viski project gets its own isolated database, separate from every other project.
2. Never paste passwords or API keys into the chat. Put them in the project's Secrets settings. They are encrypted and given to your app when it runs, and never written into your code.
3. Say who can see what. "Customers only see their own bookings, and only I can see everyone's." The agent can build good security, but only if you describe the rules.

When you add sign-in, payments or email, test them the way a customer would. Create a real account in the preview, go through the whole flow, and try doing something you shouldn't be allowed to do.

10. Preview, publish, roll back

• Share the preview first. Send the preview address to two or three people who fit your audience and watch them use it without helping.
• Publish when the preview is right. Publishing ships exactly the version you tested, and your live site doesn't change while you keep working in preview.
• Roll back without panic. Every release is kept. If something goes wrong after publishing, redeploy the previous release, then fix the problem calmly in preview.
• Add your domain once you're ready. After it's verified, HTTPS is set up automatically and your domain becomes the site's main address.

11. Choosing an agent

Viski isn't tied to one AI. You can choose the coding agent (such as Claude, Codex or Kimi) and its model per project, and the choice sticks for that project, including scheduled jobs. A practical approach:

• Use your strongest model for planning, architecture and tricky bugs.
• Use a faster model for small, well-described edits and copy changes.
• If an agent goes round in circles on a problem, don't just repeat the prompt. Switch to Plan mode, or try a different agent, which will approach it differently.

12. Working with many projects

• Workspaces separate clients, teams or businesses. Members invited to a workspace see its projects, so moving a project changes who can reach it.
• Folders keep a workspace tidy. Drag cards onto a folder, and move a whole folder (with its projects) to another workspace from its ⋯ menu.
• Quick prompt from any card's ⋯ menu sends a request without opening the project. On a folder, it sends the same prompt to every project inside it, and you can untick the ones that should be left out. This is perfect for "update the footer year" or "add our new privacy link" across a family of sites.

13. The technical track

Everything above applies to you too. This section covers how Viski's architecture works, so you can get the most out of it.

The repository is the product

Each project is an ordinary git repository on GitHub. Viski commits after every run and pushes, so the repository is always the source of truth. Clone it, open it in your editor, run it locally, and push changes. Viski picks up external pushes and continues from them. Imported repositories keep their origin, so a project synced with another builder stays usable in both.

Two branches, one rule

If you push by hand, push to viskiapp-test and let Publish move production. Releases are tagged, which is why a rollback redeploys a known build instead of rebuilding from guesswork. Feature branches let prompts run and preview on a branch of your choosing when you want to isolate a larger change. In protected repositories, changes go back to the owner's branch as pull requests.

Runtime and data

• Every project runs in its own container for preview, and in a separate one for production after publishing. Treat them as separate environments.
• Databases are isolated Postgres instances, one database and login per project. Ask the agent to write schema changes as migrations so preview and production stay in step.
• Configuration reaches your app as environment variables from the encrypted secret store. Keep .env files with real values out of the repository.
• Logs, analytics, scheduled jobs, storage and email are built into the dashboard, so ask the agent to use them rather than wiring in a third-party service for each.

Make the agent's work reviewable

• Ask for tests with behaviour changes ("add a test that fails without this fix"). Agents are much more reliable when they have something to check against.
• Keep your project's conventions (stack, folder layout, naming, what to avoid) in CLAUDE.md at the root of the repository. Every agent, whichever model you choose, is pointed to it at the start of each run.
• Review diffs for anything touching auth, payments, permissions or data deletion. Speed is the point, but a quick review is too.
• Use View mode for code archaeology: "Where is the session validated?" and "What would break if I removed this table?"

Access is the security boundary

Anyone who can prompt a project can cause code to run in it. Invite people at the lowest level that fits: viewers can ask questions, planners can file work, and editors can build. Keep owner rights for the people who publish.

14. Common pitfalls, and the fix

15. Launch checklist

• A new visitor understands what the app does within five seconds.
• The main flow works end to end on a phone and on a laptop.
• Sign-up, sign-in, password reset and sign-out all work.
• Users can only see and change their own data.
• All keys and passwords are in Secrets, and none are in the code or the chat.
• Empty states, errors and slow connections show something helpful.
• Page titles, descriptions and a share image are set for search and social.
• Privacy policy and terms are linked if you collect personal data or take payments.
• Someone outside the project has tried it in preview without help.
• You know how to roll back, and you've published from a preview you tested.

16. Prompt cheat sheet