Best Simple System for Now, and Why It Matters to Game Production
A framework for game teams to stay fast today without trapping themselves tomorrow.
Deep Dive by NotebookLM.
Building the simplest system that meets today’s needs keeps your code clean and adaptable and reduces long-term risk without over-engineering for the future.
BSSN balances speed and quality, helping teams avoid the trap of messy prototypes becoming brittle foundations that slow down production later.
Strong early systems and daily habits of simplicity prevent technical and emotional debt, keeping teams motivated and delivery on track.
Those who have worked with me often hear me say, “A good plan fiercely is better than the perfect plan.” It’s my shortcut version of the well-known line, “A good plan violently executed now is better than a perfect plan executed next week,” from General George S. Patton Jr., the World War II leader. In this context, “violently” is about vigour and determination, not violence. The quote is a potent reminder that action beats hesitation. It pushes individuals and studios to accept imperfection as part of the process, using momentum to unlock growth and improvement over time.
But while this mindset is valuable, it can come across as all-or-nothing. It risks sounding like you either charge ahead or do nothing at all, with no middle ground. It also doesn’t give you a framework to follow; it’s a mindset, not a method. Without something more structured, it’s easy to lose balance between moving fast and making thoughtful, sustainable choices.
Best Simple System for Now
Last month, I came across a brilliant blog post by Daniel Terhorst-North called ‘Best Simple System for Now’. He challenges the typical trade-off between messy, rushed code and slow, over-engineered perfection. Instead, he argues for building the simplest system that meets today’s needs to a sensible standard — no guessing at future requirements. This approach, known as BSSN, focuses on writing clean, maintainable code that solves the problem in front of you. It’s easier to change later, balances speed with quality, and reduces risk over time.
BSSN offers a practical middle ground in software development. It avoids the extremes of hasty shortcuts and heavy, speculative design. The goal is to build just enough: a lean, fit-for-purpose system that does the job now without layering on complexity you don’t need yet. There is no extra abstraction. No future-proofing for its own sake. Just clear, reliable code that’s only as robust as it needs to be — nothing more, nothing less.
The name Best Simple System for Now is intentional. Each word matters:
For Now: Build for what you know today. Avoid guessing at future needs. Developers often try to plan, but this usually leads to over-engineering. BSSN keeps your focus on the real, immediate problems.
Simple: Skip future-facing designs you don’t need yet. Overbuilding leads to rework and compromises. As Antoine de Saint-Exupéry put it, simplicity means removing what is unnecessary. A simple system stays light and adapts more easily later.
Best: Simplicity is not an excuse for cutting corners. Get the quality right for the context. Core features need rigour; prototypes need speed. Sketching code is a valuable skill; write just enough to move forward, with the option to refine later.
Terhorst-North also tackles some common objections to BSSN:
“It’s overkill for a prototype.”- Some believe prototypes should be throwaway hacks. However, successful prototypes often grow into production systems. They’ll be painful to extend and maintain if messy from the start.
“It’s incomplete.”- There’s a concern that BSSN leaves products unfinished. Delivering part of the customer’s need early is often more valuable than waiting for perfection. Most value comes from core functionality. Look at the early versions of the iPhone or Google Docs. They offered a focused, helpful subset from day one. This follows the “worse is better” idea: ship sooner and improve over time.
“It’s inefficient.”- Some worry that constant rework wastes effort. But timing matters. Big-bang projects carry high risk because you only see returns at the end if they land. BSSN spreads the risk by allowing earlier revenue and faster feedback. The Cost of Delay, which is the money lost from slow delivery, and Opportunity Cost, which is the value of what else you could have built, both point to the same thing: long, drawn-out projects are the fundamental inefficiency.
The approach stands on a few core principles that keep it grounded and practical:
Discipline: Simplicity takes ongoing, deliberate effort. It’s not a set-and-forget mindset. Like keeping a kitchen clean, it’s about regular maintenance. Leave things unattended, and clutter builds up fast. But when the codebase stays tidy, it naturally encourages more good habits. Clean code is easier to work with, which lowers friction and keeps the team moving at a healthy pace. It creates a positive loop: the simpler things are, the simpler they stay.
Habits: BSSN isn’t a one-off decision; it’s a daily practice. It means staying mindful of the temptation to generalise too early, abstract too soon, or over-invest in problems that haven’t fully formed. Good habits help you spot when you’re overworking an idea or, just as risky, under-investing in something that deserves proper attention. It’s about staying present, reading the situation, and making grounded decisions rather than following arbitrary rules or assumptions.
Courage: New approaches always feel uncomfortable at first. BSSN is no different. Terhorst-North suggests a simple principle: “Trust me once.” Give the approach a proper try, knowing you’re not locking yourself in. You’re simply testing a different way of working, with the freedom to adjust if it’s not the right fit. Courage here isn’t about reckless leaps; it’s about permitting yourself to try without fear of commitment.
Humility: Staying humble keeps you adaptable. You’ll never have perfect foresight, and that’s fine. The Bruce Lee mindset of “be like water” fits perfectly. By keeping things simple, you stay flexible and ready to respond to whatever changes come your way. It’s about trusting the future to handle future problems with more knowledge than you have today. Humility helps you let go of premature assumptions and focus on building what’s needed.
These aren’t just nice-to-haves. They are what make BSSN work day to day. They help you balance speed and quality, stop complexity from creeping in, and build an adaptable system as you learn and grow. Without them, it’s too easy to slip back into old habits or fall into the traps of overbuilding or cutting corners.
BSSN Applied to Game Production
I’ve seen it repeatedly across game teams: prototypes that were meant to be throwaway experiments somehow end up living on as the foundation of the live game. It usually starts innocently enough. A team hacks something together for a pitch, a demo, or an internal playtest. It works well enough to show promise, so momentum carries it forward. No one plans for this prototype to become production code, but before you know it, you’re building entire features and systems on top of shaky foundations.
The trouble is that early code was never designed to go the distance. It wasn’t built for scale, it wasn’t built for change, and it certainly wasn’t built for live ops demands. Fast-forward a few months, and you’ve got a team struggling to add what should be simple features, say, a tweak to an event system, a slight extension to progression, or a new monetisation mechanic. From the outside, it looks like a quick win. But under the surface, you’re fighting brittle, tangled code never meant to handle real-world complexity.
What makes this worse is that the people who wrote the original prototype have often moved on by the time the game is scaling. New teams inherit the tech debt without the full context of how or why things were built the way they were. They’re left untangling spaghetti code, reverse-engineering decisions, and working around fragile dependencies. This slows everything down. What should take days stretches into weeks. Stakeholders get frustrated. Teams burn out. And worst of all, it becomes harder and harder to justify the time needed to clean things up properly because you’re stuck in a cycle of urgent feature requests.
I’ve watched teams hit this wall more times than I care to count. It’s one of the most common root causes behind production teams struggling to deliver what seems like “small” asks. The effort to ship a new live event or tweak progression ends up wildly disproportionate to the perceived value, all because the foundations were never strengthened after the prototype phase.
This isn’t just technical debt; it becomes emotional debt, too. Frustration builds when teams feel trapped by poor foundations. As leaders, recognising this early makes all the difference.
This is precisely where BSSN shines. It allows you to build simple, clean prototypes to grow into production without carrying unnecessary baggage. You’re not over-engineering from day one, but writing code and building systems carefully to avoid future traps. You’re keeping the door open for iteration without mortgaging your future velocity.
For game teams, this isn’t theory. It’s survival. Build your early systems, assuming they might live longer than you expect. Give them just enough structure so that if and when they move into production, you’re not stuck fighting your own past decisions. It’s a balance and takes practice, but once you’ve felt the pain of battling a messy prototype in live ops, you never want to repeat that mistake.
And it’s not just a technical problem. It’s a morale issue that eats away at teams over time. When smart, capable people keep hitting invisible walls because systems fight them at every turn, it slowly drains their energy and belief. You start to hear familiar frustrations like “This should have been simple” or “We’re spending more time fixing things than building new ones.” Left unchecked, this wears teams down. They start losing faith in the plan, the tools, and their ability to deliver.
As leaders, this is one of the clearest signals to watch for. When delivery slows and frustration rises, it is often not the roadmap that is wrong. It is the foundation beneath it. Spotting this early is key. It comes down to asking the right questions, such as: Is our early work carrying more weight than it was ever meant to? Are we building clean enough today to stay fast tomorrow? Even better, it is about creating a culture where teams can raise these risks before they snowball.
BSSN naturally supports this kind of culture. It keeps the work focused on today’s needs while ensuring it is done with enough care that tomorrow’s team does not feel trapped. It also gives you a shared language as a team. When everyone understands the value of building just enough with clarity, you are not stuck trying to justify the time it takes to do things properly. Teams stay confident, momentum stays healthy, and your energy stays focused on delivering value rather than clawing back lost ground.
Closing Thoughts
When I think about “a good plan fiercely” in leadership, it’s less about shouting for speed and more about building trust in steady progress. It’s about helping your team act with conviction today without trapping them in decisions they’ll regret tomorrow. BSSN enables you to do exactly that. It keeps things honest, manageable, and flexible. Our role as leaders is to shape an environment where progress feels achievable, foundations are strong enough for now, and the team has the confidence to handle whatever comes next.