Why Vibecodr Exists
Vibecodr is a place to play with code and ship it — where the odd tools, tiny games, visual experiments, and half-serious ideas make more sense because someone can actually open them. Not a pitch deck for software, the software itself, live at a link.
Paste, upload, or generate code; watch it run as a real app; share it and let people remix it; and add a backend only the day the project earns one. That loop is the whole product — everything underneath is plumbing we handle so you can stay in the part that's fun.
Vibecodr starts from a simple idea — software is easier to understand when it can answer back — and builds the social, publishing, and safety model around it. A few stubborn beliefs, and a product built around them.
01 — Runnable, not described
A screenshot, a repo link, or a long explanation all ask people to imagine the thing. Vibecodr exists so 'here, try this' opens the real, working app in one click — on any device, with nothing to install — and the idea gets to speak for itself.
02 — A place to play
Paste what an AI wrote, drop in a sketch, or bring a whole repo. Nothing has to be finished or serious to deserve a public home. Small experiments are the point, not a warm-up for the real product — some stay toys, and some quietly grow up.
03 — Sharing is the feature
Every app gets its own page and a link that opens the live app — in the feed, in a chat, or embedded on your own site. People press play and use it, every share carries your name, and anyone can remix it with the credit staying attached the whole way.
04 — Earn the backend
A project can stay a browser-side app for as long as that is enough. The day it needs secrets, a database, a scheduled job, or a call out to another service, add a Pulse — server code that deploys with the project. You reach for it when the work earns it, and never before.
05 — Safe to open
Every app runs in an isolated, cross-origin sandbox that cannot touch your account, your data, or anything else on the page. That isolation is the whole reason pressing play on a stranger's app is a non-event — and why a place this open can also feel safe.
Small projects can stay small; ambitious ones have somewhere to grow. The same few moves carry a build from a first sketch to something people open, remix, and keep following.
Make
The making stays close to the publishing. Edit, preview, and shape the post without turning a first draft into an infrastructure errand.
Ship
No servers to rent, no deploy ritual, no 'works on my machine.' The moment you publish, the working app is live for anyone to open.
Remix
Others fork what you made and take it somewhere new, and the lineage stays visible. Ideas evolve in the open instead of getting quietly copy-pasted away.
Keep evolving
The project keeps one public identity as it grows. Links, embeds, and history stay intact, older cuts stick around, and the people following it just see it get better.
A few first-party routes explain the build loop, the trust model, the kinds of work that fit here, and the plan limits when a project starts needing more room.
Short answers for the places where marketing copy should stop hand-waving and say the plain thing.
No. Browser-side apps are the easiest place to begin, but a project can grow into a backed app when it needs secrets, schedules, webhooks, or other trusted server work. You add that with a Pulse only when the project earns it.
No. The default path is browser-first, so you can open published work immediately and publish your own by pasting what an AI wrote. And if you do code, nothing is hidden — bring a whole repo and wire up a real backend.
Because a project should be able to grow without losing its audience, links, embeds, history, or remix context every time a new version ships. BUMP IT keeps it one living thing instead of a graveyard of near-identical URLs.
By letting browser-side code be easy to open while keeping trusted backend capability in a separate Pulse plane, with explicit rules around secrets, routing, storage, and outbound calls. Open to play with, sealed where it counts.