← Back to Portfolio

Nimbus Websites

The public platform of Nimbus — Flow and Lab — built by Nimbus. Our first portfolio item and a complete example of idea materialization from brief to deployment.

nimbusplatformflowlabmaterializationpilot
Client: Nimbus
Completed: 2026-03-14

Nimbus Websites

This is our first portfolio item. It is also Nimbus demonstrating itself: the public platform that explains Nimbus, built by Nimbus. We use it here as the clearest example of complete materialization — from idea to live product — because we lived the full journey.

What Nimbus Is

Nimbus is an Idea Materialization System. It turns ideas into real systems — websites, applications, tools — through structured briefs and coordinated AI agents. The core proposition: give us a clear idea and we will materialize it. Not as a one-off prototype, but as a system that understands context, follows constraints, and produces work that fits.

Nimbus is not a single AI. It is a network of specialized agents — planner, researcher, coder, reviewer — each with a defined role. They collaborate through artifacts: briefs, findings, code, specs. No chat handoffs. Documents pass between agents. That structure makes the output traceable and reliable.

The brief is the anchor. Every project starts with one: objective, requirements, constraints, success criteria. The brief drives planning. Planning produces features. Features become tasks. Tasks flow through a queue. Humans appear at checkpoints — approving the brief, validating output — but the execution runs through the system.

How Nimbus Works

  1. Idea — A concept, a need, or a project request. It can come from a client, from an internal ideabox, or from a conversation.

  2. Brief — The idea is captured in a structured brief. What are we building? Why? For whom? What does success look like? The brief is the contract between human intent and machine execution.

  3. Planning — Nimbus plans. In Living Mode, the planner reads the brief and client-input, produces capability-level features, and creates Linear issues. Each feature is a bounded unit of work.

  4. Execution — Tasks flow through the queue. Build, execute, QA. Agents generate file specs, apply them, run checks. Retries are idempotent. Structural guardrails prevent drift. One feature at a time, sequentially.

  5. Materialization — The result is real: code in the repo, deployments live, content published. The idea has become a thing.

Why We Built the Sites as a Pilot

We needed a public face for Nimbus. Visitors should understand what we do, see what we produce, and start a project through conversation. Two sites: Nimbus Flow (the main site and Elin intake) and Nimbus Lab (this archive).

We also needed to stress-test Nimbus. The nimbus-websites project became the pilot for Living Mode — the first full run of our structured planning-and-execution workflow on a real, public-deliverable project. If Nimbus could build its own platform, it could build anything. The brief went into the ideabox. We hit go. We learned by doing.

The Process: Idea to Product

1. Brief (ideabox) — The project brief defined the platform: explain Nimbus, demonstrate capabilities, enable intake through Elin. Two sites. Static-first. File-based content for the Lab. No CMS. Security and isolation for the gateway. The brief was the single source of truth.

2. Client-input — We ingested Elin personality docs, Nimbus architecture, pricing, narrative. Context that agents would need to make decisions. All of it went into client-input/.

3. Planning (Living Mode) — The planner read the brief and client-input. It produced two features: System Introduction (the public Flow site) and Idea Materialization Process (Elin intake). Each became a Linear issue with Intent, Scope, and Success Signals. No repetition, no vague echo — distinct, grounded content.

4. Execution — Build branches. File specs. Idempotent apply. QA after each run. When something failed — wrong paths, non-idempotent creates, missing env — we fixed the system, not just the project. Context paths canonicalized. Guardrails added. Git helpers hardened. The pilot surfaced system debt; we paid it down.

5. Structural evolution — The project had legacy structure (old website/, partial scaffolds). We ran a monorepo transition: apps/nimbus-flow, apps/nimbus-lab, shared packages. Turborepo. Explicit app roots. Guardrails rejected file specs that targeted unknown roots. Structure became intentional.

6. Deployment — Both sites deploy from the same repo via a CDN-backed host. Flow and Lab go live. The Lab got a Content Management Agent so we could add entries like this one through conversation. The loop closed.

The Result

  • Nimbus Flow (nimbusflow.agency): Explains Nimbus. Hosts Elin. Visitors start a project through conversation. No forms — a dialogue that produces a structured brief. Backed by a database, an LLM provider, an email service, and bot protection. Isolated from internal Nimbus. Static-first with a small gateway.

  • Nimbus Lab (nimbuslab.agency): The living archive. Experiments, insights, portfolio. File-based. No CMS. The CMA creates content from natural-language requests. You commit and push. The Lab updates.

  • The proof: Nimbus built the platform that demonstrates Nimbus. Idea → brief → plan → execution → deployment. Complete materialization. This portfolio item is that story.