Senior Frontend Engineer & Product Architect.
Xan Torres. 15+ years building production TypeScript/React apps. I take on messy frontend work: migrations, data-heavy UI, design systems, and features that need to survive real users.
What I'm good at.
Architecture that holds up
I map data flow, state boundaries, and core interactions before the first component lands. The goal is boring in the best way: fewer rewrites, fewer surprises, and code the next engineer can understand.
Frontend craft with receipts
I care about the visible layer and the numbers behind it: interaction detail, Core Web Vitals, accessibility, loading states, and the awkward edge cases users always find.
Product judgment
I am comfortable with vague requirements, stakeholder pressure, and incomplete information. I push for the useful version, not the version that only looks tidy in a ticket.
Codebases teams can live with
Typed boundaries, migrations that do not freeze feature work, and CI that catches regressions before they reach main. I have joined codebases at every stage and left them easier to change.
Latest projects.
Roulette mini-game, missions, and ops tooling.
Ops and gameplay teams needed better tools while economy and game work kept moving.
Live govtech migration, no release gaps.
The app needed a new frontend foundation, but municipal users still needed releases every week.
Design-system fixes on mongodb.com.
High-traffic marketing pages needed library improvements, but dozens of consumers depended on those packages.
Shared UI for a private-cloud console.
The console needed reusable UI building blocks and a predictable way to cache and persist server data, instead of components and fetch logic re-solved case by case.
How I work.
Map the system first.
Before touching components, I want to know where the data comes from, who owns state, and what can break. That saves time later.
Keep boring things boring.
Routing, forms, tables, and data fetching should be predictable. The polish belongs in the interactions users actually touch.
Trust one source of truth.
Client mirrors of backend calculations drift and create support tickets. The UI should render the truth, not become a second version of it.
Ship the useful version.
I work well async and remote. I make clear calls, explain the tradeoffs, and keep momentum when perfect consensus would stall the work.
Tools I use.
Frontend
- React 17/18/19
- TypeScript (strict)
- Next.js 13+
- Apollo Client
- Redux Toolkit · RTK Query
- TanStack Query · Table
- React Hook Form · Zod
- Storybook
Design Systems
- Component library architecture
- Tailwind CSS
- MUI · Radix UI · theme-ui
- Design tokens
- Module Federation
- Style isolation
- Accessibility (WCAG)
- Rive · Lottie
Backend (supporting)
- Node.js · NestJS · Express
- Prisma · Sequelize · TypeORM
- PostgreSQL · Redis
- WebSocket · REST · GraphQL
- AWS (RDS, S3, EKS, SSO)
- Docker · Kubernetes
Tooling & Testing
- Vite · Rsbuild · Webpack
- Turborepo · NX · pnpm workspaces
- Biome · ESLint · Prettier
- GitHub Actions
- Jest · React Testing Library
- Playwright · Cypress
Work together.
If you need a senior frontend owner for a React product, migration, or design-system push, send me the rough shape. I'm best when there is ambiguity, pressure, and real users waiting.