Technology Radar

Our default language for new projects. It gives us type safety and a stronger developer experience.

Our primary framework for building user interfaces.

A production-ready React framework with SSR, SSG, and strong developer experience.

Runtime for server-side JavaScript applications.

An enterprise-grade Node.js framework with strong TypeScript support out of the box.

A progressive UI framework we assess selectively for specific projects.

A utility-first CSS framework that helps us move quickly on interface work.

A minimal and flexible web framework for Node.js services.

A reliable relational database with strong performance and ecosystem maturity.

Our primary cloud platform for hosting and infrastructure.

Containerization for consistent environments across development and production.

In-memory data storage that helps improve application performance.

Container orchestration that we use selectively on newer infrastructure-heavy projects.

A NoSQL database for use cases where flexible schemas matter.

A search engine for full-text indexing and retrieval.

A message broker for asynchronous service-to-service communication.

CI/CD automation integrated directly into GitHub workflows.

A deployment platform we often use for Next.js and frontend delivery.

An open-source Firebase alternative we actively evaluate on new projects.

Google’s Backend-as-a-Service platform that we assess mainly for MVP use cases.

A platform for JAMstack applications with streamlined deployment flows.

A payment platform for handling online billing and transactions.

Error tracking and performance monitoring for production applications.

Continuous integration and delivery is a baseline practice across all projects.

Test-driven development as a quality practice for complex codebases.

An architectural approach for larger systems that we apply selectively.

An API query layer we assess when it offers real benefits over REST.

React Server Components in modern Next.js. We are actively testing them in real scenarios.

A mandatory practice for keeping code quality and engineering consistency high.

Iterative delivery with short sprints and regular feedback loops.

A system design approach built around domain models for complex products.

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

We do not select it for new launches: the framework is EOL, carries high technical debt risk, and has a limited hiring market.

Not recommended: a shared database across services breaks domain boundaries, complicates migrations, and makes releases riskier.

We usually avoid it for MVP stage: operational overhead is too high compared with business value in early phases.

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

We avoid this delivery model: large infrequent releases increase incident risk and slow down feedback loops.

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.

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

A fit for Python-first products and back-office systems. We apply it selectively based on domain and team context.

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 launches: our delivery process and team expertise are focused on the TypeScript/Node/Go ecosystem.

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.