How BioHackMe Is Built

1. Overview

BioHackMe is developed with an autonomous, multi-agent workflow. Instead of a single developer working linearly, a project-management layer breaks work into well-scoped tasks and hands each one to a specialized AI development agent ("crew") that owns a clean slice of the codebase.

The goal is fast, safe iteration on the preview build: many small, independently-verified changes that each pass type-checks, tests, and a static build before they reach a tester-facing preview environment. Production releases stay under direct human control.

2. The Delivery Pipeline

Work flows from a coordination layer down to the crews and out to a preview deployment:

  #openclaw / #mayor          (coordination & planning)
          │
          ▼
       bridge                 (routes scoped tasks to crews)
          │
          ▼
   Gas Town crews             (specialized dev agents)
          │
          ▼
  preview delivery            (preview.* environments)
                    

The coordination layer decides what should happen and in what order; the bridge routes each task to the crew that owns the relevant part of the code; the crew implements, verifies, and publishes the change to a preview environment for review.

3. Release Lanes & Boundaries

Two clearly separated lanes keep automation fast while keeping shipping decisions human:

• Preview / staging — delegated. The autonomous PM layer and crews land changes here automatically. This is where features are built, tested, and reviewed.
• Main / production — human-gated. Promotion to production is reserved for the project owner (Mike). Automated agents do not push to the main/production lane.

This boundary is a hard rule: every automated change targets a preview lane, and a human makes the explicit decision to promote anything to App Store / production users.

4. Convoy & the State Token

Because many agents can work in parallel, the system uses two simple ideas to stay consistent:

• Convoy. Related work moves together as an ordered group, so dependent steps land in the right sequence rather than racing each other.
• State token. A lightweight token represents "who holds the wheel" for a given piece of shared state. Whoever holds the token is the single writer at that moment, which prevents two agents from clobbering each other's changes. The token is handed off cleanly when work moves to the next stage.

Together these give parallel agents the safety of a single, ordered writer without forcing everything to happen one-at-a-time.

5. The Six Crews

Each crew owns a distinct slice of the product, which keeps changes isolated and reviewable:

• mike — generalist crew for cross-cutting work and anything that doesn't fit a single domain.
• dashboard — the home dashboard and weekly health-metric views.
• meals — meal logging, photo/text analysis, and nutrition features.
• health — health-data integration and metric processing.
• watch — the Apple Watch companion experience.
• release — builds, versioning, OTA/preview delivery, and the public website.

        ┌───────────────── crews ─────────────────┐
        mike   dashboard   meals   health   watch   release
          └────────── each owns a clean slice ──────────┘
                    

6. What We Don't Publish

This page is intentionally non-sensitive. The development process never exposes, and this overview never includes:

• Any API keys, bot tokens, or other credentials.
• Any user's personal health, nutrition, or genetic data.
• Private messaging identifiers or internal contact handles.
• Infrastructure specifics such as server, network, or remote-access details.

For how the app itself handles your data, see our Privacy Policy.