Introduction

Most project tools are a list of things to do. That works right up until the moment a decision has consequences — a tooling order, a regulatory submission, a launch date you cannot move. Then the question stops being "what is left?" and becomes "are we actually allowed to proceed?"

cadence. is built for that second question.

The model#

A project in cadence. is a sequence of phases. Each phase holds tasks, and each phase ends at a gate: a short list of criteria that has to be met before the next phase can start. Nothing else in the product overrides that rule. You cannot complete a phase with unmet criteria, and completing one automatically starts the next.

That single constraint changes how a project reads:

• Progress means something. "Phase 3 of 5" is a claim about evidence, not a percentage of tickets closed.
• Disagreement happens early. Criteria are written when the phase starts, not argued about when someone wants to ship.
• The audit trail is a by-product. Who passed which criterion, on what evidence, and when — recorded because the workflow needed it, not because someone was told to keep records.

Who it is for#

cadence. was designed around new product development and portfolio teams — the kind where R&D, packaging, regulatory, marketing and supply chain all move at once and a missed sign-off costs a quarter. It suits any team that has to answer to someone outside the team.

It is a poor fit if your work has no meaningful decision points. A weekly content calendar does not need gates, and adding them will feel like paperwork.

What you get#

A note on vocabulary#

cadence. uses the language of stage-gate, because that is what it is. If your organisation says stage where we say phase, or tollgate where we say gate, the mapping is one to one — you can rename them in your templates and never think about it again.

Next: build one. The quickstart takes about ten minutes.