Skip to main content

AI, tools and trade-offs: introducing the Nitor Technology Radar

Published in Technology, AI

Written by

Mika Majakorpi
Mika Majakorpi
Chief Technology Officer

Mika Majakorpi works as CTO at Nitor. Mika has been there and done that in various architecture and development roles for years in the Finnish IT scene. Lately he's into Event Driven Architecture and data driven solutions.

Joakim Gunst
Joakim Gunst
Principal Software Architect

Joakim Gunst is a versatile software developer and architect with fifteen years of professional experience. He most enjoys working on the front end, crafting user interfaces that are beautiful, intuitive, fast, and accessible.

Article

AI is changing how we build software, and keeping up takes deliberate effort. To get a clearer view into the next year, we decided to create the first Nitor Technology Radar. It presents our opinion on interesting and relevant technologies and tools, as well as a few things to approach with care. If you are considering using a new technology, you might want to check our radar review first.

The radar results are based on experience from our client and internal projects. We started by sending a survey to all Nitoreans, to map their insights on new or trending technologies. We then gathered a group of our experts across backend, cloud, frontend, mobile, data, AI and design to discuss, curate and write the final blips. 

We also run an annual developer survey to track which technologies our developers are currently using and what they think of them. It's a separate study, but a good companion read to the radar.

What is a Technology Radar?

A technology radar is a structured way to share an organisation's take on technologies worth paying attention to. The radar uses the format established by the Thoughtworks Technology Radar

It consists of 86 blips, each placed into one of four quadrants: techniques, tools, languages & frameworks and platforms. Sometimes the category is not clear-cut, so the quadrant shouldn’t be given too much importance.

The rings

The blips are also placed into one of four rings, representing our opinionated take. Moving outward from the centre, the rings go from well-proven to more experimental. 

Adopt is the innermost ring and contains proven technologies that we can recommend for all appropriate projects. We keep it limited to focus more on the outer rings, which we find more interesting. 

The Trial ring contains blips we have hands-on experience with and consider production-ready, but are less established. Use these in projects that can carry a bit more risk.

Assess is the next ring. It contains blips we cannot yet recommend for production use, but are promising and should be investigated and tested in proofs of concept. 

Finally, we have Caution. Placing a blip in Caution does not mean we think it should be avoided at all costs, but the concerns and trade-offs should be carefully considered.

Nitor's technology radar with four rings.

Our selected highlights

On the AI side, the Trial ring shows where things are starting to solidify. Context engineering and agent skills have moved beyond the experimentation phase. Teams are starting to build repeatable ways to structure model behaviour and package those approaches into reusable workflows. Open-weight models are there too: running your own model is now genuinely viable, which matters if vendor lock-in is on your mind.

Multi-agent workflows are probably the most over-discussed item in the Assess ring. Everyone can see the potential, but reliable production implementations remain rare. Most teams are still figuring out where the boundaries between agents should be and how much autonomy they're comfortable giving them.

Some of the Caution placements are more surprising: 

One is artisanal coding: writing every line by hand without AI assistance. The concern is not code quality, but productivity. Teams that refuse to adopt AI-assisted development are increasingly choosing a slower path without gaining much in return.

Kubernetes is another cautionary placement. It is a solid technology, but most teams don't actually need it. Managed services do the job with far less overhead. JS/TS as the default also gets a flag. The npm ecosystem still has significant supply-chain risks. Using the same language across frontend and backend can make systems more tightly coupled and harder to evolve over time.

The best way to get value from it is to look up the technologies you're already using or considering. See if our take matches yours.

Here’s the radar

Written by

Mika Majakorpi
Mika Majakorpi
Chief Technology Officer

Mika Majakorpi works as CTO at Nitor. Mika has been there and done that in various architecture and development roles for years in the Finnish IT scene. Lately he's into Event Driven Architecture and data driven solutions.

Joakim Gunst
Joakim Gunst
Principal Software Architect

Joakim Gunst is a versatile software developer and architect with fifteen years of professional experience. He most enjoys working on the front end, crafting user interfaces that are beautiful, intuitive, fast, and accessible.

Ville Himberg

Let’s get together and engineer tomorrow’s success

We are here to meet your challenges. Let's harness the potential of your business together.