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.
About Ember
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.
How we work
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.
Our tech stack
Most frontend work is in React and TypeScript. 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, ClickHouse and Kafka, deployed on AWS with Terraform, GitLab CI/CD, Docker and ECS. We also have SwiftUI and Flutter surfaces in the wider product.
The role
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 solved in CSS.
We care about the details that make software feel obvious, reliable and hard to misuse. Sometimes that means polishing a booking flow. Sometimes it means making an internal maintenance tool clearer and faster. Sometimes it means deciding that a small backend change is better than more frontend complexity.
Diversity and equality
At Ember, we support diversity across our team and customers. We work to ensure every employee feels respected and able to give their best, whether temporary, part-time or full-time. We’re happy to offer flexible working patterns where they make sense, are compassionate when it comes to time off and offer enhanced maternity and paternity leave. Read more about our approach in our Equal Opportunities Policy.
What’s on offer
You'll receive a salary of £70,000–£110,000 per annum, depending on your experience and skills, plus share options. You'll also have access to frontier AI models with generous usage limits. You'll be expected to work from our office in central Edinburgh most days — we value in-person communication — but there's flexibility around the odd day from home.
How do I apply?
Send your CV and a cover letter explaining why this is the role for you. If you have code from a project you’ve worked on, or something you’ve built that shows your frontend judgement, please send that too. Applications close on 18 July 2026. First-round interviews will take place during the week commencing 20 July 2026.
Who we're looking for
You should want to get involved early in Ember’s growth story, with a real opportunity to shape how we build frontend software. Your approach to work and thinking matters more to us than specific industry experience.
These should sound a lot like you:
-
You have excellent frontend fundamentals. React and TypeScript matter, but so do CSS, layout, browser behaviour, performance and accessibility.
-
You have good taste in how interfaces should look and behave, including when the design is underspecified or the edge cases are awkward.
-
You view AI as a force multiplier and have changed how you work because of it, raising the quality and ambition of what you build.
-
You are pragmatic about architecture. You can explain the trade-offs, choose a direction and change your mind when the evidence changes.
-
You are comfortable making small, well-scoped backend changes when that is cleaner than adding frontend complexity.
-
You care about the system around your own work. You notice duplication, weak patterns and confusing abstractions, then improve them over time.
-
You are comfortable setting standards through examples, feedback and tooling, not just documents. You can give useful technical direction without turning everything into process.
-
You can work in a small team where ownership is real and good engineering means thinking clearly about the product and design too.
Relevant experience with the technologies we use is useful, but we care more about fundamentals and judgement than exact tool overlap.
