Manuj Sankrit Posted on May 31 Frontend Architecture: Where Does This File Go? # webdev # frontend # architecture The PR That Started A Twenty-Comment War The code was fine. Logic was correct. TypeScript was happy. Tests passed. And then the review comment landed: "Where does this actually belong?" That was it. No suggested fix, no alternative. Just that one question hanging in the thread like a grenade with the pin pulled. Within the hour, five developers were in the comments. Someone said it was a service. Someone else said it was clearly a utility. A third person floated the idea of a new folder entirely. The original author — who had been quietly watching this unfold — just wanted to transform an API response into a format the UI could consume. Six lines of code. Twenty comments of architectural debate. The PR merged eventually. The file went into utils/ because everyone got tired. Six months later that utils/ folder had 61 files, zero organization, and a reputation among the team as the place where code goes to retire. I have watched this happen more than once. The problem was never the code. It was that nobody agreed — explicitly, structurally — on where things belong . That is what this post is about. The Real Problem Is Not The Framework When frontend projects start, the structure feels obvious. You have components. Maybe a hooks folder. A utils folder. An api folder. Everything fits. Then the project grows. Features pile up. The team doubles. And somewhere around month four, a new developer joins and spends forty minutes on day three not writing code — just figuring out where to put a file. They ask a senior. The senior pauses genuinely, thinks, and says: "Honestly just put it in utils for now." That "for now" is permanent. The framework is not the problem. React, Next.js, Vue — none of them tell you how to structure your business logic. They tell you how to render. The organizational mess is entirely yours to solve. Atomic Design — Why It Works And Then St
LIVE