Software is getting weird again.
Secure state sandboxes. Simple social sharing. Built for the people, not the platform. We're a small team building something that matters—and we're looking for engineers who want to work in public.
Vibes are for everyone.
Our mission is to make collaborative apps into a new media object, with social data sharing driven by our secure runtime.
Built for your group chat
Describe what you want, get a live app. Share the link. Your friends join instantly and see real data—no accounts, no setup, no "wait let me send you the invite."
Actually collaborative
Everyone in your vibe sees the same live state. Someone adds an item, everyone sees it. It works like a shared doc, except it's a full app you described into existence.
Yours, not theirs
Your data lives in your vibe. Private by default. You approve who gets in. No algorithm, no feed, no platform deciding what happens to your stuff.
The tightest deploy loop for agentic apps.
One file. One push. A live URL with real persistent state. Agents skip the entire stack negotiation—no bundler, no backend, no environment drift.
A featherlight runtime.
Most agentic coding systems slow down the moment they try to become useful. Package drift, auth drift, backend sprawl, environment mismatch—they pile up fast across a batch of apps.
The answer isn't to maximize freedom everywhere. It's to constrain the parts that create operational drift and leave the creative surface open. That's the design point behind Vibes DIY.
Instead of asking an agent to assemble a modern web stack from scratch, we give it a tight app contract: one file, a light core platform surface, persistence built in, and a CLI that turns "generate" into "deploy" in one loop. When an agent doesn't need to decide how to wire storage, where to host state, how to bundle dependencies, or how to invent a deployment pipeline—it can spend its attention on product logic. That's what lets us think in terms of 48-app or 96-app batches instead of one heroic demo at a time.
Constrained app shape. Open module ecosystem.
Here's what we're actually solving.
You'd work on these directly with JChris and Meno. In code. In public.
Read-first entry
Invite links currently hit a Clerk auth wall before the visitor sees any value. Fireproof's offline-first architecture can render the live app with no cloud token—defer auth until the first write action. Impulse clickers shouldn't bounce at a login wall.
Remix without the data cliff
Clicking remix forks the code into a blank Fireproof database. Users call it "being evicted into an empty house with the same paint but no furniture." The fix: let forks inherit read-only access to the original data state via Fireproof cryptographic proofs, until the user explicitly diverges.
Surface the permissions model
The CLI already supports --reader flags and D1 fully supports read-only membership—but the web UI omits it entirely. One toggle on the invite button takes this from prototyping toy to deployable enterprise tool. Zero new infrastructure.
Vibes is an electric guitar. Now it's up to the world to invent rock-and-roll.— Marcus Estes, Co-Founder of Vibes DIY
Look under the hood.
The whole thing is open source. Read the code, open an issue, send a PR. That's how it starts.
github.com/VibesDIY