AP #3: Late Design Decisions
Core design decisions made on day 2. Architecture constraints discovered after significant building has already happened.
What It Looks Like
Day 2, several hours in: someone raises a design question that should have been answered on day 1. A mechanic needs to be added that changes how core systems connect. Or a visual direction gets decided after the programmer already built the rendering pipeline for something different.
Everything built before this decision now has to accommodate it or get rebuilt.
The Colossorama Case
JorgeGameDev reflected on Colossorama (LD36) with a clear lesson: “Important design decisions should be made on the first day instead of delaying them.” [1] The upgrade system was not an optional feature. It was a core mechanic that affected how progression worked across the entire game and it was not fully designed until the second day.
Content built on day 1 did not account for it. The system had to be inserted into a partially built game and features that conflicted with it had to be cut. One late decision cascaded into cuts across the board.
The Architecture Dimension
Late design decisions are not always about mechanics. Architecture decisions discovered late cost more. UNH4CK3D (LD36) had to rewrite their entire architecture mid-jam because the initial structure could not support features added later. [1]
A 30-minute architecture sketch at hour 4 would have cost 30 minutes. The rewrite cost hours.
Why It Happens
Teams sometimes delay hard design decisions because they are hard. It is easier to start building the obvious parts and figure out the complicated stuff later. Or the decision only surfaces once building starts and reveals the problem.
Both situations are addressable with more thorough concept work at the start.
Fix
BP #2 — Concept Lock on Day 1: all critical design decisions locked within the first 4–6 hours, including architecture approach.
See also AP #8 — No Architecture Planning for the architecture-specific failure mode.