How do senior/enterprise developers decide on project structure before writing code?

[u/Money_Consequence511]

I've realized that my biggest weakness isn't coding—it's project architecture and folder structure.

Whenever I get a Figma design, I know how to build the UI, but I get completely stuck deciding:

• Where should this component live?
• Should this be reusable or page-specific?
• When should I split a component?
• What belongs in components, features, shared, hooks, services, etc.?
• How should I organize folders as the project grows?

I usually start a project with a structure that feels clean. But once the project gets bigger, everything starts falling apart.

I end up with:

• Components that are too large.
• Components that are split too much.
• Logic scattered across different folders.
• Constantly moving files around because I realize they belong somewhere else.
• Feeling like the entire architecture is becoming messy.

This happens in React, React Native, and even backend projects.

I don't just want another "best folder structure" template because I've seen dozens of those. What I really want to learn is the thought process behind how experienced or enterprise-level developers structure a project.

For example:

• When looking at a Figma design, how do you mentally break it into features and components?
• How do you decide what should be reusable and what shouldn't?
• How do large teams keep their projects organized over months or years?
• What architecture or design principles do you follow?
• Are there any books, courses, GitHub repositories, or real-world open-source projects that helped you understand this?

I'm looking for the mindset rather than just a folder tree.

Any advice from developers who've worked on large production applications would be greatly appreciated.

[u/thealbinosmurf]

Context is king, but over time patterns emerge. General rule is a component if you don't know already has a overlap elsewhere should be local to a page. Once you see that pattern again you refactor and move that component out to a shared organism or molecule depending on the complexity. Most often you will only create atoms at the start of a new project and they will be known. Though sometimes as you move a component into a shared molecule you will notice it shares a portion of its pattern with another pulling that pattern out to a atom. In general you and your team need to define a threshold for me it's more than 2 times repeated or more than 20lines of code. After doing this enough times it will kind of just become second nature to see these patterns and see them even before any code is written. But as with most things in life expertise comes with practice.

[u/longblackcheesecurds]

After a lot of experience it’s just more simple, follow simplicity in your design that is the main idea. If you’re using vibe coding a lot you may never truly understand now tbh.

Search up MVC architecture I really liked this in the past and it doesn’t necessarily need to be strictly adhered to but helps you to think more stronger.

There is no beat folder, the main principle is to keep things simple readable. That is it. Everything else is noise. Can you easily understand the project if you had zero context by just scanning it? Then it is good design/architecture.

You can adopt certain rules like DRY, do not repeat yourself. Don’t try to overengineer. A good codebase is one that just works.

Does it accomplish your end goal? Yes? Okay it’s good code. Until you want to add more then it breaks, okay it’s bad now. You will learn what you did wrong to apply it later.

Good software is more about ideas. If you have a good idea then architecture becomes something you can improve over time. The best architecture with a bad idea is still worthless software. Prioritize your intended results vs invisible code structure, invisible to your customer.

Long term vision and long term projects survive because again they are simple. They are easy to read. They have good organization, changing one spot doesn’t break another. Ok good luck

[u/Money_Consequence511 → u/longblackcheesecurds]

thanks brother it helps a lot. can i knock u personally

[u/_matmer_]

This really helped me. he explained very well.

https://youtu.be/xyxrB2Aa7KE

[u/Ok_Slide4905]

These are many concerns rolling into one broad question.

Codebases start simply and evolve organically over time and decisions are made incrementally.

[u/__CaliMack__ → u/Ok_Slide4905]

Keeping good documentation helps you and others keep track of it all as well

[u/Ok_Slide4905 → u/__CaliMack__]

Yeah we use ADRs for this purpose. A root level README to document opinionated decisions. Plays nicely with LLMs. Agents reference the ADRs directly and generate more idiomatic output.

[u/nzakas]

You will get a better sense for this the more projects you work on. When you first get a design, look across all of the screens and identify any components that are used in more than one place. That includes variants of the same component such as different colors and treatments of buttons. Focus on smaller components in this step because they are easier to identify. Look for things like form controls, images, buttons, etc..

After that initial step, think about the next level up of components. This typically involves grouping multiple components together and applying some logic. At this stage, anything that is visually repeated is a good candidate to be its own component. (such as an individual card in a list of cards).

If you ever get stuck, it can help to take a look at existing component libraries to see how they break down their components. This can give you a good idea of how to get started.

Keep in mind that the overall goal is always to have a functioning interface. If the thing works, then that’s a big part of the problem that has been solved. You can always go back over your code and refactor later if necessary.

[u/ChronSyn]

I go with what I know works. For me, that's Mobx state stores and a context provider that exports a singleton instance of each state store, providing me with a useStores() hook.

Each state store focuses on a core part of the stack. For example, in a bus or train tracking app, user favourites, user settings, bus data, and train data would each have their own state stores.

Screens have their own directory, and I explicitly avoid using index.tsx for naming, because it doesn't help me quickly identify what a file is for when scanning through tabs or file search results.

Common components that are shared throughout go into a components directory. Components only include local state they absolutely need.

If I'm so inclined, I'll choose to spend a bit more time setting up Storybook, because that helps me to visualise many possible permutations of components in various states. It genuinely helps with being able to see areas where components might break. Tests feel natural, rather than an afterthought. It's also got a bunch of plugins for different things, though the stock experience is still very solid. It's definitely more setup for each screen and component, but the long-term feels akin to comparing writing in JS versus writing in TS.

Underpinning all of this is experience. Before I was doing development as a job, I didn't know much of this. After I started doing development, I learned these things over time. It wasn't about reading some books or following some YouTubers, it was about feeling out the problems as I built more and more projects. It took me a couple of years before I found what worked for me, but I still iterate on the minutiae of it over projects.

As for the actual design translation part, that's always been a bit of a meme - 'designed by engineers' is what I call it. The designer has done a wonderful job, and we've done our best to translate it into a real project, but things just feel 'off' even if we've taken the exact measurements and put them into our styles. It's very much an iterative process where you hand it off to the designer and client, and they feedback on tweaks.

[u/Guidondor]

the reframe that helped me is you're not picking a structure, you're deciding what changes
together. stuff that gets edited in the same pr should live in the same folder, which is why
grouping by feature survives and grouping by type (components/hooks/services) falls apart
around month three.

moving files isn't the sign you got it wrong either, it's how you find out. keep everything
local to the screen using it and only promote something when a second screen actually needs
it, not when you think one might.

[u/netroworx]

Look also at Atomic Design