Case notes: what we learn from every release
Every project leaves a record, whether or not anyone writes it down. We choose to write ours, because a lesson remembered is worth little and a lesson recorded can be learned by the whole team. These case notes are how we capture what we decided, what happened and what we would do differently, across both our own games and the projects we take on for studios.
Why we keep case notes
A studio without records keeps relearning the same lessons. A change that worked two years ago is reinvented badly; a mistake made in one project is repeated in the next because nobody remembered why it failed. Writing it down is the cheapest way to build memory into a small team.

Case notes also make honesty easier. When a decision and its result are both written, it becomes much harder to tell a comfortable story about a project after the fact. The record keeps us faithful to what actually happened, which is the only version worth learning from.
What goes into a case note
A good case note is short and specific. It records the situation, the decision, the expectation and the outcome, and it ends with the lesson. It is not a report for a client and not a marketing story; it is a working document for people who will face a similar problem later.
- The problem, stated in a sentence.
- What we decided and why.
- What we expected to happen.
- What actually happened.
- What we would do differently.
That last line is the one that matters most, and it is the one most likely to be left out. A note that ends with the outcome alone is a diary; a note that ends with a lesson is a tool.
Learning from our own releases
Our own games are the richest source of case notes, because we live with the results for a long time. When Solitaire Grove taught us that subtraction outperforms addition, that lesson went into the notes and shaped every title after it. When Flop Ball Jump corrected our sense of feedback and difficulty, the note changed how we advise clients as well.
The table below is the shape of a typical lesson from our own titles, from the situation to the habit it changed. Each one began as an observation during play and ended as a rule we now keep.
| Situation | What we learned | The habit it changed |
|---|---|---|
| A calm game felt stressful | Removing pressure helped | Design by subtraction |
| A run felt unfair | Feedback, not rules, was wrong | Tune the feel first |
| A daily loop felt like a debt | Forgiving calendars retain | Reward return, never punish |
| A puzzle felt lucky | Fairness must be visible | Check every board |
Learning from client projects
Client work produces its own lessons, and we are careful about how we record them. A case note about a client never names them without permission and never includes anything that could identify their game or their numbers. We record the method and the reasoning, and we leave the identity out.
That restraint is not only a courtesy. It is also what makes the notes useful, because the transferable part of any project is the method rather than the particular game. A lesson stripped of names travels further and reads more honestly than one that trades in specifics it should not share.
Reviewing the notes before the next project
The notes only earn their keep if they are read. Before a new project we go back through the relevant ones and ask what applies, so that the team starts from what it already knows rather than from scratch. This small ritual has saved us more than once from repeating an expensive mistake.
We also revise the notes when we learn something new, because an understanding that never changes is usually an understanding that stopped looking. A note is a living document, and the day it becomes a museum piece is the day it stops helping anyone.
When a project goes wrong
The most valuable case notes are the ones about things that did not work. A failed change, a misjudged feature, an assumption that turned out to be wrong: these are the notes that save the most time later, and they are the ones a proud studio is most tempted to leave unwritten. We make a point of writing them first.
A note about a mistake is not a confession; it is a map of a place not to go again. Recording it plainly, without blame and without softening, turns an expensive lesson into a cheap one for whoever faces the same terrain next. The habit costs nothing, and it is the difference between a team that learns and one that merely endures.
Memory as a studio asset
For a small studio, accumulated judgement is the main thing we have that a larger competitor cannot simply buy. Case notes are how that judgement survives the person who earned it, and how a lesson learned in one project reaches the next one without being lost in the gap between them. Writing them down is tedious, and it is one of the few habits that makes a small team quietly formidable over time.
Read next
About Dytbaat: a studio and consultancy
Three industry veterans, one studio, and a focus on making good games great.
Our approach: data, play and iteration
Why we measure before we change anything and how iteration shapes our work.
The tools behind our games and analysis
The everyday software and methods our designers, engineers and analysts rely on.