Lock Version 1. After today, no new features — only bug fixes.

Every piece of software you've ever used — every game, every app, every website — was "frozen" before it shipped. The team stopped adding features, cleaned up, and said "this is Version 1." Today, you do the same thing.

Video: Git Explained in 100 Seconds (2 min)

Fireship explains Git — the tool professional developers use to track versions of their code. When a team does a "code freeze," they're using version control to lock down what ships. This is the system behind every major software release.

Discussion after watching: Why would a team STOP adding features before launch? Isn't more features always better? What could go wrong if you keep changing code right up until release day?

A real studio freezes code before release. Code freeze means: the feature set is final. You can fix bugs, but you cannot add anything new. This discipline prevents last-minute chaos.

After today:

  • No new features
  • Only critical bug fixes
  • No "just one more thing"
  • No refactoring
  • No experiments

You need: A piece of paper and a pen. This is physical. This is real.

Write the following contract by hand:

CODE FREEZE CONTRACT

I, _______________, agree that _______________ Version 1.0 is DONE.

I will not add features.

I will not add mechanics.

I will not "just try one more thing."

I will only fix crashes and game-breaking bugs.

Signed: _______________    Date: _______________

Witnessed by: _______________

Both kids sign their own contract. Then they sign each other's as witnesses.

Put the contracts on the wall, the fridge, or next to the computer. This is how professionals ship. The contract is a promise to your future self: "I will not break what works."

This feels silly but it works. The physical act of writing and signing creates real commitment. When the urge to "just add one thing" hits tomorrow, point at the contract.
  • Add "// Version 1.0 — Code Freeze" comment at top of main.js
  • Tag version in HTML header or title
  • Clean folder structure (remove test files)
  • Remove all test/debug variables
  • Confirm localStorage compatibility
  • Optional: add simple start screen (title + "Press Start")
  • Verify game loads cleanly with no console errors
    •
    Checkpoint

    Both projects load cleanly. No unused code. No console errors. The game is frozen.

    This IS the freeze. Nothing new after today.

    "Code freeze except for this one thing..." — NO. A freeze with exceptions is not a freeze.

    Deleting code that's actually needed — test after every deletion. Remove only what you're certain is unused.

    Not testing after cleanup — cleaning up files can break paths and references. Verify everything still loads.

    Forgetting to remove debug code — search for console.log, test variables, and temporary hacks. Remove them all.

    The contract is the most important part of today. Take it seriously. Don't laugh it off. The kids will follow your energy. If you treat it as real, they will too.

    Ask: "Why do professional teams freeze code?" Answer: because every change before launch is a risk. The game works NOW. Changes might break it. Freezing protects what works.

    Expect resistance. Both kids will want to add "just one more thing." That's the whole point. Learning to stop is harder than learning to build. This is real-world software discipline — and life discipline.

    The cleanup tasks matter. Removing debug code, cleaning file structure, and verifying a clean load are professional habits. Frame this as "preparing for launch" not "boring cleanup."

    Tomorrow: We put your game on the internet for the world to play. The code is frozen. Tomorrow it goes live.