Table of Contents
We’ve all seen it in the movies- inspiration strikes a tech genius, they pull an all nighter building the next great app, fame and fortune follow. While there’s nothing wrong with a good story, if you’re an MBA looking to learn about digital products there’s a few more things worth unpacking. Even the best executed, most wildly successful startups had to put in the work to create a digital infrastructure that could deliver on that wild success.
In practice, maintaining such an infrastructure is like a lot of things in both business and engineering; relatively well understood in general, but in practice requiring diligence, adaptation, and, above all, disciplined experimentation. Every company, every product, and every team will realize their own unique set of outcomes from the decisions they make about their digital infrastructure. This 100% includes your AI colleagues- while they’re capable of reading through the whole code base very quickly and making some inferences, good housekeeping will go a long way towards keeping you, your team, and your AI’s on the ‘same page’.
There are five major components to maintaining to a high-functioning digital infrastructure (code base, etc.):
- Separation of Concerns
Your code is your kitchen. And let’s say it’s a commercial kitchen, with lots of new items coming in and out. How do you organize things such that both as your team and your equipment changes, you can readily find what you need? - Modularity
If everything’s just thrown in a drawer, it might be in the right place, but what if you need to move something similar (but not the same) into that same spot? Will things get mixed up and messy? Or is everything neatly sectioned-off and self-contained? - Self-Documenting Code
You’ve got a big freezer with lots of ziploc bags full of stuff. You need chicken stock in a hurry- can you find it? Or do you have to go look up someone’s notes? The idea with self-documenting code is that all the code, infrastructure, etc. has notes about itself in place (en situ). - Simplicity
Day to say, let alone week to week, you don’t know exactly what you’ll be making. While you might have some chicken stock and frozen carrots sitting around is it really a good idea to make chicken soup? Or should you just keep the ingredients as they are (simple) in recognition of that fact that you don’t know what you may need next (and it very well may not be chicken soup). - Observability
You smell a plate before it goes out and something about it is rotten! Can you figure out what the bad ingredient was in a hurry so you can get rid of it while still keeping the kitchen producing? Observability is the idea that you don’t just want monitoring and logs- you want to be able to intervene in certain ways to fix things when they break or underperform, and that you should organize your code infrastructure for that.
Separation of Concerns
In MVC terms: keep views as views, controllers as controllers, and models as models.
Your codebase is your kitchen. In a commercial kitchen, ingredients come and go, people rotate in and out, and the menu evolves. If you don’t organize your space, everything slows down. People waste time hunting for tools. New staff get confused. Your AI coding assistant—no matter how powerful—has to guess what you meant.
A well-organized digital “kitchen” puts each thing where someone would naturally expect it:
Views are supported by purpose-specific HTML and CSS files (vs. just one big file).
Controllers are decomposed into area-specific .js files. For example, with the HinH code, you might have a JS file that deals with filtering, searching, and the UI interactions on the front page. You might have another that deals with authentication and another that deals with model interactions (with, say, Firebase).
Models have tables or collections (noSQL) that parallel the real-life entities they represent.
If you treat the codebase as a shared workspace rather than a personal project, other humans—and AIs—will be able to help you without stepping on landmines.
Modularity
Even if things are technically “in the right place,” stuffing unrelated tools together creates confusion. Modularity ensures that each component—a function, a file, a Firestore collection—has a clear boundary.
In MVC terms:
Small JS files for specific tasks that don’t overlap
Functions that only do one job
Firestore subcollections only where they reflect real domain relationships
Good modularity means you can add something new without breaking what already works—and your LLM can generate patches with confidence.
Self-Documenting Code
If your freezer is full of unlabeled Ziploc bags, you may technically have everything you need—but you can’t work quickly. Self-documenting code means the intention is visible without needing a separate memo:
Clear variable and function names with comments explaining their role.
Code grouped where one would expect it (e.g., controller code near the event listeners it supports), or some other consistent convention.
Firestore fields named according to the real-world concepts they represent.
Minimal reliance on comments because the structure speaks for itself
Setting intention is more important than following an arbitrary checklist. The LLM will happily generate details—but only if it understands what those details are supposed to accomplish. That clarity comes from you.
Simplicity
Just because you could combine your carrots, noodles, and stock into soup doesn’t mean you should—especially when you don’t yet know tomorrow’s menu.
Simplicity means avoiding premature abstraction:
Basic, readable JavaScript over clever tricks
Minimal layers between your UI and your Firebase calls
Data models that match today’s requirements, not hypothetical future ones
Simple systems are more adaptable—for humans and machines.
Observability
Monitoring tells you that something broke; observability helps you understand why.
In MVC + Firebase terms, that means:
Console statements and logs that tell a clear story
Controller code that reveals which step failed
Firestore rules that fail loudly and descriptively
Clear mapping between user actions, controller functions, and database writes
You don’t just want to detect problems—you want to intervene intelligently, fix root causes quickly, and keep the “kitchen” running smoothly.
In Summary
These five patterns—Separation of Concerns, Modularity, Self-Documenting Code, Simplicity, and Observability—aren’t engineering trivia. They’re the structural foundation that lets mixed teams of humans and AI build, test, and iterate on digital products quickly and safely.
When your designs flow cleanly into your data model, your data model flows cleanly into Firebase, and your controllers and views remain tidy and predictable, you get a system that welcomes change rather than fighting it.
Good kitchens make good meals.
Good codebases make good products.
And in both cases, staying organized isn’t extra—it is the work.
