Experience
What the user sees and touches.
Technologies
The stack follows
from the problem.
We do not pick technology by fashion or by preference: we pick what your case justifies — and we explain why. This is the list of what we master and run in production.
01 How the stack is organized
Four layers, one request.
Every system we build has the same anatomy: the experience the user touches, the application that carries the rules, the data that has to outlive everything, and the operations that keep it all running. Technology belongs to one of those layers — never on its own.
Application
The rules that make the business work.
Data
The asset that has to outlive everything.
Operations
What keeps the system running.
02 What we use
Each tool, where it actually solves something.
This list describes what the company masters — not the stack of a specific product. Nowhere on this site do we attribute technology to an individual product: that information is not public.
01
Frontend
ExperienceThe layer the user touches. It is where performance and finish show — or fail to.
AngularReactNext.jsTypeScript
02
Mobile
ExperienceNative when the device capability demands it; cross-platform when the time saved is worth it.
FlutterReact NativeKotlinSwift
03
Backend
ApplicationWhere the business rules live. The choice here sets the cost of maintaining the system for years.
JavaSpring BootNode.jsPython
04
Integration and security
ApplicationThe contract between systems — and the control over who may do what.
REST APIOAuth2JWT
05
Artificial intelligence
ApplicationModels applied to a defined problem, with human review wherever an error is expensive.
OpenAIClaudeGemini
06
Data
DataThe asset that outlives any change of technology. Modelling before tooling.
PostgreSQLFirebaseMongoDBRedisOracleSQL Server
07
Messaging
DataSo a slow system does not take down the next one — and nothing is lost on the way.
KafkaRabbitMQ
08
Cloud and DevOps
OperationsInfrastructure sized for real usage, with cost under control.
AWSGoogle CloudAzureDockerKubernetes
09
Continuous delivery
OperationsShipping should be predictable routine, not a risk event.
GitHubGitHub ActionsCI/CDGitLab
03 The criterion
No technology gets in without justifying its own presence.
What makes a choice a good one
- It solves the problem with the fewest moving parts.
- It has a community, support and a future — it is not the personal bet of whoever wrote it.
- Someone can maintain the system two years from now without archaeology.
- The cost of running it fits the company's real budget.
What we rule out
- Technology adopted to pad a portfolio.
- A distributed architecture where a simple system would do.
- A dependency that locks the client to the vendor.
- Novelty with no migration path for when it is abandoned.
The technical decision comes before the code
Which stack does your
project actually call for?
Tell us the problem. We will say what to build, what to buy off the shelf and what simply not to do.