Tech Radar

Every team faces the same question dozens of times a year: should we adopt this new library / framework / pattern? The unstructured answer — "let's try it" or "let's not" — produces two failure modes. One is technology sprawl: half-adoption of everything that looked promising, none of it load-bearing. The other is stasis: never adopting anything, until the stack is five years behind and hiring is hard.

A Tech Radar is a small ritual that gives the team a shared language for these decisions. Popularized by ThoughtWorks, the format is now widely used in product teams. It does not replace judgment — it makes the judgment explicit and reviewable.

What a Radar Is

A Tech Radar is a snapshot of where the team stands on a curated list of technologies. Each entry is placed in:

• Adopt — proven for this team's context; the default choice when the need arises.
• Trial — worth trying on a real (low-risk) project; expect to learn whether it belongs in Adopt or Hold.
• Assess — interesting enough to keep an eye on; experiment in a side project or proof of concept.
• Hold — not recommended for new work; existing usage may be tolerated but not extended.

Entries are grouped by quadrants — typically: Languages & Frameworks, Tools, Platforms, Techniques.

The visual is a half-pie with four concentric rings (Adopt closest to the center) and four wedges (the quadrants). Most teams render it as a markdown table; the visual is nice but optional.

Why It Works

• Decision capture. Instead of relitigating "should we use TanStack Query?" in every project, the radar says where the team stands.
• Onboarding. New hires read the radar and learn the team's defaults — what's blessed, what's deprecated.
• Sunset signal. "Move from Adopt to Hold" is a clean way to retire a tool without a flame war.
• Outside view. Looking at the radar as a whole exposes biases: too much fragmentation in one quadrant, no movement in another for a year.

Why It Sometimes Doesn't

• Theater. The radar is updated once, then ignored. Becomes decorative.
• Tyranny. The radar becomes a list of bans. Anything not in Adopt is forbidden, regardless of project context.
• Wishful thinking. Things get moved to Adopt because someone wants them adopted, not because they have been validated.
• No mechanism for entries. Engineers see a missing technology and have no way to propose adding it; the radar becomes the in-group's view.

The discipline that prevents these is the process around the radar, not the radar itself.

The Process

A radar that updates produces value; a static one rots. The minimum viable cadence:

Quarterly review

A 60-minute meeting, every quarter. Format:

1. Survey. Two weeks before, send a form asking "what new technologies should we discuss?" — open to the whole team.
2. Triage. A small group (two seniors + the most curious mid) decides which proposals warrant 5 minutes of group time.
3. Discuss and decide. For each candidate: present the case, hear concerns, place on the radar (or explicitly not).
4. Publish. New radar committed to the repo; changelog notes what moved and why.

Quarterly is the right cadence for most teams. Faster, and the radar feels like overhead; slower, and the world has moved on between reviews.

Per-decision entries

Between quarterly reviews, individual engineers can propose adding a single entry via PR to the radar repo (treat it like an ADR). The PR is reviewed in the next quarterly meeting unless urgent.

Movement rules

Movement of an entry follows rules that are themselves part of the radar:

• Promote to Adopt requires evidence: at least one production use, no blocking issues, alignment with at least one other team using it (or explicit acceptance of being on an island).
• Move to Hold requires evidence: known blocking issues, deprecated upstream, replaced by a better option, or strategic decision to consolidate.
• Remove entirely is for entries that are no longer relevant (the technology is gone, the problem it solved is no longer a problem).

The bar should be higher to move toward Adopt than to move toward Hold; it is easier to repent than to commit.

Anatomy of an Entry

A radar entry is small — three or four lines:

### TanStack Query

**Ring:** Adopt
**Quadrant:** Tools
**First listed:** 2024-Q1
**Last moved:** 2024-Q4 (Trial → Adopt)

