About the role
The dashboard is where a customer does the actual work: import a file, agree the shape of the columns, write the contract for a field, run it, review what the run was unsure about, curate the result, publish a release and deploy it as a tool with keys and security settings.
That means data-dense interfaces that have to stay usable, rather than marketing pages: tables of thousands of records, a receipt behind every value, a review queue that gets to zero. Server state comes from a generated API client, and the rule is that it stays server state rather than being mirrored into local state and drifting.
You would also own the design system shared between the public site and the dashboard: one definition of each component, so the two halves cannot drift apart.
What you'd do
- Build data-dense interfaces that stay usable: tables of thousands of records, receipts behind every value, review queues
- Work from the generated API client and keep server state honest rather than mirrored into local state
- Hold the design system: one definition of each component, shared between the marketing site and the dashboard
- Check every screen at desktop and at 390px before calling it done
- Make the slow paths feel deliberate: optimistic updates where they are safe, honest progress where they are not
What we need
- Two or more years building React applications that other people used
- Solid TypeScript, and CSS you write on purpose rather than by trial and error
- You have built at least one genuinely complex interface (a table, an editor, a queue), not only forms and cards
- You test the parts worth testing and can say why the rest are not
- Keyboard access and focus states are part of your definition of done
Nice to have, not required
- Experience with TanStack Query or a similar server-state library
- You have worked on a design system used by more than one application
- Canvas, SVG or data visualisation work
How we work
- Small team, thin slices, shipped weekly. Nothing sits on a branch for a month.
- Reviews are real. Every feature ships with its tests, and a bug found in review is cheaper than one found by a customer.
- Safety-critical means the boring answer usually wins: fail closed, keep the receipt, don't guess.
- We only claim what ships. That applies to the product, the roadmap and the offer letter.
How hiring works
- 1A 30-minute call about something you've built and what was hard about it.
- 2A working session on a real problem from this codebase. You can drive, or we can pair.
- 3A conversation about how you make decisions when the evidence is thin.
- 4References, then an offer. We aim to answer within a week at every stage.