Frontend development

An interface when the theme is the wrong tool

Many of the screens we ship are Drupal themes, because the content and the permission live in Drupal and the page should be HTML. Some screens are applications: a tool with its own state, a dense interface on top of an API, a public view that must be assembled from more than one system. That is frontend work.

We build it in React, Angular, or Vue, with TypeScript where the contract is large enough that types will save the next change. The framework follows the product and the people who will maintain it. A component library is introduced when there is repetition to absorb, not as a starting ritual.

Accessible, and connected to the platform

A custom interface for a public institution still has to be usable with a keyboard, a screen reader, and a small window. WCAG is part of the build. So is the empty state, the error from the API, and the moment the session expires. Visual design that ignores those states does not survive contact with real users.

The frontend calls the backend or Drupal we also build. Payloads, authentication, and caching are agreed in the same squad, so the screen and the service do not drift. When a Drupal theme would be simpler, faster, and easier to hand over, that is the recommendation.

• React, Angular, or Vue, chosen for the product and the team that inherits it.
• TypeScript on interfaces where the API contract is the source of truth.
• Keyboard, screen reader, and small-screen behaviour included in the build.
• A clear line between what Drupal renders and what the application renders.

The brief

Bring the task the person has to finish, the systems the screen must read, and who will change it in a year. We reply within 24 hours with whether this is a frontend, a Drupal theme, or both.

This work sits inside Cloud & AI Development. Request information — tell us the organisation, the platform, and the constraint.