File Structure Makes Sense Now

Why structure exists at all

Imagine a group project where everyone dumps their files into one shared folder. No organization, no naming convention, nothing. One file called stuff.js, another called finalfinal.js, something called dontusethis.tsx, and nobody remembers what any of it does or who wrote it.

Now imagine that project has 200 files.

That's what codebases looked like before people agreed on structure. And the problem wasn't just that it looked messy — it's that things broke and nobody could find where to fix them. You'd change one file and something totally unrelated would stop working, with no way to trace why.

File structure exists to solve that. It's an agreement. A convention. A way of saying — if you're looking for a page, it's in this folder. If you're looking for something reusable, it's in that folder. If you're looking for configuration, it's over there.

Once everyone agrees — including you, your future self, and Claude Code — the whole project becomes navigable.

The real question this module is answering: when you open a codebase and see a list of folders and files, how do you read it like a map instead of staring at it like a foreign language?

Why you already know this (even if you don't feel like you do)

When you first moved from Vite or Express to Next.js, you felt the difference immediately. Next.js handed you a map. Vite and Express handed you a blank page and said good luck.

That's not a textbook lesson. That's a lived one. Opinionated frameworks give you a starting point to understand where things go and why. Unopinionated ones leave you guessing.