The cost of rejection is the release cycle, not the size of the patch
Aliases: resubmit cost · review queue delay · calendar cost of rejection
What it is
After a store rejection, changing one button label and rebuilding half a feature look almost the same on the calendar: both re-queue, both wait, both may be re-inspected on unrelated screens. The cost of rejection is rejection cycle cost, not patch size. A design decision that treats “small to change” as low risk has misread the cost function. The gate is discrete days, not continuous hours.
This is not what the rules constrain, and not whether reviewers read source. It is the currency paid after failure: time, and specifically time on the release cadence.
Why it happens
Once the binary leaves the team, it enters a queue the team does not control. Rejection takes the product out; the fix goes in at the tail. Queue wait, version bump, possible re-review scope — none of these scale with diff size. One line of copy and two thousand lines of refactor, if both trigger a resubmit, cost the same order of calendar. A hotfix that still has to pass review is not faster for being small.
Risk should therefore be estimated as “will this trigger a submit,” not “how many hours to change.” Surfaces that, on failure, walk the whole package again — paywall, first-run, permission prompts — are high cycle-risk in design even when they are few pixels. Leaving them until freeze night stacks cycle risk on feature risk: the fix can be fast and you still wait another round.
Where it stops holding
Hot-update channels that skip re-review (asset packs on some stores, a web portion) lower the calendar cost of small edits; do not carry that lesson onto client changes that must pass binary review. Internal enterprise shipping has no store queue; cost returns to true patch size. Expedited or appointment windows change the wait distribution, not the step “one rejection ≈ one full re-entry.” Products that have been pulled and will not submit again have no cycle to pay.
Applying it
- Mark surfaces that trigger resubmit (payment, first launch, permissions, outbound links, metadata screenshots) as cycle-risk on the feature list, and close them before freeze rather than letting them ride the train as small items.
- After freeze, treat edits to those surfaces as a new release, not “two words while we are here.”
- Keep a minimal resubmit set ready: change only the named screens, and do not smuggle unreviewed interaction that would widen re-review.
- Verify against the last real or rehearsed rejection: calendar days from the letter to “reviewable again,” versus files actually changed. If days do not fall with file count, the cost model should be per queue entry, not per hour. In design review, ask of cycle-risk items “is shipping a week later acceptable?” — not “is the change big.”