For a MERN app that is expected to grow, I’d recommend moving from a pure layer-based structure (controllers, routes, models, etc.) to a feature-based structure with shared infrastructure.

That usually scales better because React encourages breaking the UI into reusable pieces and reusing logic through custom hooks, while Express is designed around routers and middleware that can be grouped by concern. ([React]1)

A good rule is:

• Group business code by feature: auth, users, products, dashboard
• Keep cross-cutting code shared: middleware, utils, config, lib, types, validators

So instead of this:

backend/
  controllers/
  models/
  routes/

prefer something like this:

backend/
  src/
    app.js
    server.js
    config/
    middleware/
    lib/
    utils/
    modules/
      auth/
        auth.controller.js
        auth.service.js
        auth.repository.js
        auth.routes.js
        auth.validation.js
        auth.model.js
      users/
        user.controller.js
        user.service.js
        user.repository.js
        user.routes.js
        user.validation.js
        user.model.js
      dashboard/
        dashboard.controller.js
        dashboard.service.js
        dashboard.routes.js

And on the frontend:

frontend/
  src/
    app/
      router.jsx
      providers.jsx
      store.js
    components/
      ui/
      layout/
    features/
      auth/
        api.js
        hooks.js
        components/
        pages/
        utils.js
      dashboard/
        api.js
        hooks.js
        components/
        pages/
      products/
        api.js
        hooks.js
        components/
        pages/
    services/
      http.js
    lib/
    utils/
    hooks/
    styles/

Why this works better:

1. Feature code stays together
   When auth grows, you don’t have to jump between 6 top-level folders just to change one feature.

2. Shared logic has a clear home

   • validation → featureName.validation.js if feature-specific, or shared/validators if reused widely
   • utilities → utils/ only for true generic helpers
   • DB/API wrappers → lib/ or services/

3. Scaling is easier
   New features become new folders instead of making the whole codebase flatter and harder to navigate.

For the backend, I’d also separate responsibilities clearly:

• routes → define endpoints
• controller → handle request/response
• service → business logic
• repository/data-access → database queries
• model/schema → Mongoose schema

That keeps controllers thin and makes your code easier to test and maintain. Express supports composing logic cleanly with router-level and application-level middleware, so this style fits the framework well. ([Express.js]2)

For the frontend, keep these guidelines:

• put reusable UI in components/ui
• put feature-specific UI inside that feature
• put reusable stateful logic in custom hooks
• keep API calls near the feature, unless you have a truly shared HTTP client

React’s docs explicitly encourage composing apps from components and reusing logic through custom hooks, which maps well to a feature-first structure. React also emphasizes being intentional about state organization as apps grow. ([React]3)

A few practical best practices:

• use a src/ folder in both frontend and backend
• centralize environment/config loading in config/
• keep error handling and auth in middleware
• avoid dumping everything into utils/
• create one folder per major domain/feature
• add tests beside features or in feature-level __tests__ folders
• use consistent naming conventions across backend and frontend

If the app becomes much larger, you can evolve this into a modular monolith first before thinking about microservices. In most MERN apps, a modular monolith is the sweet spot for maintainability without unnecessary complexity.

So the short answer is:

For scalability and maintainability in MERN, prefer a feature-based structure with a small set of shared folders for infrastructure. Keep backend code split into route/controller/service/repository layers inside each feature, and organize frontend code by feature with shared UI and reusable hooks extracted only when needed.

That gives you the best balance of clarity, scaling, and real-world maintainability.