FrontendArchitecture

The applications I get called into tend to share a symptom: the first version worked, and the second one is fighting the architecture. Data fetching is scattered across components, so nothing can be reasoned about or cached. Rendering strategy was never decided, so everything is client-rendered including content that should have been static. Types stop at the API boundary, so a backend change becomes a runtime error in production rather than a build failure.

The cost shows up as a slow feedback loop. Small changes require large amounts of careful testing because nobody is confident about what else they touch, and that uncertainty is what actually slows a team down — not typing speed.

Rendering strategy is a decision I make explicitly and early, per route rather than per application. Content that can be static should be static. Data that is per-user belongs on the server where it can be fetched without a waterfall. Only genuinely interactive state belongs in the client. Getting this right at the routing layer removes entire categories of performance problem before any optimisation work is needed, and it is nearly free at the start and expensive to retrofit.

Data flow gets a defined shape: typed models, fetching that lives in one layer rather than scattered through components, and components that receive data as inputs. This is what makes caching, deduplication and testing possible later, and it is the single structural decision that most reliably determines whether the application is pleasant to work in at version three.

Performance statements go into feature tickets rather than into a later optimisation phase. A ticket adding a view says what it may fetch on load and what it must receive from its parent. A ticket adding an image says the space is reserved. These are one-line additions at the point of writing, and they are what stops Core Web Vitals from becoming a score nobody owns.

For a new application, the first week produces a working routed skeleton with the data layer and rendering strategy settled and one real feature built through it end to end. That gives everyone something concrete to react to before the expensive decisions calcify, and it is far more useful than a document describing what will be built.

For an existing application, it starts with an assessment: what is slow, what is fragile, what is expensive to change, and what each of those is worth fixing. Work then proceeds in increments that ship, rather than a rewrite. Rewrites are occasionally right and usually a way of converting a known problem into an unknown one.

Angular or React for a new web application?

Angular when the application is large, form and data heavy, built by a team that benefits from strong conventions — admin consoles, case management, portals. React with Next.js when rendering strategy and content are central, or the surface is public facing and performance sensitive. I will recommend based on your team and the product, not a preference.

Can you work with our existing backend and API?

Yes. Most of my work integrates with backends built by other teams, including REST APIs on Sails.js, Node and .NET. I do not require the backend to change, though I will flag places where a small API change removes a large amount of frontend complexity.

Do you handle the design as well?

I implement designs to a pixel-accurate standard and I can design interfaces where none exist, working from the product requirements. If you have a designer, I work from their files and handle the engineering decisions that designs do not specify — states, edge cases, responsive behaviour, accessibility.

How do you handle accessibility?

It is built in, not audited afterwards. Semantic markup, keyboard operability, visible focus, and WCAG 2.1 AA as the working standard. Retrofitting accessibility is substantially more expensive than building it correctly, and on government and pension work it is generally a requirement rather than an aspiration.

What about testing?

Unit tests for logic that has a right answer, and end-to-end tests with Playwright for the flows that would cost real money if they broke. I do not chase coverage percentages; I aim for the property that a green build means the important paths still work.

• Performance is a product requirement — Why load behaviour belongs in the feature spec rather than a later optimisation phase.