Angular Project Structure - How I’d Organize Small, Medium, and Large Apps

When Angular projects are small, almost any structure feels fine.

When they grow, bad structure becomes expensive fast - harder to navigate, harder to test, harder to hand off.

Angular’s style guide recommends organizing by feature areas and keeping one concept per file.
Modern Angular also leans toward standalone components by default.

This is how I think about structuring Angular apps based on size.

---

Small Projects

For small apps, keep things simple and avoid over-engineering.

You don’t need core, shared, and complex architecture for a small admin panel or learning project.

Example structure:

src/
  app/
    home/
      home.component.ts
      home.component.html
      home.component.scss
    about/
      about.component.ts
      about.component.html
      about.component.scss
    app.component.ts
    app.routes.ts
  assets/
  styles.scss

The goal is speed and clarity.

If your app has only a few screens, adding layers just makes it harder to understand.

---

Medium Projects

As the app grows, structure starts to matter.

This is where core, shared, and features become useful.

Example:

src/
  app/
    core/
      services/
      guards/
      interceptors/
    shared/
      components/
      pipes/
      directives/
    features/
      auth/
        login/
        register/
      dashboard/
        widgets/
        pages/
      settings/
        pages/
    app.routes.ts
    app.component.ts
  assets/
  environments/
  styles.scss

Key idea:

• Feature code lives together
• Shared code is reusable
• Core handles app-wide logic

This matches Angular’s recommendation to organize by feature, not file type.

---

Large Projects

At scale, folders are not enough - you need clear boundaries.

The biggest risk becomes coupling, not file organization.

Example:

src/
  app/
    core/
      auth/
      api/
      layout/
      guards/
      interceptors/
    shared/
      ui/
      utils/
      pipes/
    features/
      billing/
        components/
        pages/
        services/
        models/
      users/
        components/
        pages/
        services/
        models/
      reporting/
        components/
        pages/
        services/
        models/
    app.routes.ts
    app.config.ts

In larger apps:

• Each feature is self-contained
• Features own their components, services, and models
• Boundaries matter more than folder depth

---

My Rules for Structure

• Small app - keep it flat and readable
• Medium app - introduce core, shared, features
• Large app - organize by domain and enforce boundaries
• One concept per file whenever possible

Avoid creating folders just because they “look right”.

Folders should solve real problems:

• duplication
• confusion
• scaling issues

Otherwise they’re just decoration.

---

What I Care About Most

A good structure helps answer three questions quickly:

• Where does this code belong?
• What is reusable?
• What should stay isolated?

If those answers are obvious, the structure works.

If simple changes become harder, it’s too complex.

---

Angular gives you enough structure to stay organized
without locking you into one rigid pattern.

The goal is balance - not over-engineering, not chaos.