Developers Log - 001 (finally)

Thread body

Someone gave me a great idea: we should maintain a dev log so people can see what’s happening, what’s being built, what’s changing… because so much of Vibecodr has been happening “behind the scenes”. And honestly, this post is also me forcing myself to stop hiding behind “I’m still working on it” as a permanent state. The funny part is: writing Devlog 1 immediately forces the thing I’ve been side‑stepping… a version number. Which feels way more intimidating than it should. I’ve been building Vibecodr for about 4 months. Most days it’s been 10+ hours. There are 867 commits on GitHub. And for a long time that was my “devlog”: a pile of commits, notes scattered across files, and whatever was in my head at 2am. So I’m calling this moment Devlog 1, and (for my own sanity) this era is basically V1. Not “perfect”. Not “finished”. Just: the platform is now a real thing you can use end‑to‑end. That matters. Why I built Vibecodr I’m going to keep this real and not romanticize it. At some point recently I made a Reddit post that was basically me saying: I’m looking for community. I’m looking for the kind of people who build weird stuff because they can’t not build it. The kind of people who think interactive code can be art. The kind of people who still get excited when something in the browser feels alive. The replies were helpful, but the underlying truth hit me: everyone is scattered. Tons of talent, tons of creativity… but no obvious “home” that feels like our home. So I stopped searching and started building the place I wanted to exist. Vibecodr, to me, is not “a website with posts”. It’s a way to make creative code shareable like a song is shareable. Not “clone the repo.” Not “run npm install.” Not “it works on my machine.” Just… click → it runs → you feel something → you remix it → you make it yours. That’s the whole idea. Everything else is scaffolding. What Vibecodr actually is right now (in plain English) Vibecodr is a social platform for interactive web experiences. A “Vibe” is a post that can contain a runnable project (“Capsule”). Capsules are client‑side apps that run in a sandboxed iframe on their own domain. That separation is intentional. It’s part of the safety story. (This also enables embedding without handing your browser storage/cookies to random code.) Capsules have real constraints and guardrails: file limits, bundle size limits, boot timeouts, safe defaults. You can import npm packages directly and the platform resolves them through a CDN pipeline (so you don’t need to wire up bundlers just to make something playful). And when you need server-side power, you don’t hack secrets into client code. You use Pulses. Pulses are server-side scripts deployed on Cloudflare Workers for Platforms. They support secrets (write-only, never leaked back), allowed-host restrictions, quotas, grants for execution, and all the boring-but-essential stuff that makes “server-side automation” safe enough to offer to strangers. Then Triggers sit on top: cron, runtime events, manual fire, HTTP webhooks. Triggers can call webhooks, Discord webhooks, and can execute pulses. Everything is rate-limited and quota’d, because otherwise the platform becomes a liability. That’s the platform. Now… what’s actually “done” enough to call V1? The V1 milestones (aka: what exists today) I’m not going to list every tiny change. This is the “if you’re new here, this is what Vibecodr can do right now” list. Creation & publishing Studio exists as a real workspace: create a new capsule, edit files, run it, and publish. Remix flow exists: you can start from someone else’s work (or your own) and fork it into a new direction. Import pipeline exists: you can bring in code from GitHub or a ZIP upload, it gets analyzed, safety-checked, bundled with esbuild, and stored as an artifact the runtime can load. Playing & sharing Player exists as a real product, not a demo: immersive mode, console, stats, run tracking, mobile layout, “arcade” vibes. Embeds exist in a way I actually trust: they run on a separate origin, with sandboxing, and support “live” embeds or pinned snapshot embeds. Social & discovery Feeds exist (Following / Discovery / For You), and they’re not random. The ranking is built around the stuff that matters for this platform: not just likes, but real interaction signals like runs, completions, remixes, shares. The goal is that “things people actually play” rise, not just things people scroll past. Search exists, and it’s real search (not a fake filter). Automation & server-side power Pulses are real: create, edit, deploy, run; manage secrets safely; archive/restore to manage limits. Triggers are real: runtime event / webhook / cron / manual, and they can execute actions (webhook / Discord / pulse execution). (Email is intentionally not enabled yet — it exists in the schema, but I’m not shipping it until it’s actually done properly.) Safety, trust, and the unsexy work This is the part nobody sees, but it’s most of the work if you want a platform where strangers run code. Capsule attachment and remix rules are strict. Ownership rules, quarantine rules, published-only rules. No weird loopholes where private stuff accidentally becomes public because a post did something unexpected. Embeds are isolated by design (separate origin), not “hope and vibes”. Rate limiting exists. Quotas exist. Budget enforcement exists. Security hardening has been a constant theme: stronger protection against the usual web attack categories (XSS/SSRF/etc), safer fetch patterns, safer file handling, safer logging, safer defaults. Admin/ops (because this can’t be a toy forever) There are real admin surfaces for moderation/flagging, analytics, errors, and operational maintenance. A lot of the platform has tests specifically around safety and abuse edges, because those are the edges that actually matter. The part I don’t want to gloss over V1 is not “done”. But it is real. It is a full loop: create → publish → play → share → remix. Plus the server-side half (pulses + triggers) that turns a vibe from “cool interactive thing” into “something that can actually do work”. And I want to say this plainly: I built this because I didn’t want to keep building alone. I don’t want the only proof of progress to be a commit graph. I want to build where people can actually touch the work, respond to it, remix it, and make it feel alive. What happens next I’m going to keep this devlog human. Not corporate. Not fake-polished. If something breaks, I’ll say it broke. If something ships, I’ll say what it actually unlocked. And if you’re reading this and thinking “I’m one of those people, I’ve been looking for this too” — then please make something. Even something tiny. Especially something tiny. Post it. Let me see it. Let me feature it. Let’s turn Vibecodr into the place we were all trying to find. That’s Devlog 1. — Braden