Skip to content
STACK IT FIRST
Install the skills
Method skill · 03 After you ship

Tier upgrade

Checks whether a project has outgrown its tier (MVP, Growth, Scale) using Stack It First's signals, and plans the move to the next tier as small, ordered changes instead of a rewrite.
v0.5.0 Updated

Most re-architectures happen too early or all at once. This skill checks the project against the next tier’s signals and, only if they hold, plans the move as a sequence of changes the agent can make and verify one at a time.

When to use

  • Someone proposes services, queues, Kubernetes, a separate API or a rewrite.
  • The product has new constraints: paying users, a second team, a compliance audit, a second region.
  • A periodic check (once a quarter) of whether the stack still fits.

Steps

  1. Find the current tier. Read docs/decisions/ for a stack decision (see stack-it-first). If there is none, infer the track, tier and profile from the repository and confirm with the user.
  2. Open references/<track>.md and read the next tier’s section: its scope, its signals, and what changes when you get there.
  3. Check every signal against evidence, not opinion: users and revenue, people committing in the last 90 days, incidents, regions, audit requirements, response-time numbers. Mark each signal met, not met, or unknown, and ask about the unknowns.
  4. Decide.
    • Fewer than half the signals met: stay. List what would change the answer and stop here.
    • Otherwise: plan the move.
  5. Plan the move as ordered steps, each one shippable on its own and reversible: contract first (typed API or schema), then the boundary (module, then service), then the infrastructure. For each step write what changes, what stays the same, how to verify it, and how to roll back.
  6. Compare with the target stack on stackitfirst.com for the same profile at the next tier. Adopt only the parts the signals justify.
  7. Record the decision as a new ADR next to the original stack decision.

Rules

  • No big-bang rewrites. Every step leaves the product working and deployed.
  • Split by team boundary, never by noun. One team, one deployable is fine at any size.
  • Contracts before boundaries: a generated client or schema must exist before code moves to the other side of it.
  • Keep what the “what does not change” section lists: boring infrastructure, one migration tool, tests the agent runs before every change.

Output

A signal table (signal, evidence, met / not met / unknown), the decision, and, if moving, the ordered step plan and the ADR.