When we started building Concept Sandbox, the temptation was obvious: build a full in-browser code editor with live preview, bundling, and hot reload. After all, that's what "prototyping tool" conjures in most developers' minds. We chose a fundamentally different path — a hub-and-spoke architecture where Concept Sandbox is the hub and external prototyping tools like v0, Lovable, and Bolt.new are the spokes.
The Monolith Trap
Building a browser-based compiler is a massive undertaking. Projects like StackBlitz's WebContainers and CodeSandbox's Sandpack have invested years of engineering into running Node.js in the browser. For a solo-creator tool, that level of infrastructure investment creates a paradox: you spend so long building the tool that you never ship the product.
We saw this play out firsthand. Early prototypes with an embedded Monaco editor and esbuild-wasm bundler consumed three months of development time and still couldn't handle basic npm imports reliably. The maintenance burden alone — keeping up with new framework versions, handling edge cases in module resolution, supporting TypeScript — would have become a full-time job.
Why External Tools Are Better
The insight that changed our direction was simple: the best prototyping tools already exist, and they're getting better every month. Vercel's v0 generates production-quality React components from natural language prompts. Lovable creates full-stack applications with databases and auth. Bolt.new spins up complete development environments in seconds.
These tools each have dedicated teams of engineers improving them daily. By integrating with them instead of competing, we get several advantages:
- Always up to date. When v0 adds support for a new shadcn component, our users get it immediately. We don't need to ship an update.
- Best-in-class quality. Each spoke tool optimizes for its specific strength. v0 excels at UI generation. Lovable excels at full-stack scaffolding. We don't need to be mediocre at everything.
- Reduced attack surface. Running arbitrary code in the browser introduces serious security concerns. By offloading execution to sandboxed external services, we avoid an entire class of vulnerabilities.
How Hub-and-Spoke Works in Practice
In Concept Sandbox, every concept has a stage: Idea, PRD, Prototype, or Archive. When a concept reaches the Prototype stage, the user doesn't open a code editor inside our app. Instead, they click "Build with v0" or "Build with Lovable," and we pass the concept's PRD — the structured requirements document our AI helped them create — as context to the external tool.
The external tool opens in a new tab. The user builds their prototype there, with all the power of that dedicated tool. When they're done, they paste the deployment URL back into Concept Sandbox, and we store it as an external link. The concept card then shows a live preview iframe of their prototype.
This flow is intentionally simple. There's no complex state synchronization, no WebSocket connections to manage, no build errors to debug. The concept's PRD serves as the bridge between planning (our strength) and building (their strength).
The Integration Layer
Our integration with external tools goes beyond simple links. When a user clicks "Build with v0," we construct a prompt that includes their concept's title, description, and the full PRD content. This prompt is URL-encoded and passed as a query parameter to v0's generation endpoint. The user lands in v0 with their requirements already loaded — no copy-pasting required.
For tools that support it, we also pre-configure framework preferences. If a user's PRD specifies "Next.js with Tailwind," we encode that in the handoff so the external tool starts with the right stack.
Trade-offs We Accept
This architecture isn't without downsides. We can't offer a seamless, single-window experience. Users need to context-switch between tabs. We can't track exactly what code was generated or offer inline editing of prototypes. And we're dependent on external services — if v0 goes down, that spoke is temporarily unavailable.
We accept these trade-offs because the alternative — building an inferior in-browser IDE — would be worse for our users. Solo creators don't need another mediocre code editor. They need a fast path from idea to working prototype, and that path runs through the best tools available.
Looking Ahead
The hub-and-spoke model also gives us flexibility for the future. When new prototyping tools emerge — and they will — we can add them as spokes without redesigning our core architecture. We're watching tools like Replit Agent, Cursor Composer, and GitHub Copilot Workspace closely. Any tool that can accept structured requirements and produce a deployable prototype is a potential spoke.
Our job is to be the best hub: the place where ideas are captured, refined into clear requirements, and handed off to the right tool for execution. That's the product we're building, and the hub-and-spoke model makes it possible.