madcompany

MVP-driven development

For products with little or no UI (APIs, CLIs, bots, data pipelines, agents), or whenever you want the smallest working thing first. R1 does one job end to end, on mocked integrations, and you try it through an API explorer or a CLI run. Every release after that is shaped by your feedback.

Plan with: a product brief and a short MVP scope: the one job it must do end to end. Architecture can be light.

Releases

R1MVP

The thinnest slice that works end to end, on mocked integrations, demonstrated through an API explorer (Swagger) or a CLI run.

R2Real integrations

Mocks swapped for real services once you have added the keys (see Human help).

R3+Next features

One release per round of your feedback.

Steps

  1. Terminal
    npx madcompany init --mode mvp

    Set up, then keep npx madcompany hq running

  2. Claude Code
    /bmad-product-brief

    The problem and the one job the MVP must do

  3. Claude Code
    /bmad-spec

    Optional: a short spec of the MVP scope

  4. Claude Code
    /mc-staff

    Pick the team, then restart Claude Code once

  5. Claude Code
    /mc-plan-release

    R1: the MVP, end to end on mocked integrations

  6. Claude Code
    /mc-start

    The team builds it; you watch HQ and answer Inbox and Human help

  7. HQ
    Releases → Approve

    Try it through the API explorer or the CLI demo first

  8. Terminal
    npx madcompany ship R1

    Merge into main and tag; push and deploy are in Human help

  9. HQ
    Human help

    Add the real service keys so R2 can switch mocks to live

  10. Claude Code
    /mc-plan-release

    R2, R3…: real integrations, then features from your feedback

You and the team

You

  • Say what the MVP must do end to end, and what is out (/bmad-product-brief, optionally /bmad-spec)
  • Try each release: the lead tells you how (Swagger UI at the integration port, or a CLI command)
  • Approve it or ask for changes in HQ → Releases
  • Add real keys in Human help when you want mocks switched to live services

The team

  • Designs the contract first (OpenAPI, schema), then builds the slice across layers in single-domain tickets
  • Puts every third-party service behind an adapter with a mock and a live version, switched per service in .env
  • Ships a way for you to try it: Swagger UI, a CLI demo script, or sample requests
  • Adds tests with every ticket; the merge queue re-runs them after each merge

Tips