Senior/Lead Fullstack Engineer

THE PRODUCT

We build an AI agent for office work — people who spend their days preparing documents, working through spreadsheets and checking what the rules say, and whose output has to be right, not merely plausible.

That constraint shapes the whole engineering problem. The product reads the files people actually work from, drafts the document or spreadsheet that comes out of them, and finds the regulation or precedent a decision rests on — while showing exactly where every claim came from. Doing any of that on real customer material means solving the data boundary, tenant isolation, citation provenance and audit before anything else is worth building.

It ships as a multi-tenant product. Each customer organisation is a tenant with its own access boundary, its own seat and token budget, and its own audit trail. Scale is measured in hundreds of tenants and thousands of seats rather than one large workspace, so the interesting failures are isolation failures and cost failures, not raw throughput.

We have not solved all of it yet. That is the engineering problem, and it is the job.

THE STACK, AT A HIGH LEVEL

A TypeScript monorepo (npm workspaces + Turborepo) on Node.js 24, built on an open-source chat/agent platform we consume and contribute to rather than rewrite.

• Backend — TypeScript services behind a thin Express layer of legacy JS we are steadily retiring.

All new code is TypeScript, strictly

• Agent runtime — A graph-based agent framework (LangGraph underneath) with durable multi-turn runs,

subagents, scheduled and event-triggep approval, code execution andartifacts. Inherited and capable; we extend it, we do not fork it.

• Data — MongoDB + Mongoose for appli pgvector for retrieval, Meilisearchfor conversation search.

• Distributed layer — Redis, single a rate limits, cross-replica routing,run leases.

• Tools — MCP (Model Context Protocol first-party skills system forpackaged capabilities.

• Auth — Passport strategies, enterpr LDAP, JWT + JWKS.

• Frontend — React 18 + Vite + Tailwind, TanStack Query for server state, Jotai (mid-migration off

Recoil), Radix / Ariakit primitives ookenised design system, i18next withVietnamese as the default locale. A separate admin SPA for tenant and user provisioning.

• Platform — Terraform end to end.

• Testing — Jest per workspace against real dependencies (mongodb-memory-server, real protocol SDKs),

not mocks.

Today the stack runs outside the counce leaving the region. An in-regionpath is on the roadmap and you will help design it.

WHAT YOU WILL ACTUALLY WORK ON

1. A highly scalable backend

Designing the services, data access a the product from hundreds of tenantsto many thousands without a rewrite: horizontal scale across replicas, data models and indexes that

hold up under real load, caching and heir place, and headroom that ismeasured rather than assumed.

2. Multi-tenant isolation

Tenant-scoped roles, data stores and hundreds of tenants, where a leakacross a boundary is the failure that ends the company. Some of these seams are genuinely incomplete

— role seeding, for one, is still gloe to a tenanted user. Closing them isyour first quarter.

3. Cost and latency at scale

Caching, payload compaction, windowinand usage rollup. Per-seat uniteconomics are decided in this code rather than in a spreadsheet, and a change that looks free at one tenant is not free at a thousand.

REQUIREMENTS

You have owned a product, not just a

You shipped something end to end and stayed with it after launch — you made the scoping calls,

watched the metrics, absorbed the supproduction taught you. Tell us what it was, what you got wrong, and what you would rebuild.

High initiative

Small team, hard market, a lot of unret a problem statement, not a ticket.We expect you to find the real constraint, propose the shape, disagree in writing when the plan is

wrong, and ship without waiting to be

Communication

You write things down — the design call, the disagreement, the status — where they can be read, challenged and found later. You can engineer, and the same trade-off to the person who sells the product.

LLMs as an engineering substrate

Not prompt-writing — the systems laye

• Harness design — context assembly, tool and function schemas, sub-agent decomposition, approval and

human-in-the-loop gates, failure and alls.

• Skills / capability packaging — designing reusable, discoverable model capabilities, and knowing

when not to expose one.

• Token optimisation — measuring before optimising: prompt caching, context compaction, history

windowing, retrieval budget against at model that keeps amulti-thousand-seat deployment viable.

Full-stack in practice

You can ship a React feature end to eder cost, accessibility and whatstacked diacritics at small sizes do to legibility. The user-facing surface is half the product, and

there is nobody else to hand it to.

Languages

You read Vietnamese as well as English. Our users work in Vietnamese, and the source material the

product reasons over is not written iannot be checked in translation.

Nice to have

• Enterprise or regulated-industry delivery.

• Enterprise SSO integration (OIDC / s identity provider.

• Performance work on a live production system, driven by real telemetry rather than guesses.  • Open-source contribution to an LLM or developer tooling.

                                                HOW WE WORK

                                                • TypeScript-first, strictly typed. Nand in the legacy layer.

• Design decisions are written down before they are coded — the domain language is a maintained document, not tribal knowledge.

• We use AI coding tools daily and every pull request gets an automated review before a human one.

Review is substantive and reciprocal,ted parts.

WHY THIS ROLE

• A genuinely cutting-edge AI product of what LLM systems can do inproduction — agent runtimes, tool harnesses, retrieval, context and cost engineering — not a chat wrapper over someone else's API.

• A small team of people who have already done it. The engineers here have built and shipped software

used by millions of people worldwide.cisions carry weight and reachproduction quickly; senior enough that they get challenged properly on the way.

• High ownership, and it moves fast. atement to production and keep it —the design call, the code, the rollout and what it does at scale. Decisions get made in days, not

quarters.

• We use the latest technology wherever it earns its place. New models, new runtimes and new tooling

get adopted on their merits rather thsafe and boring — and you will oftenbe the one making that call.

TO APPLY

Send a short note — no more than 200 words each:

1. The product you owned, and its fai

2. One distributed-systems bug you diagnosed that was genuinely hard, and how you found it.