We've been using TanStack Query for server state across two products
for nearly a year. It has displaced the bespoke fetch wrappers and
reduced cache-related bugs to near zero. Strong recommendation for
new web projects; consider it the default for fetching, caching, and
mutating server state.

**Don't use for:** local UI state, real-time subscriptions (use a
purpose-built client).

The entry is opinionated. A radar entry that says "TanStack Query has some pros and cons, it might be useful sometimes" provides no guidance — readers cannot tell if the team has tried it.

Frontend Radar: Categories

For a frontend-focused team, the quadrants usually look like:

Languages & Frameworks

• Programming languages (TypeScript, Dart, Swift, Kotlin).
• UI frameworks (React, Vue, Svelte, Flutter, React Native).
• Backend-for-frontend / SSR (Next.js, Remix, Nuxt).

Tools

• Build tools (Vite, Webpack, Turbopack, esbuild).
• Test runners and libraries (Vitest, Jest, Playwright, Detox, Maestro).
• Linters and formatters (ESLint, Biome, dart format).
• Package managers (pnpm, yarn, npm).
• Component-development tools (Storybook).

Platforms

• Hosting and deployment (Vercel, Netlify, Cloud Run).
• CDN and edge platforms.
• Mobile distribution (App Store Connect, Play Console, TestFlight, App Center).
• CI/CD (GitHub Actions, Azure DevOps, GitLab CI).
• Observability (Sentry, Datadog RUM, Honeycomb).

Techniques

• Architectural patterns (micro-frontends, monorepos, BFF).
• Testing approaches (RTL queries, MSW, contract testing).
• Performance practices (Core Web Vitals budgets, bundle analysis, RUM).
• State patterns (server state vs client state separation, query libraries).
• Cross-platform strategies (Flutter vs RN, web component libraries).

A specific list is more useful than a generic one. Tailor to what the team actually decides about.

A Sample Frontend Radar

For illustration only — pick the entries that match your team's actual decisions.

The radar's value is not in any single placement; it's in being able to point at it during a design discussion and say "that's in Trial, what are we trying to learn from this project?"

Common Decisions to Capture

These are the recurring questions a frontend tech radar answers:

• State management. Which library for server state? For client state? When to use neither?
• Styling. CSS-in-JS, utility-first (Tailwind), CSS modules, or platform-specific (Flutter ThemeData)?
• Component libraries. Build in-house, adopt one wholesale, or pick primitives (Radix, HeadlessUI) and style ourselves?
• Forms. Which library, or no library?
• Testing. Component-level (RTL / RN Testing Library / widget test), E2E tooling (Playwright / Detox / Maestro).
• Build target. Browser support matrix, mobile minimums.
• Monorepo. Tooling (Nx, Turbo, pnpm workspaces, Bazel) — or not?
• API access patterns. REST + Query, GraphQL + cache, gRPC-Web?

Each of these is a recurring discussion in any product frontend team. A radar entry resolves it for the team-wide default; project-specific deviations can still happen, but with a reason.

Anti-Patterns

"Everything is Trial"

A radar where most entries are in Trial reflects a team that hasn't made decisions. Trial is a transient state — entries should move to Adopt or Hold within two quarters. A long-lived Trial is decision avoidance.

"Adopt by inertia"

Tools end up in Adopt because they were always there, not because they meet the current bar. Periodically re-evaluate Adopt entries: would we choose this today, knowing what we know?

"Hold the whole world"

A radar with twenty Hold entries is a list of grievances. Hold is for things people are actively choosing or proposing to use; an obsolete tool nobody uses today does not need a Hold entry — remove it.

Off-team adoption

Engineering team A puts something in Adopt; team B adopts it without consulting their own radar. Discover later that the contexts were different. Radars are team-scoped; cross-team adoption needs a separate conversation.

Pre-Commit Question

Before adding or moving an entry on the radar:

If a new engineer joined tomorrow, would this entry help or confuse them?

If help, ship it. If confuse, the placement or the description needs work — sharpen before merging.