Quality & Team

Choosing Technology

Intermediate

Adding a new language, framework, database, or major library is a long-term commitment the whole team takes on: to learn it, secure it, patch it, and live with it for years. Choose deliberately. Prefer our established stack, weigh the real cost of anything new, and decide as a team, not as a personal preference slipped into a PR.

New technology is exciting and sometimes the right call. But every addition has a cost beyond the problem it solves. The team must learn it. It adds new attack surface and a new patching duty. It needs operational support. And it fragments the codebase if it overlaps with what we already use. Lean toward consistency with our existing stack (.NET/C#, Dapper/SQL Server, React, Azure, Pulumi) unless there is a clear, considered reason to differ.

This connects Dependency & Supply-Chain Security (what you adopt, you must maintain and secure), Technical Debt (the wrong choice is expensive to undo), and Documentation as Code (record significant decisions). The key habit: significant technology choices are team decisions, made openly and written down.

Decide deliberately

DoDefault to our established stack and patterns. Introduce something new only when it clearly beats the existing option for a real need.
DoWeigh the whole cost: how long the team takes to learn it, the security and patching burden, operational support, how mature and well-maintained it is, and licensing (see Dependency & Supply-Chain Security, Open-Source Licensing).
DoMake significant choices as a team, openly, and record the decision and the reasons (a lightweight ADR) so future readers know why (see Documentation as Code).
ConsiderTrying out a risky choice in a small, contained way before you commit the whole system to it.
AvoidChoosing technology just because it is interesting or new (resume-driven development), rather than because it fits the problem and the team.

Limit the damage of new things

DoPrefer fewer, well-understood technologies over many overlapping ones. Consistency lowers cost for a growing, junior team.
DoPut a new technology behind a boundary where you can, so it can be replaced if it does not work out (see Inversion of Control, Domain Modelling & Boundaries).
ConsiderWhether you can solve the problem with what we already have before reaching for something new, and whether a small amount of code beats a new dependency.
AvoidSlipping a new framework, library, or datastore into the codebase through a PR without discussion. Others will have to live with it and maintain it.
NeverIntroduce technology that cannot meet our security, compliance, or data-residency requirements, however appealing it is otherwise (see Compliance by Design).

Self-review checklist

AskCould our existing stack solve this well enough, without something new?
AskHave I weighed the full long-term cost — learning, security, patching, ops — not just today's convenience?
AskIs this a team decision that's been discussed and recorded, or my personal preference?
AskCan it meet our security, compliance, and residency requirements?

Why it matters: Technology choices are hard to reverse. The team lives with them for years, and a poorly considered one fragments the codebase, adds security and maintenance burden, and is painful to undo. Choosing deliberately, leaning toward consistency, and recording it as a team decision keeps the stack coherent and maintainable as the team and product grow.