Languages, frameworks, databases, cloud services, artificial intelligence models: the range of technologies grows every year, and every choice has long-lasting consequences. A well-chosen stack (the set of technologies an application is built with) supports a product for years; a poorly chosen one is paid for in maintenance, security and costs.
In our projects we work with more than 60 technologies, but we don’t have one stack that fits everything. We decide case by case, following ten criteria that we make explicit, so the client can also see why one path was chosen over another.
Start from the problem
1. Project requirements
The first criterion is the most obvious and also the most overlooked: what the system must do, for how many users, with what constraints on response times, availability and lifespan. A management system that will stay in use for ten years has different needs from a prototype to be shown next month. That is why, before talking about technologies, we write down expected load, integrations, security constraints and where the data must reside.
2. Compatibility and integration
A new technology has to live alongside what is already there: sign-in systems, databases, infrastructure, reporting tools. In the Atac ERP for Ernst & Young the microservices are deployed in Docker containers on an on-premise system provided by the client; in the Hera ERP for Atos the application runs on Microsoft Azure, uses Azure Active Directory (now Microsoft Entra ID) for sign-in and Power BI for reports.
Security and costs
3. Security
We look at a project’s vulnerability history, how quickly issues are fixed, the security updates planned for the versions we will use, and support for standards such as OAuth2 and OpenID Connect. An abandoned library is a risk, even if it works today. For sensitive data we also assess where it is stored and what guarantees the provider offers.
4. Costs
Cost is not just the licence. What counts is the total cost: infrastructure, development hours, training and above all maintenance over the years. A managed service costs more per unit of use, but often costs less than running an equivalent system yourself. And a free but little-known tool can turn out expensive when you need to find or train people who know it.
People: productivity, community, experience
5. Ease of use and productivity
Clear documentation, mature development tools, tests that are easy to write: everything that helps the team work faster and with fewer mistakes, today and when someone else has to pick up the code.
6. Support and community
A large community means answers to problems, ready-made libraries and professionals available on the market. A public release schedule, long-term support versions and, where needed, commercial support from a company also matter.
7. Team experience
A technology the team knows well reduces risks and timelines. That is no reason never to learn anything new, but it has to be weighed: the learning curve has a cost, and it is best accounted for before starting.
Looking ahead and checking
8. Industry trends
We follow where the market is going so as not to bet on a declining technology, but we don’t adopt something new just because people are talking about it. A very recent technology can change quickly; in those cases we tell the client and plan a way out. In generative AI, for example, models and tools change within a few months, so it is wise to keep the model behind an interface of the application, so it can be replaced without a rewrite.
9. Tests and proofs of concept
When a doubt matters, we test it with a POC (proof of concept, a small prototype that shows a solution really works): a few days on a real case are worth more than many meetings. We measure performance, ease of integration and quality of the result: two databases or two language models, for example, are compared on the same data and the same questions.
10. Business strategy
Finally, the technology has to fit the client’s strategy: the cloud providers it already has agreements with, the in-house skills it wants to grow, the freedom to change provider in the future, the regulatory constraints on data.
Trade-offs in practice
The ten criteria rarely all point the same way. A few typical cases:
- Long-lived enterprise systems: mature frameworks such as Spring Boot for the back end and Angular for the front end offer structure, shared conventions and planned releases; they need more setup at the start, which pays off over years of maintenance.
- Pilots that need quick validation: lighter tools and managed services get you in front of users sooner, accepting that some parts will need revisiting if the pilot works.
- Artificial intelligence: the Python ecosystem, with libraries such as PyTorch, scikit-learn, Hugging Face and LangChain, is today the reference point, while integration with business systems can stay in Java or TypeScript.
- Build or use a service: the video pipeline of Artika relies on AWS managed services, such as Amazon Transcribe for automatic subtitles and Amazon Rekognition for video moderation, rather than on components built and run in-house.
If you need to start a project or renew an existing system and want to understand which stack suits you, we can weigh the options together using these criteria, starting from a POC if needed. Contact us and let’s talk.
