Social runtime
The post is not a placeholder for the project.
Posts, player pages, and embeds are meant to open the actual software, so someone can click around, feel the idea, and decide whether they want to save, share, or remix it.
About Vibecodr
Build the thing, then hand people the working link.
Vibecodr is for runnable web software: the odd tools, tiny games, visual experiments, useful dashboards, and half-serious ideas that make more sense when someone can open them.
Start in Studio, publish a live app post, let people play with the real thing, then keep the project moving with BUMP IT, remixes, embeds, and Pulses when the work needs trusted backend help.
About
Read the mission behind Vibecodr and why we focus on shareable, runnable software instead of static screenshots.
Why Vibecodr exists
Software is easier to understand when it can answer back. Vibecodr starts from that simple belief and builds the social, publishing, and safety model around it.
Permissive creation
Small should stay easy, and bigger should still have a path.
A project can stay as a browser-side Vibe for as long as that is enough, then add Pulses for secrets, schedules, webhooks, or integrations when the work has earned a backend.
Cohesive identity
The same project can keep becoming itself.
BUMP IT keeps links, embeds, history, and public identity connected, so the next release feels like a living continuation instead of a replacement people have to rediscover.
User safety
Openness works better when the boundaries are visible.
Runnable Vibes stay in a browser sandbox, while secrets, schedules, external APIs, and trusted server work belong in Pulses instead of leaking into public code.
What the platform holds together
The public post, runnable artifact, remix path, source workspace, and Pulse-backed backend plane each keep their own boundaries while still feeling like one project to the people building and opening it.
Build loop
Studio keeps the making close to the publishing.
Edit files, preview the work, shape the post details, and publish without turning the first version into an infrastructure errand.
Distribution
Discovery is part of the work, not an afterthought.
A project can live in the feed, on a profile, on its own player page, and inside embeds while still carrying the same identity and remix trail.
Backend model
Backend power arrives when the project needs it.
Use Pulses for the work that should be trusted, scheduled, or private without making every new idea carry a full backend from the first draft.
Clarity
The rules are visible where people need them.
Security, privacy, pricing, and community boundaries stay readable so the platform feels inviting without hiding the serious parts.
Keep exploring
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.
FAQ
Short answers for the places where marketing copy should stop hand-waving and say the plain thing.
Is Vibecodr only for frontend experiments?
No. Browser-first Vibes are the easiest place to begin, but projects can grow into Pulse-backed apps when they need secrets, schedules, webhooks, or other trusted backend work.
Does Vibecodr require users to install tooling first?
No. The default path is browser-first so people can open published work immediately, then decide whether they want to build, remix, or go deeper.
Why emphasize canonical app continuity?
Because a project should be able to grow without losing its audience, links, embeds, history, or remix context every time a new version ships.
How does Vibecodr balance openness with safety?
By letting browser-side code be easy to open while keeping trusted backend capability in a separate Pulse plane with explicit safety rules around secrets, routing, storage, and external calls.