Senior Full-Stack Engineer — Platform

The platform is where the product is either good or it is not. It is a dense, information-heavy workspace — long conversation histories, large contact tables, a notes editor, live updates arriving while you work — and all of it has to stay responsive over data volumes that make naive approaches fall over immediately.

This is the surface with the most user-facing work by a wide margin, and it currently shares one owner with everything else in the company. The result is that product quality is gated on one person's attention rather than on how good the ideas are.

We want someone to take it, hold the quality bar, and make it feel like a tool built by people who use it.

• The core workspace. Conversations, contacts, notes, calendar, search — the surfaces people live in.
• Perceived performance. Not benchmark numbers: whether typing feels instant, whether a large list scrolls without stutter, whether a view paints before you notice waiting. This is the difference between a tool people tolerate and one they like.
• Real-time correctness. Live updates arriving mid-interaction without stealing focus, losing a draft, or showing a state that was true two seconds ago.
• Read-path design end to end. The database query, the authorization boundary it crosses, the cache, and the component. When a page is slow you will own the whole chain rather than filing it downstream.
• The interaction craft. Selection, keyboard behaviour, empty states, error states — the parts that separate software that works from software that feels considered.

• Genuinely full-stack. You are equally willing to open a slow query and a CSS file, and you do not treat either as someone else's job.
• Serious React judgement. You know why a component re-renders, you reach for the profiler before the rewrite, and you understand that most "React is slow" problems are data-shape problems.
• You have made a dense interface fast. A table, an inbox, a timeline, an editor — something with far more rows than fit on screen and an expectation of instant response. This is the single strongest indicator for this role.
• Product instinct. We do not have a product manager and are not hiring one. You will get problems, not tickets, and we expect you to have opinions about what should be built and to argue for them.
• Taste, and the ability to defend it. You can look at a screen and say what is wrong with it in specific terms rather than "it feels off".
• Strong TypeScript, and comfort in a large App Router Next.js codebase.

• You have built a rich-text or block-based editor, or worked on collaborative/offline-capable editing and its conflict resolution.
• You have worked on a client with an offline or sync layer and understand why "just refetch" stops being an answer.
• You have owned a design system in a codebase where consistency actually held.
• You are opinionated about accessibility and keyboard-first interaction as a matter of craft rather than compliance.

We are a very small, remote, engineering-led team, and we ship continuously — a change that is right goes out the same day. No standups for their own sake, no story points, no committee between you and production.

You will get problems rather than specifications, and considerable latitude in how you solve them. The counterpart is that you own the outcome, including the part where it is live and someone is unhappy with it.

We use AI tooling heavily and expect you to. It closes the gap between having an idea and seeing it on screen faster than anything before it, which makes taste and judgement the scarce inputs rather than typing speed.

Fair warning on ramp: this is a large codebase with a lot of accumulated context. Expect four to six weeks before your first meaningful independent merge.

Competitive salary and meaningful equity. We will give you the band in the first conversation rather than making you ask.

The process is short and centred on real work:

1. A 45-minute conversation with our founder about your background and the surface you would own.
2. A walkthrough of something dense and interactive you have built — we would rather see a real interface than hear about one.
3. A paid, scoped exercise against a realistic problem, sized to a day.
4. A final conversation on how we work, comp, and your questions.

We do not do unpaid take-homes and we do not do surprise algorithm rounds.