Let's talk

Frontend

Hire Frontend Developers

Interfaces that hold up under real use.

Operational software is not a marketing site. The screens people live in all day are dense with tables, filters, calendars and forms, and they are used by someone who already knows the domain better than the designer did. Speed matters more than polish, and keyboard behaviour matters more than animation.

The frontend work here is that kind: hundreds of screens, real data volumes, and users who notice a hundred milliseconds because they perform the same action four hundred times a day.

That user changes what counts as good. Someone who books forty rentals a day does not want a wizard; they want every field reachable from the keyboard, the same field in the same place on every screen, and the ability to correct a mistake without starting again. Guidance that helps a first-time user is friction for the person who has done this since 2019, and operational software is mostly built for the second one.

State is where these applications actually get difficult. A screen showing live data, with optimistic updates, a filter set the user expects to survive a refresh, and two people editing adjacent records — that is a set of decisions about caching, invalidation and conflict, and the library chosen to express them matters far less than whether anybody made them deliberately.

Accessibility belongs in the same conversation rather than in a later audit. Keyboard focus that moves sensibly, form errors that are announced rather than only coloured, and controls that are real controls are the same things that make a dense interface fast for everyone. Retrofitting them costs several times what building them in would have.

The stacks in this group are React, Next.js, Angular, Vue and the HTML, CSS and JavaScript underneath all of them. We treat that last layer as the one that matters most, because a developer who understands the platform can learn a framework in a fortnight and a developer who only knows the framework is stuck when it behaves unexpectedly.

What to look for when hiring

The useful signal is how someone handles a table with fifty thousand rows and eight filters, not whether they can name this year's state library. Ask what they did about it — virtualisation, server-side paging, a different query — and why they rejected the other two. Then ask how the same screen behaves for a keyboard-only user, because the answer tells you whether accessibility is something they build or something they are told about later.

Talk about a team