Starting implementation without an architecture sketch. Systems built in isolation that cannot connect when it matters.

---

What It Looks Like

Everyone is excited. The theme is good. The concept is locked. Someone opens the engine and starts coding immediately — no sketch, no discussion of how systems connect and no agreement on data flow.

Three hours later the programmer building combat and the programmer building UI are using incompatible data structures. Or the animation system assumes a state machine that does not exist. The discovery costs as much to fix as doing it right the first time would have cost to plan.

---

UNH4CK3D’s Rewrite

UNH4CK3D (LD36) had to rewrite their entire architecture mid-jam. The initial frontend/backend split could not support the features they needed later and the rewrite consumed hours that were budgeted for content. [1]

A 30-minute sketch before coding, agreeing on what the major systems are and how they connect, would have prevented it entirely. The sketch does not have to be perfect. It has to exist.

---

What a 30-Minute Sketch Covers

Not UML. Not a full spec. Just:

• What are the 4–5 major systems? (player, enemies, level, UI, audio)
• What data does each system own?
• How do systems communicate? (events, direct references, shared state)
• What are the integration points that could cause problems?

Draw it on paper or a whiteboard. Take a photo. Refer to it when integrating.

---

The False Urgency Problem

“We should start building” feels urgent when the theme drops. The 30-minute sketch feels like delay. Missing an integration point that requires a 3-hour rewrite at hour 30 is not faster than spending 30 minutes upfront. It is six times slower and happens when you are exhausted.

The sketch is not preparation instead of building. It is preparation that makes building faster.

---

Fix

BP #2 — Concept Lock on Day 1: architecture sketch is part of the concept lock session, not a separate step.