Lead Frontend Engineer

We’re looking for a Lead Frontend Engineer to set the technical direction for Ember’s frontend while building products used by passengers, drivers and internal teams.

This is a senior individual contributor role, not a line management role. You’ll own how our frontend works: architecture, framework choices, component patterns, styling, testing, performance, accessibility and maintainability.

Most of your work will be hands‑on frontend product development, across customer‑facing products and the internal tools that run our operation. We’re a small team and our best projects often cross boundaries, so you should be happy making small backend changes or touching our apps, when that’s the cleanest way to solve the problem.

We're building the future of public transport — convenient, affordable, connected and zero‑emission. Our goal is to make it easier and more enjoyable to get from A to B with Ember than it is with your own car.

Ember is a tech company, not a traditional bus operator. We've built a platform that coordinates our entire operation – everything from monitoring vehicles and controlling chargers to selling tickets and calculating ETAs. This allows us to use electric buses more intensively than anyone else in the world, leading to a massive reduction in emissions. It also helps us provide a much better passenger experience, with innovative features like demand‑responsive stops.

We’re still tiny, with a handful of routes and ~100 buses. The challenge is to scale this 50x whilst staying lean, increasing efficiency and delivering an even better product experience. We’ve recently raised a Series A from some of Europe’s leading climate VCs and are looking for mission‑driven individuals who want to get on board and help take us to the next level.

We’re a small team and engineers are expected to understand the problem, not just pick up tickets. We don’t have dedicated product managers — you’ll help decide what we build, how it should work and what scope is worth pursuing.

AI tools have changed how we work and what one person can do. We expect you to use them heavily and thoughtfully: exploring unfamiliar code, writing tests, migrating repetitive patterns and moving from idea to working implementation faster. The leverage is real, but only if you have the engineering judgement to know when the output is good and when it is wrong.

Most frontend work is in React and Type Script. We don’t use a utility‑first CSS framework: most styling is authored directly with CSS via styled‑components, so strong browser, layout and styling fundamentals matter. We use Gatsby, Jest and Playwright today, though part of the role is shaping where the frontend stack should go next.

Around the frontend, we have Python services backed by Postgres, Redis, Click House and Kafka, deployed on AWS with Terraform, Git Lab CI/CD, Docker and ECS. We also have SwiftUI and Flutter surfaces in the wider product.

You’ll split your time between product development and frontend platform work.

On the product side, you’ll build features for passengers, drivers and internal teams. That might mean improving booking flows, implementing a website redesign, helping passengers better understand disruption, or building internal tools.

On the platform side, you’ll raise the quality of our frontend and make it easier for everyone else to work in. That includes:

• Planning and executing large architectural changes, such as a migration away from Gatsby.
• Assessing new technologies and tools where they solve real problems.
• Taking responsibility for frontend quality, including CI build times, Web Vitals, Sentry errors, bundle sizes and accessibility.
• Building our own component library and migrating away from Kiwi Orbit and styled‑components where that clearly makes sense.
• Making sure we reuse high‑quality components rather than reimplementing the same thing in slightly different ways.
• Raising the frontend bar through feedback, clear standards, good tooling and quality control, including exploring how review agents can catch issues like duplicated components, design‑system drift, avoidable bundle growth and layout problems…