The worst feeling as a developer is opening an old project and spending 20 minutes looking for one file. "Is the Login Button in components/buttons or views/auth/components?" If you organize your folders by File Type (putting all Models together, all Views together), you are making your life harder as the project grows. The Fix: Feature-First Architecture. Instead of grouping by what the file IS, group by what the file DOES. ❌ Type-Based (Hard to Scale): /components -- LoginButton.tsx -- LoanCard.tsx /screens -- LoginScreen.tsx -- LoanScreen.tsx /utils -- authHelpers.ts Problem: To fix a bug in "Loans", you have to jump between 3 different folders. ✅ Feature-Based (Scalable): /features -- /auth ---- LoginScreen.tsx ---- LoginButton.tsx ---- authHelpers.ts -- /loans ---- LoanScreen.tsx ---- LoanCard.tsx Benefit: Everything related to "Auth" is in one place. This works for React Native, Flutter, and even Django apps. Files that change together should stay together. How do you organize your projects? Feature-first or Type-first? I'm Nehemiah Yusuf. I write about scalable software development for mobile and web. Follow along for more insights. #SoftwareArchitecture #CodingBestPractices #React #ReactNative #Flutter #Django #FullStackDeveloper #CleanCode #ProjectStructure
This is a life long debate. Pros and cons are available in both sides. The important think is to stick with one and make sure the entire app follow the same architecture.
It depends on the project type. For small to medium projects, a type-based structure works well. However, for projects expected to scale, I prefer a feature-based architecture. If I have a design system, I can also follow Atomic Design principles and implement an atomic architecture. There isn’t a single “best” architecture, it depends on the project, the team’s standards, or sometimes just personal preference.
Organising a large-scale project is less about choosing a single pattern and more about deliberately combining patterns, with each trade-off justified by architectural pressures such as team size, rate of change, domain complexity, performance, and deployment model. While this approach can be very effective for small-scale projects, it tends to break down as the need for shared and reusable code increases, causing the project structure to become difficult to maintain at scale. A wrong structural move late in the architectural plan acts like a slow poison; it doesn’t break things immediately, but it steadily drains the codebase’s health over time.
⚠️ Feature-based project structure isn’t a silver bullet Organizing code by feature (instead of by type) has benefits, but also downsides: • Risk of duplicated logic across features • Harder to enforce consistent architecture • Cross-cutting concerns (security, logging) get scattered • Slower onboarding for new developers • Overkill for small or CRUD-heavy projects
If you spend 20 minutes searching for one file, you need more IDE skills.
By using features, you'll run into the problem of shared code that modules have. When you separate by type, you can better atomize and reuse code in larger and more complex projects.
Ur approach is nice but in the end, using both approached interchangeably or at the same time might be best
Hybrid is also an option - Feature for the first folder level, type for the 2nd.
Do you know that you just invented approach that has been used for decades and has just as many drawbacks as splitting by type?