Builder.run

Inspiration

Builder.run is inspired by configurable systems like Drupal, where a small set of primitives can be combined into custom information systems. I wanted to explore what that model looks like in an agentic world, with the application spec as the canonical artefact rather than generated code.

What it does

Builder.run is a local-first application runtime that humans and agents can build, shape, and use together. Apps are composed from types, fields, views, summaries, forms, pages, widgets, and rules, and the browser runtime turns that spec into working software backed by local SQLite storage.

How I built it

The current runtime uses Svelte 5, SvelteKit 3, TypeScript, Tailwind CSS, shadcn-svelte, and wa-sqlite in a Web Worker, with browser-local persistence through OPFS where available. The project was built in roughly three days using an agent-heavy development workflow with Codex and Grok, which made it possible to iterate quickly on the runtime, WebMCP integration, and UI.

WebMCP is exposed in two layers: fixed builder tools let an agent shape the application itself, while application tools are generated dynamically from the live app spec so the agent can immediately use the app it just created.

Challenges I ran into

I started late, so a major constraint was deciding what to prioritise. I focused on proving the complete loop: build the app, generate its capabilities, use them, then evolve the app again, rather than expanding the feature surface.

The biggest challenge was keeping the system based on a small set of reusable primitives rather than adding special-purpose features for every use case. WebMCP also introduced lifecycle challenges because the tool surface itself can change as the application changes, without disrupting ordinary data operations or in-flight tool calls.

Accomplishments that I'm proud of

I've been thinking about configurable information systems since I first started using Drupal more than 15 years ago. This hackathon gave me the excuse to finally turn that long-running idea into a working runtime. The part I am most pleased with is the full loop:

Agent shapes app → spec changes → UI, storage, and tools update → agent uses the new capabilities.

The generated WebMCP tools are not a fixed API bolted onto the application; they are derived from the application the user and agent create together.

What I learned

The main thing I learned is that WebMCP can be more than an integration layer for an existing website. In a malleable runtime, it can become part of the application model itself, allowing agents both to shape the software and immediately use the capabilities they create.

What's next for Builder.run

Builder.run is still an early runtime, with plenty of rough edges to refine — particularly around the UI and the current Rules experience. Next I want to explore richer primitives, expand Rules into more capable workflows and automations, support more flexible presentation, make app data more portable, strengthen permissions and actor support, and build hosted or multiplayer runtimes that can consume the same application spec.

Built With

• bits-ui
• indexeddb
• opfs
• pnpm
• shadcn-svelte
• sqlite
• svelte-5
• sveltekit-3
• tailwind-css
• typescript
• vite+
• wa-sqlite
• web-workers
• webassembly
• webmcp