Technology Radar

Our default frontend language. We use strict typing and account for TypeScript 6 changes ahead of the future native compiler.

Our primary UI library. Current applications use React 19.2 with modern rendering and form APIs.

Our default framework for public websites and SEO-focused products. We use the App Router, Server Components, and Turbopack.

Our default build tool for SPAs and internal applications. Vite 8 uses Rolldown as its unified bundler, so upgrades go through the full test suite.

Our primary backend language for APIs, background jobs, and integrations. We value predictable performance and straightforward deployment.

Used for mobile products that benefit from a shared TypeScript/React stack and native iOS and Android interfaces.

Routing for SPAs and application workspaces, with typed routes and URL-managed state.

Our standard frontend server-state layer for caching, retries, mutations, and keeping UI synchronized with APIs.

Used for systematic UI delivery, responsive interfaces, and efficient design-token workflows.

A compact client-state layer for data that does not belong in the API cache or URL.

Used selectively for complex SPAs where type-safe routes and search parameters provide clear value.

The Garmin Connect IQ language, used for watch faces and apps with strict memory, display, and power constraints.

We track the native TypeScript 7 compiler, but do not use preview builds in production.

A progressive UI framework we assess selectively for specific projects.

We assess it selectively for enterprise contexts. For most MVP and product launches, we choose alternatives with faster delivery speed.

We treat it as a niche option: more for enthusiast use cases. For large commercial projects, the ecosystem and hiring market are still weaker.

We consider it for Vue-oriented teams, but for new launches we more often default to the React/Next stack.

We assess it for selected web products. Usage is still limited to cases with clear UX and routing advantages.

Why use slow Python and Django when we have fast and reliable Go? We assess it only for specific Python-first workloads and ML/Data integrations, not as our default backend stack.

We do not use this for new projects: PHP/Laravel is outside our current production focus and does not match our speed/support strategy.

We do not use it for new launches: our delivery process and team expertise are focused on the TypeScript/Node/Go ecosystem.

We avoid this for new projects: it increases maintenance cost, weakens type safety, and does not fit modern React/Next architectures well.

Not selected for new projects: React has deprecated CRA and recommends frameworks or modern build tools.

Legacy support only because official long-term support has ended.

Used for cross-platform desktop and mobile apps with web frontends and Rust backends: tiny binary size and minimal RAM usage.

A lightweight, ultrafast web framework for Edge, Cloudflare Workers, Node.js, and Bun with end-to-end type safety.

Not used for new projects: excessive boilerplate. Zustand and TanStack Query handle client and server state more simply and reliably.

Not used for new launches: lags behind our TypeScript/Go stack in type safety, API speed, and infrastructure efficiency.

Not recommended for web apps: canvas-based rendering via CanvasKit/WASM impairs SEO, accessibility (a11y), text selection, and bundle size.

Avoided for simple desktop utilities: bundling full Chromium with 300+ MB RAM usage is unnecessary given lightweight alternatives like Tauri.

Our default transactional database for strong integrity, migrations, JSONB, and mature operational tooling.

Object storage for user files, releases, and images through the S3 API and MinIO-compatible implementations.

Used for real-time workflows where polling would add unnecessary latency or load.

Used where containers genuinely simplify environments and delivery; not mandatory for every small service.

Added for caching, rate limiting, and short-lived state only when the need is demonstrated.

Used for automated checks and delivery in GitHub repositories, with controlled production activation for critical systems.

Assessed for systems where scale, isolation, and service count justify the operational complexity.

Vector embeddings and semantic AI search directly in PostgreSQL without paying for or managing separate vector databases.

Our default tool for browser E2E tests: reliable parallel execution, visual snapshots, and critical user path verification.

An ultrafast Rust-based linter and formatter. We assess it to speed up CI and local DX as a replacement for ESLint + Prettier.

Not recommended as default MVP infrastructure without a measurable need because operating cost usually outweighs the benefit.

Not recommended as the primary transactional store: PostgreSQL with native JSONB provides integrity, typing, and flexibility without consistency issues.

We avoid manual SSH production server setup: all environments are provisioned via reproducible Docker, CI/CD, or managed PaaS.

Not used for new projects: heavy configurations and slow builds. Our default is Vite 8 (Rolldown) and Turbopack.

A platform for Next.js and frontend applications when its hosting model and cost fit the product.

Used in production when managed PostgreSQL, Auth, Storage, and real-time capabilities fit the product.

Garmin's watch-face and app platform, with device compatibility, memory, AOD, and display constraints built into delivery.

Used for measurable AI workflows with explicit controls for cost, privacy, fallback behavior, and output quality.

Used for error and performance monitoring when a product needs centralized production observability.

Assessed for focused mobile and real-time use cases, with cost and data portability modeled first.

Not recommended for new product launches: expensive maintenance, harder architecture evolution, and high vendor lock-in.

We do not use it for new websites and product launches: high vendor lock-in, difficult maintenance, and limited architecture flexibility.

We do not use it for new product projects: high plugin dependency risk, weaker quality control, and less predictable scaling.

We do not use it for new projects: we consider it not reliable enough for our production requirements and long-term support.

Not recommended for complex products: cost control, strict access governance, and schema evolution become harder at scale.

We avoid no-code builders for complex SaaS products: strict customization limits, vendor lock-in, and inevitable costly rewrites.

We do not build custom auth/crypto from scratch for early MVPs: Supabase Auth or mature providers save weeks and guarantee security.

Our default integration contract: explicit resources, HTTP semantics, versioning, and predictable error responses.

We combine unit, integration, and browser E2E tests in proportion to change risk.

Every release gets reproducible checks, a build, and smoke tests; production activation may remain manual and controlled.

Reviews cover correctness, security, migrations, UX, and operational consequences rather than code style alone.

Used in Next.js to reduce client JavaScript and fetch data on the server, with explicit client/server boundaries.

Our preferred starting backend architecture: domain boundaries without premature distribution.

We deliver small verifiable changes with rollback paths and short feedback loops.

Semantics, keyboard access, focus, contrast, and reduced motion are baseline UI acceptance criteria.

AI supports analysis and delivery speed, while changes still pass the same reviews, tests, and security checks.

We apply useful DDD elements in complex domains without turning terminology into mandatory ceremony.

Services are extracted when independent scale, ownership, or release cycles appear, not at the start of every product.

Assessed when client query complexity justifies the additional schema, caching, and operational model.

Not recommended because a shared schema removes service independence and couples migrations and releases.

Not a standard delivery model because large infrequent releases complicate verification, rollback, and incident diagnosis.

We avoid dogmatic 100% coverage targets: we prioritize business invariants, integration, and E2E tests over mocking trivial code.

We do not start early products with distributed microservices: a modular monolith delivers faster without infrastructure overhead.

We avoid multi-month isolated branches: we practice Trunk-Based Development, short PRs, and feature flags to avoid merge hell.