Features
A request goes in, a conventional project comes out, and every step between is something you can read. This is the whole of it, including where each part stops.
01The composer
Three optional inputs sit above the request, and all three persist. Getting started walks through them.
Write what the thing is, who uses it and what it has to do. Specifics help more than adjectives.
Standing instructions that persist: the company name, a stack you insist on, how dates are formatted.
The visual direction, kept apart from the brief, so changing how it looks does not mean restating what it does.
A page to copy from or emulate. vibld fetches it and reads its structure.
Which models are offered depends on the deployment and your account. The settings menu reports which one actually served the last run.
02Directions
Name a style preset and the build starts from its direction, including how it moves. Or ask for three sketches that differ in look, and pick one.
03Checkpoints
A run produces a staged checkpoint: a plan and a set of files, not yet the project. The preview, a push and a publish all act on the last one you accepted. Iterating is another turn in the same conversation, and the follow-up sees the project it is editing.
Until a sandbox runs, a local mock of the plan in a fully restricted frame: nothing installed, no generated code executed. Once a sandbox runs, the frame is the sandbox.
The generated files, as files. The pane to read before accepting anything.
What the run is doing, when it started and finished, and what it cost.
Where it stops: Not the sandbox’s process output, which is not piped in yet.
What vibld’s own checks found in the staged files before you accepted them.
Where it stops: Not the sandbox’s install, build or type errors, which are not reported here yet.
04Sandbox and sharing
Run in sandbox installs the dependencies and starts a dev server. It reports each state (queued, installing, starting, ready, failed) instead of a spinner, and it expires, because it is for looking at a project rather than hosting one.
Share mints a link to the running sandbox. Several can be live at once, each with its own expiry and each revoked on its own, and none is affected by restarting or stopping the sandbox.
Anyone with the link can view the running app and everything it shows, until it is revoked or expires. The builder says so next to the button.
A sandbox serves the checkpoint it started from. Accept a newer one and the pane says so and offers Restart in sandbox, rather than letting the frame quietly misrepresent the project.
05Design checks
The chosen direction is written into the project as DESIGN.md: its colours, type, breakpoints and motion. When the build finishes, static checks read the files against it, and against the few rules every page must keep: a page language, alt text on images, a reduced-motion rule. Checks read files; they do not render them, so they cannot see computed contrast or an overflowing layout.
An error is something the checker is confident about, such as a colour the spec named that appears nowhere. Only errors buy a repair, because a repair is a paid call that rewrites the whole project. A warning rides along with a repair that is happening anyway.
06Taking your code
The output is a conventional project. There is no proprietary runtime to keep it working and nothing that stops building the day you stop paying.
Downloads the accepted checkpoint as a .zip: the files as they are, ready to open in an editor and run with the package manager the project declares. Nothing rewritten, nothing that phones home.
A branch named vibld/<revision>, one commit and a pull request against the default branch, in the single repository you approved. The grant expires after 90 days, and a push is safe to retry.
Builds the accepted checkpoint and serves it at a vibld address, in two presses. Take it down the same way: the address stops working immediately and the name stays yours.
Where it stops: Rolling back to a previous published checkpoint is not built yet.
07What you get
Plan and usage in the settings menu mirrors the same spend figures the builder enforces, so what it shows and what it allows cannot disagree. Pricing has the plans.
It installs and builds with the package manager it declares. There is no vibld package in its dependencies and nothing that checks an account when it runs.
Static checks read the files. Only an error the checker is sure of buys a repair, because a repair rewrites the whole project.
In the one repository you approved, on a vibld/ branch, against your default branch. Review it like any other change.
vibld: <revision>
your-org/clay-saturdays, from vibld/<revision>
Nothing automated can publish: no scheduled run, no webhook, no text in a commit. Take it down and the address stops working immediately, and the name stays yours.
clay-saturdays.vibld-preview.dev
Name itPublish
The source is public. Self-hosted, vibld is three Cloudflare Workers with deliberately different blast radii, so the code a model wrote never runs next to your provider keys.
08Before you join
Yes. Export downloads it as an archive: package.json, index.html, a src directory and a README. Push to GitHub opens a pull request in a repository you connect. From there it goes wherever you put it.
No. It installs and builds with the package manager it declares, npm install and npm run build. There is no vibld package in its dependencies and nothing that checks an account when it runs.
It writes React, TypeScript and Vite, styled with Tailwind and shadcn/ui components, with Lucide icons and Motion for animation. A frontend developer can review it without learning a new format first.
Projects you have exported or pushed keep working, because none of them call home. The core is licensed Apache-2.0, so anyone with a copy of the source can keep reading, running and forking it.