Indie Devlog #05: The Product Bootstrap System

Sunday March 15 2026·3 min read

Indie Hacking Product Development SaaS Automation

After the first few products, a pattern emerged. Every new app in the monorepo needed the same setup: documentation, marketing website, local pre-commit hooks, GitHub CI, deployment pipeline, App Store screenshots, store listing copy, and a Flutter scaffold. I had personal skills for each piece — saas-doc-setup for docs, setup-pre-commit for git hooks, app-store-screenshots for marketing assets — but there was no single command to run them all in order.

The problem was not that the work was hard. It was that I had to remember the sequence, check what was already done, and switch between three AI agents (Cursor, Claude Code, and Hermes) without missing a step.

So I built microbyte-product-bootstrap.

The orchestrator pattern

The system is simple: a hub skill that reads a JSON manifest and dispatches work to leaf skills and runbooks. Each product gets a bootstrap.jsonc that tracks phase status:

{
  "$schema": "../../docs/bootstrap/bootstrap.schema.json",
  "product": "Dream Journal",
  "slug": "dream-journal",
  "mode": "greenfield",
  "capabilities": {
    "mobile": false,
    "api": false,
    "website": true
  },
  "phases": {
    "docs": { "status": "done", "completedAt": "2026-05-24" },
    "website": { "status": "pending" },
    "localCi": { "status": "skipped", "reason": "website-only" },
    "githubCi": { "status": "pending" },
    "websiteDeploy": { "status": "pending" },
    "screenshots": { "status": "skipped", "reason": "capabilities.mobile is false" },
    "storeListing": { "status": "pending" },
    "mobile": { "status": "skipped", "reason": "capabilities.mobile is false" }
  }
}

The orchestrator loads the manifest, validates it against a JSON Schema, lists pending phases, and walks through each one. If the phase has a dedicated leaf skill (saas-doc-setup, setup-pre-commit, app-store-screenshots), it loads that skill. Otherwise it reads a numbered runbook from docs/bootstrap/phases/.

Two modes: greenfield and harden

New products start from scratch with --mode greenfield. The system copies a template manifest, then runs phases 1 through 8 sequentially.

Existing products that drifted from the standard use --mode harden. The orchestrator scans the filesystem for signals — a docs/PRD.md means docs are done, a website/package.json means the website exists, .github/workflows/*.yml means CI is configured — and merges the results into the manifest. It only runs the phases that are missing.

harden dream-journal
  → scanning filesystem...
  → docs: found (docs/PRD.md, docs/branding.md)
  → website: found (website/package.json)
  → localCi: missing
  → githubCi: missing
  → websiteDeploy: missing
  → screenshots: skipped (no mobile)
  → storeListing: missing
  → mobile: skipped (no mobile capability)
  → pending phases: localCi, githubCi, websiteDeploy, storeListing

This was surprisingly useful. I ran it on dream-journal — a product I had been working on for weeks — and discovered I had never set up CI or a proper deploy pipeline. The scan caught it before I shipped.

Multi-agent by design

The skill must work across three AI agents with different capabilities. Cursor has the Skill tool and Task subagents. Claude Code has a similar Skill tool. Hermes Agent uses skill_view() and sequential terminal commands.

The hub skill's SKILL.md is written in agent-neutral language. Instead of "use the Task tool to run phase 1", it says "load the leaf skill and execute the phase runbook." Agent-specific notes live in a separate reference file — for Hermes, references/hermes.md maps the same steps to skill_view() calls:

# Hub workflow (all agents)
Load the leaf skill and execute the phase runbook.

# Hermes equivalents (references/hermes.md)
skill_view("microbyte-product-bootstrap")
skill_view("saas-doc-setup")        # docs phase
skill_view("setup-pre-commit")      # localCi phase

An install script symlinks the skill into all three agent homes:

bash "$MICROBYTE_SAAS_ROOT/docs/bootstrap/scripts/install-skill.sh"

What I learned

Template drift is real. The system templates come from Fiscify — workflows, deploy configs, CI snippets. When Fiscify changes, the templates diverge. I added a quarterly refresh note to the README, but realistically this needs automation too.

Version 1 is opinionated. The eight phases (docs, website, local CI, GitHub CI, deploy, screenshots, store listing, mobile) are ordered and sequential. Non-mobile products skip three phases via the capabilities flag. But the system assumes every product wants a website, which is not always true. That is a v2 problem.

The manifest is the durable record. Before this system, I kept setup notes in my head or scattered across agent sessions. The bootstrap.jsonc now tracks exactly what has been done, when, and why a phase was skipped. A month later, I can look at a product's manifest and know its maturity at a glance.

The result

Setting up a new product used to take two to three days of context-switching between agents, documentation, and manual checks. With the bootstrap system, I invoke the skill, approve each phase as it completes, and have a fully set up product in about two hours.

The time saved is not the execution — it is not having to remember the sequence every time.

For suggestions and queries, just contact me.