Angular development
Angular work reaches us in three shapes: a front-end estate several teams share, an application stuck a few major versions behind, and an AngularJS codebase that went end of life in 2022 and still runs the business.
01Capabilities
Four shapes of Angular work, and which one you are in
Angular is an opinionated application framework rather than a rendering library, and that is the whole reason to choose it. Knowing which of these four you are in changes the plan more than the architecture does.
- Estate
One component layer, many applications
unicrew rebuilt the front end of Bitergo's Business App Store, a set of warehouse management apps, on the latest version of Angular. The total number of applications is more than 15 and many of them reuse the same modules, so our developers built universal components in Storybook and integrated them into the new grid of each application (the study). At that count the expensive question is the component contract, not the screens.
- Operations
Back-office interfaces people work in all day
Dispatch boards, admin consoles and reporting surfaces of the kind that sit on top of logistics and transportation platforms. Typed reactive forms, tables that stay usable at ten thousand rows (virtual scrolling from the Angular CDK, OnPush change detection, RxJS streams that are actually torn down), and permissions enforced in the API rather than hidden in a template.
- Library
A component library other teams build against
A versioned library developed in isolation with Storybook, so a component can be reviewed before an application depends on it. Where the design allows it we build on Angular Material and pay the theming cost; where it does not, we build on the Angular CDK primitives instead of reinventing them badly. Either way it is a product with consumers and a breaking-change policy, which is what our design systems work covers.
- Migration
Getting off AngularJS, and off stale majors
AngularJS v1 reached end of life in January 2022 and a great deal of it is still in production. Getting off it is a replacement rather than an upgrade, so it is legacy modernization work, and it has to happen without a feature freeze. Stale modern Angular is a different job: the version floor first, then the state layer, then the move off zone.js toward signals.
02Case studies
Systems where our Angular is running today
Three estates in production, across logistics, food production and automotive.
See all case studies
LogisticsApp Store for warehouse managementOur client Bitergo offers a collection of business apps to optimize warehouse management, scalable from start-ups to 4PL companies. Given the business drivers, the client decided to upgrade the front-end of all their applications to the latest version of Angular.Rapid increaseOf test accounts ordered by potential customers after the site launched
FoodtechDigital Transformation in Food IndustryOur client is an innovation-oriented group of food companies based in Germany that produces and distributes a wide range of products for well-known retail businesses and food services.
AutomotiveJack Cooper: Software for automotiveA sophisticated vehicle inspection tool for one of the biggest transportation providers.
03Fit
When Angular is worth its conventions
Angular earns its place when a front-end estate is large enough that convention beats flexibility, and it is the wrong answer often enough that we would rather say so before a contract is signed than after. Three of the six rows below send you somewhere that is not an Angular project with us.
| Your situation | What we recommend |
|---|---|
| A large estate, several teams over several years, one upgrade path wanted | Use AngularRouter, forms, HTTP layer and dependency injection are decided for you, and at this size that is worth more than flexibility. |
| AngularJS v1 still in production, unsupported since January 2022 | Rebuild on AngularAngular is the destination, but code does not port, so plan a replacement route by route behind a shared shell. That is legacy modernization. |
| An Angular application several majors behind, and slow to change | Not a rewriteRaise the version floor with the CLI update schematics, replace the abandoned dependencies, then decide what else is actually blocked. That is a smaller engagement than the one people ask us to quote. |
| Mostly content, where search visibility and first paint decide the outcome | We argue againstNot a single-page application at all. Angular does render on the server with hydration, and it works, but Next.js is the better-trodden path for a content-led site. |
| A team already productive in React or Vue | Different pageDo not migrate for its own sake. That is a cost with no owner. Our React and Vue pages are the honest starting points. |
| A genuinely small interface, one or two developers, no second team coming | We argue againstAngular's machinery pays for itself across teams and across years, and neither of those applies here. Keep the framework small and spend the budget on the product. |
Scope
On an Angular engagement we own that decision and what follows from it: how the pages are rendered, where shared data ends and a screen's own state begins, and whether the component library is a real product or a folder that drifts. Keeping the version current is part of that job rather than a change request. unicrew has been building this kind of front end since 2012, with 100+ senior in-house engineers across six countries, and we hold ISO 27001:2022 and ISO 9001:2015, renewed through a multi-stage audit with Quay Audit UK. Where the honest answer is a smaller piece of work than the one you came for, you get that answer, including when the larger piece would have been ours.
Angular's reputation for being heavy usually comes from codebases that never adopted the parts that make it light. Standalone components, lazy-loaded routes and OnPush change detection are not advanced techniques, they are what we expect as the default on a current codebase. When an Angular application feels slow we look at change detection before anything else, and most of the time the fix is a few boundaries rather than a rewrite.
Andrii BurdaSenior Engineering Manager, unicrew04Delivery
What we establish before we change a line
Inherited Angular is most of what reaches us, so the first pass is diagnosis rather than a plan. Steps one and two carry the real information; sequencing after that is cheap.
- Establish the version floorWhich Angular major you are actually on, how far the dependency tree has drifted from it, and whether the code still runs on modules and decorators or has moved to standalone components and signals. That answer sets the order of everything else.You getA written version-floor note: the current major, the dependencies blocking the next one, and the upgrade order the CLI schematics can take.
- Find where change detection is really happeningSlow Angular applications are usually not slow because of Angular. They are slow because everything re-renders, or because an RxJS chain fires far more often than anyone intended. Measuring that is cheap and it beats opinions every time.You getA profile: which components re-render and why, which subscriptions are never torn down, and a shortlist ranked by cost.
- Name the owner of the component contractIn a shared estate, who may change a shared component and what breaks when they do is an organisational answer as much as a technical one. Left undefined, it produces four copies of the same component that quietly diverge.You getThe contract in writing: what counts as public API, the breaking-change policy, and where the boundary is enforced by the build rather than by goodwill.
- Migrate by route, ship continuouslyWhere a rewrite is warranted we run old and new behind the same routing shell and replace one route at a time, each surface live before the next one starts. You can stop at any point and still have a working product.You getEach route live behind the shared shell as it lands, the old one removed rather than left running beside it, with its automated coverage handed over.
05Client voices
Two clients on how the work went
After launching the site we saw a rapid increase of test accounts ordered by potential customers. Now the site provides a steady source of sales leads.
We occasionally disagreed about the code and process. Artelogic was self-critical during these exchanges and didn’t charge us for the time. In the end, the team’s quality deliverables have created value for cost. The EDI tool generates significant daily revenue and helps us solve order collection issues.
06Stack
What sits around Angular in these estates
The technologies that turn up in the same repositories, each with its own page if that is the decision you are actually making.
07Questions
What buyers ask before an Angular engagement
Answered the way we would answer them on the call. If yours is not here, it is a good first message.
Yes, and some clients start exactly there. What we will not do is supply people and leave the result unowned. An architect outside the delivery team reviews the design, and the work goes through the same QA and test automation practice as our own projects, with ISTQB-certified engineers in every sprint. Team extension is managed teams; handing over the outcome instead is web development.
No, and the distinction matters more than the shared name suggests. AngularJS is the original 1.x framework and it reached end of life in January 2022, so it gets no further security patches. Angular is a different framework with a different programming model: TypeScript first, component based, with standalone components, signals and its own CLI. Application code does not port between the two.
Upgrade, in nearly every case we have looked at. The CLI's update schematics handle a large share of the mechanical work one major at a time, and what they miss is usually concentrated in three places: the state layer, the UI kit, and build configuration nobody has touched in years. That is bounded work with a visible end. A rewrite trades it for unbounded work, and it belongs in legacy modernization.
Angular when the estate will be large, several teams will work in it over years, and you want the router, forms and dependency injection decided once rather than reassembled per project. React when it is one product with heavy client state and hiring breadth matters more than convention. At the scale most products reach, either will work, so follow the team you have and can hire.
A scoping call with the engineer who would do the work, not a salesperson. For an existing application we ask for repository access first, because half an hour in the code answers more than an hour of description. You get back a written read on the version floor, the state model, and what we would change first. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we only offer it once the first read is done. Team extension is billed monthly per engineer. The rate inside any of them follows the seniority mix the work needs, so it is quoted rather than listed.
Building an Angular front end, or getting off AngularJS?
Send the repository, or a description of where it hurts. You will get an engineer's read on the version floor, the state model, and what we would change first.