Angular gives a large team one way of doing things, and a small team a lot to carry.
Angular comes with an opinion about almost everything. Where files go, how screens talk to data, how forms are checked, how code is tested. For a team of ten that agreement is a gift, because any developer can open any part of the app and find their way.
For a team of one or two it is the opposite. You learn a large framework before you ship a single screen. The structure that protects a big project can slow a small one badly, and the cost only becomes visible when the deadline is near.
Angular is a complete framework from Google for building web applications in TypeScript. Unlike a library that only draws screens, it also includes routing, forms, data calls and testing tools in one package, all used in a set way. You get fewer decisions to make and more rules to follow, which suits big projects.
Where it earns its place.
What it is genuinely good at
- Large internal applications with dozens of screens and many developers
- Forms with long lists of rules, checked the same way everywhere
- Teams that change often, since the layout is the same in every project
- Applications that will be maintained for many years by whoever is hired next
- Code that has to read the same to a new joiner and to its author
Where the structure costs you
Angular asks you to write more before anything appears on screen. On a small project that overhead never pays itself back.
- A steep first month for developers who have not used it before
- Several files for something React would do in a few lines
- A small marketing site, where the framework outweighs the content
- An early prototype that you may throw away, and wanted quickly
The cost is real but it is front-loaded. On a long-lived project the rules save time later, and on a short one they simply cost time now.
Where we use it
- Existing Angular applications that a client already runs and needs kept alive
- Internal portals for staff, with many roles and many forms
- Large business apps where the client’s own team writes Angular
- Careful upgrades of old AngularJS apps to the current framework
The upkeep that comes with a big framework
Angular moves in regular releases, and falling behind makes each later jump harder. Leaving an app untouched for a few years is how it becomes a rewrite.
- A habit of upgrading one release at a time, not five at once
- Checking that each third-party package still supports your Angular release
- Keeping the test suite alive, since upgrades lean on it
- Planning for AngularJS code, which is old and no longer supported
How Angular sits among the other parts
This framework covers the front end only. It talks to a back end over an API, and it expects that API to be tidy and well described.
- A back end in Node.js, NestJS, Laravel or .NET, whichever your team knows
- TypeScript throughout, which Angular requires and which suits NestJS well
- A shared description of the API, so the two sides cannot drift apart
- A separate public site, if search matters, since Angular alone is weak there
When this is the right choice.
- You are building a large internal application with many screens and roles
- Your own developers already write Angular and TypeScript
- Many developers will work in one codebase and need strong common rules
- The application will be maintained for years, not months
- You already have an Angular app that works and needs steady care
When it is not.
- A small project with one or two developers, where React or plain pages are lighter
- A public site that must be found through search, where server-drawn pages fit better
- A quick prototype that may be abandoned, since the setup cost is wasted
- A team with no TypeScript experience and no time to learn it
- A rewrite of a working app in another framework only because it is fashionable
Questions we are asked about it.
Is Angular the same as AngularJS?
No. AngularJS is the original framework, which is old and no longer supported. The current framework is a complete rewrite with a different design, so moving from one to the other is a rebuild of the screens rather than an upgrade.
Which is better, Angular or React?
Neither is better in general. Angular gives structure to big teams, and React gives freedom to small ones. The right choice depends on your team’s size, habits and how long the app must live.
Can you maintain an Angular app someone else built?
Yes, and this is a large part of our Angular work. We start by reading the code, running the tests and listing what is out of date. Then we upgrade in small steps so the app keeps working throughout.
Does Angular suit a public website?
Not on its own. Its default is to draw pages in the browser, which is weak for search. It can draw pages on the server, but a simpler tool usually suits a public site better.
How hard is it to hire Angular developers?
It is manageable, particularly in large companies where Angular is common. Developers who know it tend to be comfortable with TypeScript and with working under shared rules. Those habits are what a large project needs.
Should we start a new project in Angular?
Only if the project is large, long-lived and will have several developers. Otherwise a lighter tool will get you to a working product sooner. We will say so plainly if that is where you are.
Services that use it.
What it sits with.
Not sure Angular is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
What happens after you share your requirements
- A senior engineer reads your answers. Nobody phones first.
- Within one business day you get a written note: what we understood, what we would start with, and the questions we still have.
- If it fits, a proposal follows with the order of work, what we need from you and what you receive at each step.
- No call is booked and nothing is paid until you have read the note. Your details stay with us.
Start with your requirements
Seven short steps that tell us what you need. A senior engineer reads them before anyone gets in touch.
Share your requirements