Braidly

• 

  chat section

• 

  profile

• 

  landing page

Inspiration

"Vibe coding" made building software faster than ever — but it also broke the one thing that made teams work: knowing your code will fit with everyone else's. We kept seeing the same story play out: someone vibe-codes a feature that works perfectly in isolation, hands it off, and the integration step turns into hours of manual glue-code and guesswork. Multiplied across a team, that's how "AI helped us build fast" turns into "AI helped us build five things that don't talk to each other."

At the same time, we'd been reading through research on why vibe-coded apps actually fail in production — not anecdotes, but numbers: close to 45% of AI-generated code carries an OWASP Top-10 vulnerability (Veracode), only around 10.5% of agent outputs are both functional and secure (CMU SUSVIBES), and — worst of all — AI "fixing" its own code through iteration makes it more vulnerable, not less (+37.6% after five iterations, IEEE-ISTAS). The Lovable BOLA incident, where any free-tier user could read another user's private source code, was the moment it clicked: this isn't a tooling gap, it's a governance gap. Nobody had married team-based vibe coding with the discipline that keeps it safe.

Two things were missing from every tool we looked at:

A way for a team, not just a solo dev, to vibe-code an app together and end up with one working product instead of five disconnected fragments. Guardrails baked into the workflow itself, not bolted on afterward — so "vibe coded" didn't have to mean "unreviewed."

Braidly is our answer to both. The name comes from the idea at its core: each teammate's module is a single thread, and the platform's job is to braid them into one strong, integrated rope.

What it does

Braidly is a collaborative AI vibe-coding workplace built around a five-stage loop:

The Debate Room — a real-time chat where the team and an AI facilitator brainstorm an app idea together. The PRD Factory — when the discussion is ready, one click ("Finalize Discussion") has the AI generate a complete, per-person brief: a PRD, strict Build Instructions, a machine-readable contract.json, and auto-generated contract tests — all built from a shared contract every member codes against. Vibe Coding — each person builds their module against their brief, testing locally against auto-generated contract tests before they ever submit. File Submission — modules go into per-module storage, ready for integration. The AI Tech Lead — an orchestrator agent that verifies every submitted module against the shared contract, runs static security and quality scans, executes the contract tests, applies a bounded, minimal-diff AI fix loop for genuine seams (not full rewrites), and delivers one working, integrated app with a full audit-trail integration report.

The key insight is that Stage 5 — integration — is normally the hardest, riskiest part of any multi-person AI-coding effort. Braidly makes it tractable by turning it from "make sense of five people's unknown code" into "mechanically verify five people's code against a spec they all wrote against in the first place." We proved the whole loop end-to-end by building a tiny to-do app through the platform itself.

How we built it

We treated the project the same way we're asking Braidly's users to treat theirs: contract-first, documentation-first, with the entire architecture living in version-controlled specs before code:

Runtime: Node.js end-to-end (Express + native ws for WebSockets), chosen deliberately for a single-process, local-first MVP that runs on a modest laptop (Ryzen 7, 16GB RAM, 4GB VRAM) at $0 cost. LLM Gateway: every single AI call in the app routes through one module. It fails over Groq → OpenRouter → local Ollama (qwen2.5-coder:3b), so the product never depends on a paid API and can swap providers without touching a line of app logic. Frontend: started as a single-page vanilla HTML/CSS/JS app (zero build step, matching the $0/no-friction MVP philosophy), later evolved into a React + Vite + Tailwind SPA once the pipeline itself was proven, complete with a from-scratch Three.js "braided strands" hero animation. Storage: JSON files on disk with a serialized write queue for the MVP, with Supabase (Postgres + auth + RLS) layered in as the project matured. The Security Constitution: we distilled two research documents on vibe-coding failure modes into GOVERNANCE.md — ten non-negotiable security rules (parameterized queries only, ownership checks on every object access, no secrets in code, no verbose error leakage, CORS allowlists, rate limiting, and more), a supply-chain whitelist to stop slopsquatting (verifying every dependency exists on the real registry before it's allowed), anti-"Dark Logic" rules against silent error-swallowing, and a bounded, logged, minimal-diff policy for the orchestrator's fix loop. Every one of these is enforced mechanically in the generated contract.json and contract tests — not left to good intentions. Deployment: split across Vercel (static UI, reverse-proxied /api/*) and Railway (the Express/WebSocket/orchestrator monolith with a persistent volume), since Vercel's read-only, timeout-bound functions can't host a service that runs WebSocket upgrades and executes submitted code. Challenges we ran into: Model quirks under a $0 budget. Free-tier models change shape under you — we discovered mid-build that Groq's structured-output mode (json_schema) isn't actually supported on the model we planned to use for JSON generation, that a "reasoning" model puts its real output in a reasoning field instead of content (silently breaking streaming), and that our originally-planned model had been deprecated entirely (HTTP 404). Each of these meant redesigning the PRD Factory's JSON strategy around json_object mode plus code-side schema validation and a provider fallback chain, rather than trusting any single provider's guarantees. Rate limits as a first-class design constraint. Running an entire multi-agent pipeline on free tiers meant 429s were a when, not an if — we had to build retry-with-backoff, inter-module delays, and a full three-tier fallback chain (Groq → OpenRouter → Ollama) directly into the gateway, plus keep a recorded fallback demo video for the hackathon in case live traffic hit a wall mid-presentation. Making "integration" actually mechanical, not aspirational. It's easy to say "the AI will fix integration issues" — it's much harder to stop that AI from doing full-module rewrites that quietly discard the security rules you just spent so much effort embedding. We had to explicitly bound the orchestrator's fix loop (≤3 attempts, minimal-diff only, every attempt logged) after learning that AI "fixing" iteratively makes code more vulnerable, not less. Deployment topology surprises. We initially assumed a single free host would work for everything; it took hitting Vercel's ephemeral filesystem and WebSocket-upgrade limitations firsthand to realize the backend (with its persistent JSON/file storage and long-running orchestration calls) needed a genuinely different host than the static frontend. Keeping documentation from rotting. With a solo builder moving across many sessions (and occasionally different AI coding tools), the easiest failure mode was losing context between sessions. We made updating history.md, checklist.md, and PROJECT.md after every session a hard, non-negotiable rule — which paid off directly the one time a chat session was lost mid-build and the project was recovered purely from the docs. What we learned: The real bottleneck in AI-assisted team coding isn't code generation — it's integration, and integration only becomes tractable when the contract is written before anyone writes code, not reverse-engineered from finished modules. Security has to be a mechanically-checked gate, not a hope. Reading the research on vibe-coding failure rates changed how we thought about the whole product: "the AI will probably write secure code" is not a strategy, but "the AI's code doesn't pass until it clears a fixed checklist of adversarial checks" is. Constraints are a feature, not a limitation. Building for $0 on a 4GB-VRAM laptop forced an architecture (single LLM gateway, provider-agnostic routing, no build step in the MVP) that turned out to be exactly the kind of discipline the product itself is trying to teach its users. Iterative AI fixing has diminishing, even negative, returns — which reshaped how we designed the orchestrator's fix loop to be bounded and minimal-diff rather than "just keep trying until it passes." Most of all: the discipline the product enforces on its users — spec first, verify mechanically, document every session — is the same discipline that kept the project itself from collapsing across dozens of sessions, tool switches, and model changes.

Built With

• express.js
• javascript
• json
• react
• supabase
• tailwind
• vite