Senior Frontend Engineer

Lyearn is an AI-native workforce intelligence platform. We help large organisations understand what their people are actually doing, what they're good at, and what's getting in their way — and then act on it.

We're an unusual company. Ten years old, bootstrapped, and profitable — but the product you'd be joining is barely two years old, because we took the original platform apart and rebuilt it from the ground up. New architecture, new team, new thesis about what this category should be. That rebuild is roughly two-thirds done, and the next stretch is the part where the product has to look as intelligent as it is.

Our customers are enterprises - a major private-sector bank, a high-growth commerce business, a global consumer brand - and they're demanding in exactly the way that makes work interesting. They notice everything.

The role

We're hiring one senior frontend engineer to own the visual and interaction layer of the product. Not a team lead, not a manager - an engineer whose work sets the standard for everything we ship.

You would be the most senior frontend person in the company. That means real ownership: you make the calls on how our interfaces are structured, how our component layer evolves, and what "good" means here. It also means the work is visible. There's no layer of process between what you build and what a customer's VP sees on Monday morning.

What you'll build

Information-dense product surfaces. A sales leader opens Lyearn and sees two thousand opportunities distilled into the five things worth their attention today. A manager sees a skill footprint rendered as a radial chart that has to be legible at a glance and precise on inspection. An analytics module where the same underlying data reads completely differently depending on whether a CEO, a revenue leader, or an individual rep is looking at it.

The hard part isn't any single screen. It's that every screen is an argument about what deserves attention - and it has to stay fast and readable while making that argument. Dense tables, custom visualisations, layered filtering, live data. This is closer to building a cockpit than building a website.

Alongside the surfaces themselves, you'd own the component layer they're built from: the primitives, the patterns, the design tokens, and the consistency that makes a product feel like one product.

Our stack

React 19 · TypeScript · Vite · Tailwind v4 · GraphQL (urql) · recharts / d3 · Oxlint

We're on modern versions deliberately and we keep them current. If you enjoy working on a codebase that isn't fighting five years of accumulated compromise, you'll like it here.

What we're looking for

You've shipped product UI at a genuinely high visual bar. You can take a Figma frame and land it exactly - spacing, weight, rhythm - and you're also the person who tells the designer when the frame is wrong, with a reason.

You've done data-dense rendering for real. Virtualised lists, large tables, custom charts, interaction that stays smooth under load. You've hit a performance wall, measured it properly, and fixed it - and you can talk about that with specifics rather than adjectives.

You think about GraphQL as a client architecture problem, not just a way to fetch things. Cache behaviour, fragment design, knowing when the shape of the data is the actual source of the bug.

You build things other engineers build on. A component library, a design system, a set of primitives with a point of view - not just assembling someone else's.

And you work well without a fully-specified ticket. We'll give you context, constraints, and a goal. What we need back is something real to react to, quickly.

Roughly six or more years of frontend experience usually gets someone to this point, but we care much more about what you've shipped recently than about the number.

How we work

We ship weekly. We'd rather look at a rough version of the real thing on Tuesday than a polished plan for it in three weeks - most of our arguments get settled by building the thing and looking at it.

Strong opinions are genuinely welcome. We're a small enough team that one person can change how the whole product feels, and we'd rather hear "this is wrong and here's why" early than discover it after launch. What we ask in return is that opinions move when the evidence does.

You'd work closely with our Head of Engineering, our product designers, and the CTO. Decisions get made in hours, not sprints.

Honest about what this isn't

This isn't a large team with process cover. There will be weeks where priorities shift under you because an enterprise customer needed something.

If you want scale and stability, there are better places. If you want your fingerprints on the whole thing, this is a good one.

How to apply

Apply here on Wellfound and send us a link to your work. Send us one thing you've built that's dense with information - a dashboard, a tool, an internal product, anything real. Along with it, two paragraphs about a rendering or data-layer problem inside it that you solved, ideally with the numbers.

We read every one of these properly, and we'll get back to you either way.