Application development
Angular front-end development
I build fast, accessible and tested Angular interfaces on a readable codebase. You get measured user journeys, not just screens that render.
What it covers
An expensive front end is usually the result of invisible decisions: subscriptions never released, excessive change detection, state duplicated in several places. I structure applications around standalone components, signals for local state and a single data service per functional domain.
Performance is treated as an acceptance criterion. We measure loading and interaction indicators on critical journeys, with an explicit budget and tracking inside the integration pipeline. Accessibility is verified on structuring components: keyboard navigation, contrast and labels.
Testing and industrialisation
Unit tests cover component logic, end-to-end tests cover essential business journeys. Selectors are explicit and test data is isolated, so the suite stays stable without daily maintenance.
- Standalone components with strict typing end to end.
- State management kept minimal, signals by default.
- Server-side rendering for pages exposed to search engines.
- End-to-end tests limited to critical journeys.
- Performance budgets enforced in the integration pipeline.
Problems addressed
The application slows down as screens and loaded data accumulate. The same state is stored in several places and drifts out of sync. End-to-end tests fail randomly and end up disabled. The upgrade to a recent Angular version is postponed every year. Accessibility issues surface too late, during acceptance testing.
Expected benefits
Responsive interfaces on modest hardware profiles. Predictable application state that is easy to debug. Journeys automatically verified before every release. A codebase a new front-end developer can work in. Performance indicators tracked over time. Better natural discoverability for public pages.
Method and steps
- 1
Journey framing
Identifying critical screens, required state and acceptable performance budgets together with business and design teams.
- 2
Front-end foundation
Project structure, styling conventions, generated API client and testing tooling.
- 3
Screen development
Delivery in functional increments, with visual review, accessibility checks and end-to-end tests on key journeys.
- 4
Optimisation and handover
Analysis of real measurements, fixes on hot spots, convention documentation and a handover session with the team.
Deliverables
Angular application structured by functional domain.
Typed API client generated from the back-end specification.
End-to-end test suite covering critical journeys.
Performance report with before and after measurements.
Front-end convention guide and accessibility checklist.
Handover session with the front-end developers.
Technologies used
- TypeScript
- Spring Boot
- Angular
- RxJS
- NgRx
- OpenTelemetry
- Playwright
Frequently asked questions
Do you handle Angular version migrations?
Yes. Migration happens screen by screen so the application stays shippable. Breaking changes are handled in batches, with non-regression tests running at each step.
Is server-side rendering mandatory?
No. Server-side rendering brings real value to public pages exposed to search engines and to slow connections. For an authenticated internal application it adds complexity with no measurable benefit.
How do you keep consistency with the back end?
The API client is generated from the service OpenAPI specification, which removes contract drift. Server errors are translated into understandable messages in the interface.
Related case studies
Angular front-end migration and performance overhaul
Five versions behind, one hundred and eighty screens, migrated in shippable batches
Demonstration sample - not a real client reference.
Discuss my interface
Tell me about your priority screens and the issues you observe. I will propose an incremental plan with measurable performance targets.