Skip to main content
vibld
DocsSign in

← All guides

Using vibld

Getting started

Checked against the product on

vibld turns a description of an application into a real project: a conventional codebase in files you can read, running on a stack you already recognise. This page is the first twenty minutes.

1. Sign in

The builder is at app.vibld.com. Accounts are email and password or a linked provider, whichever you prefer. Nothing in the builder mounts until you are signed in, including the part that would start spending money on your behalf.

A new account is granted $1.00 of model spend when it is created. That is a one-time grant and it does not reset. It is enough to build something small and see what the output looks like before deciding whether to pay for anything.

2. Describe what you want

The composer is the left column. Write what the thing is, who uses it, and what it has to do. Specifics help more than adjectives: “a booking page for a two-chair barbershop, with a week view and an email confirmation” produces a better first pass than “a modern booking app”.

Three optional inputs sit above it, and all three persist:

  • Knowledge is standing instructions. Anything you would otherwise repeat in every prompt belongs here: the company name, the stack you insist on, a rule about how dates are formatted.
  • Style DNA is the visual direction, kept apart from the brief so that changing how it looks does not mean restating what it does.
  • Reference URL points at a page to copy from or emulate. vibld fetches it and reads its structure.

You can also choose the model. Which models are offered depends on what the deployment can serve and on what your account is allowed, and the header always reports which one actually served the last run rather than which one was requested.

3. Read the checkpoint before accepting it

A run produces a staged checkpoint: a plan and a set of files, not yet the project. Nothing downstream, not the preview, not a push, not a publish, acts on staged files. Open the Code tab, read what it wrote, and accept it when it is right.

Accepting is what makes a checkpoint the project. Iterating from there is another turn in the same conversation: the follow-up sees the project it is editing, so “make the header sticky” means the header it already wrote.

4. Run it for real

The preview you see first is a local mock assembled from the plan and the stylesheet. It runs nothing. When you want a genuinely installed, genuinely running copy, use Run in sandbox, which is covered in Running and sharing your project.

What to read next