madcompany

UI-MVP development

For most new apps: a real, usable first version with a designed UI, as early as possible. It combines the other two: UI first, but only for the MVP's screens, and working end to end by the second release. This is the default for npx madcompany init.

Plan with: a product brief, the MVP scope, and a UX spec for just the MVP screens.

Releases

R1MVP screens

Only the screens the MVP needs, clickable on mock data, signed off in a UI sprint.

R2Working MVP

Those screens wired to a real backend: the smallest product a real user could use.

R3+Next features

One release per batch of features or feedback.

Steps

  1. Terminal
    npx madcompany init --mode ui-mvp

    Set up, then keep npx madcompany hq running

  2. Claude Code
    /bmad-product-brief

    What the product is and who it is for

  3. Claude Code
    /bmad-spec

    The MVP scope: the smallest set of features worth using

  4. Claude Code
    /bmad-ux

    The UX for the MVP screens only

  5. Claude Code
    /mc-staff

    Pick the team, then restart Claude Code once

  6. Claude Code
    /mc-plan-release

    R1: the MVP screens, clickable on mock data

  7. Claude Code
    /mc-ui-sprint

    Iterate on the screens with the team until you sign off

  8. Claude Code
    /mc-start

    The team builds R1; approve it in HQ → Releases, then npx madcompany ship R1

  9. Claude Code
    /mc-plan-release

    R2: the working MVP, the same screens on a real backend

  10. Claude Code
    /mc-start

    Build, approve, ship; then R3… from your feedback

You and the team

You

  • Decide the MVP scope: the smallest set of features worth using (/bmad-spec)
  • UX for those screens only (/bmad-ux)
  • Sign off the MVP screens in a UI sprint (R1)
  • Approve R1, then R2: the first version a real user could use
  • Do the Human help items the working MVP needs (database, auth provider, hosting)

The team

  • R1: only the MVP screens, clickable on mock data
  • At sign-off: writes the API contract those screens need
  • R2: builds the backend to that contract and wires the same screens to it, integrations still mocked where your keys aren't in yet
  • Then grows the product one release at a time from your feedback

Tips