Atmora Tech

Engineering

Built for the ten-year
maintenance window

Angular gets chosen when a system will outlive the team that wrote it: banking back offices, claims engines, dispatch consoles. We work in signals, standalone components and strict templates, and we treat the framework's opinions as an asset rather than a tax.

Overview

Angular for systems that must still be maintainable after four rounds of staff turnover.

Angular's reputation for ceremony is mostly earned by code written against 2018 patterns. Standalone components removed NgModules, signals removed most of the RxJS that people were using badly, and the built-in control flow removed the structural directive boilerplate. Modern Angular is a smaller language than its critics remember.

We build with strict template type checking enabled and OnPush change detection everywhere, because the alternative is a detection cycle nobody can reason about once a screen holds two thousand rows. Signals carry component and derived state. RxJS stays where it belongs, on streams that are genuinely asynchronous and need cancelling.

Most of our Angular work sits behind authentication in regulated environments: role-driven route guards, audit trails on every mutation, and Nx workspaces where four product teams share libraries without blocking each other. Quarterly release trains, not continuous deployment, are frequently the constraint we design the branching model around.

11,400 rows
Rendered in the Aldridge Risk exposure grid with no dropped frames on scroll
62%
Fall in change detection time after the move to OnPush and signals
18 minutes
Full CI run for four teams in one Nx workspace, down from 71

Capabilities

What this covers

Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.

  • Signals and change detection

    Component state moved onto signals with computed derivations, OnPush applied consistently, and zoneless configuration where the dependency tree allows it, so a keystroke stops re-checking the whole page.

  • Nx workspace structure

    Libraries split by domain with enforced module boundaries, affected-only CI so a change to one product does not rebuild six, and a shared release process that four teams can use without coordination meetings.

  • Data grids and complex forms

    Virtualised tables holding tens of thousands of rows, typed reactive forms with cross-field validation, and dirty-state guards that survive tab switching in the middle of a long claims workflow.

  • Angular Material and theming

    Material 3 tokens mapped to your brand, component overrides kept in one theming layer rather than scattered across features, and dark mode plus high-contrast variants verified against real screens.

  • Legacy and version upgrades

    AngularJS strangler migrations, and version-by-version upgrades of Angular 8 through 20 with schematics, so you land on a supported release without an eighteen-month feature freeze in the middle.

  • Access control and auditing

    Route and component guards driven by claims from Keycloak or Entra ID, per-field permission masking, and client-side audit events correlated with server records for regulated change history.

Deliverables

What you get

  • Angular 20 application on standalone components with strict template checking enabled
  • Nx workspace with enforced domain boundaries and affected-only CI configuration
  • Shared component library published internally with Storybook and theming documentation
  • Jest unit suites and Playwright coverage of regulated workflows and permission rules
  • Upgrade runbook mapping each Angular version step, breaking change and schematic applied
  • Performance report covering change detection cost, bundle budgets and grid render timings

Stack

What we build it with

  • Angular 20
  • TypeScript
  • RxJS
  • NgRx SignalStore
  • Nx
  • Angular Material
  • AG Grid
  • Jest
  • Playwright
  • Storybook
  • Keycloak
  • ESLint

Process

How the engagement runs

Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.

  1. Assess version and patterns

    We record which Angular version you run, how much NgModule and untyped form code remains, and where change detection is costing frames under real data volumes.

  2. Set the target architecture

    Standalone components, signal-based state and Nx boundaries agreed as a written target, with a per-quarter sequence that never blocks feature delivery for longer than a sprint.

  3. Migrate and build in parallel

    Schematics run against one domain at a time while feature work continues elsewhere, keeping the application deployable at the end of every single sprint.

  4. Verify against regulated flows

    Playwright coverage of permission rules, audit trails and approval chains, run on every pull request because these are the paths auditors will actually sample.

  5. Train and hand over

    Workshops on signals, OnPush and Nx boundaries for your engineers, followed by a period where they lead the work and we review the pull requests.

When this is the wrong engagement

For a small application built by two engineers who have never used it, Angular is structure without payoff, since its advantages appear at team sizes and lifespans where enforced consistency beats flexibility.

FAQ

Questions we get asked

Should we move to signals now or wait?

Move new code to signals immediately and convert existing components when you are already editing them. A dedicated conversion project rarely earns its budget. The exception is a screen with known change detection problems, where the rework pays for itself inside a quarter.

We are on Angular 12. How bad is the upgrade?

Predictable rather than pleasant. Each version step has official schematics, and the real cost is third-party libraries that stopped at Angular 14. We audit those first, because one abandoned grid component decides more of the timeline than the framework itself does.

Do you use NgRx?

Only where the state genuinely justifies it, which in practice means multi-user collaboration, complex undo or heavy cross-view coordination. For most applications, signal stores plus a typed HTTP layer are less code and easier for a new joiner to follow six months later.

Can you work within our release train?

Yes. We plan branching and feature flags around fixed release windows, including code freeze periods and regression cycles. Trunk-based development with flags is our preference where governance allows, but we will run long-lived release branches properly if that is the mandate.

Start a project

Tell us what is
breaking.

We reply within one working day, and the first call is with an engineer who would actually work on it — not an account manager. If we are not the right studio for the problem, we will say so on that call.

Start a project