TypeScript stack and tooling
We prefer TypeScript over JavaScript for frontends and backends alike. One typed language across the stack lets engineers move between projects, and it gives coding agents a type checker that catches their mistakes before a reviewer has to.
Within TypeScript these are our preferred choices for new projects. They are defaults, not rules: deviate when a project has good reasons, and discuss it in the team.
Next.js or TanStack Start as the full-stack framework. Next.js is our established choice and remains a good fit, especially for content-heavy public sites. For new application-like products we increasingly use TanStack Start (1.0 since October 2026): built on Vite, with type-safe routing and server functions.
Contract-first typed APIs. Define the API contract in code and publish it as OpenAPI, with oRPC or ts-rest, in line with our preference for REST over GraphQL. tRPC is fine when client and server live in the same TypeScript monorepo and the API has no other consumers.
Drizzle ORM for data access. It stays close to SQL, is fully typed and generates plain SQL migrations. Our newer projects use it; older projects on Prisma do not need to migrate.
better-auth for authentication inside an application. When several applications share users or a central identity provider is needed, use Keycloak.
Tailwind CSS with shadcn/ui for styling and components. shadcn/ui builds on Radix primitives and gives us accessible components we own as source code instead of as a dependency.
Zod for schemas and validation. One schema validates input at runtime and provides the static type, shared between client, server and API contracts.
Bun and Biome in our newer templates. Bun installs, runs TypeScript and tests without extra tooling; Biome replaces ESLint plus Prettier with one fast tool. Node.js (LTS) and ESLint with Prettier remain common in our projects and are fine.
Beyond that we use the usual building blocks: React, Vite, Vitest, Turborepo and Playwright, with TanStack Query for server state and React Native for mobile.
We prefer TypeScript to JavaScript. Our decision in more detail:
In the context of creating user-interfaces with React and back-end applications using Node.js, facing the proliferation of different languages used within INFO and the engineering communities at large we decided for TypeScript as the preferred language in favor of JavaScript and neglected Flow and others languages, to achieve a common way of working that will allow software engineers to work on or maintain multiple code bases over multiple projects, accepting limiting the options for teams and individual engineers to select their tools.