When a Row Is Enough
A named row is enough when the task shape differs through policy the existing engine already knows how to enforce. A template can express instructions, required stages can express proof boundaries, review default can express ordinary scrutiny, and a hint can improve launch without changing authority.
Rows are cheap to inspect, version, archive, and compare. They keep operators inside one queue and one record system. That economy matters: every new application adds runtime ownership, deployment, UI maintenance, health checks, documentation, and another place for state to diverge.
Do not mistake rich instructions for product pressure. A long template may still fit a row if it describes one recurring task. The stronger graduation signals are new lifecycle states, durable domain entities, specialized material rules, interactive workflows, or verification semantics the generic engine cannot represent.
Likewise, high stakes alone do not require an app. A strict review default and additional required stages may carry a rare but sensitive task safely. Birth software only when the generic contract would become dishonest or contorted.
Use the Row-Fit Questions
Ask whether every difference can be expressed as template, known stages, review policy, and hints; whether destination remains task-owned; and whether existing records can explain the work. If yes, keep the row.
A row should not call arbitrary code to stay enough. The moment it needs product-specific executable hooks throughout the lifecycle, you are hiding an application inside configuration.