Skip to main content

Technology stack

What we work with, and how we choose

A stack list is only useful with the reasoning attached, so each group below says how we decide. We are deliberately not a single-platform shop: the right answer depends on what your team can operate after we leave.

  • Languages and runtimes

    Chosen per problem. A long-lived business system and a data pipeline rarely want the same language.

    • TypeScript / JavaScript
    • Python
    • PHP 8
    • Java
    • C# / .NET
    • Go
    • SQL

  • Application and interface

    Server-rendered where the content is public, client-rendered where the interaction is genuinely stateful.

    • React
    • Node.js
    • Next.js
    • REST
    • GraphQL
    • OpenAPI
    • WebSockets

  • Data

    Relational by default. We move to something else when the access pattern actually demands it, not because it is fashionable.

    • PostgreSQL
    • MySQL / MariaDB
    • Redis
    • Elasticsearch
    • Object storage
    • Message queues

  • Platform and infrastructure

    Infrastructure as code from the first environment, so staging and production cannot silently diverge.

    • Docker
    • Kubernetes
    • Terraform
    • AWS
    • Microsoft Azure
    • Google Cloud
    • Linux
    • nginx

  • Delivery and operations

    A pipeline that anyone on the team can read, and observability that answers questions during an incident.

    • GitHub Actions
    • GitLab CI
    • Automated testing
    • Structured logging
    • Metrics and tracing
    • Blue/green and rollback

  • Security

    Built into the system rather than added at the end, and evidenced where an obligation requires it.

    • OAuth 2.0 / OIDC
    • SAML
    • Secret management
    • TLS and key rotation
    • SAST / DAST in CI
    • SBOM and dependency scanning

Selection

How a technology gets chosen for your project

  1. 01What must it do under load?Throughput, latency and failure behaviour set hard limits long before preference does.
  2. 02Who operates it afterwards?If your team runs it, it has to be something they can run. A technically superior choice your staff cannot support is the wrong choice.
  3. 03What is already there?Most work joins an existing estate. Consistency with what you already operate usually beats a marginally better tool.
  4. 04What does it cost to leave?We prefer technologies with a credible exit. Anything that would lock you in gets flagged explicitly before it is adopted.
  5. 05Is it still maintained?Licence, release cadence and the size of the maintainer pool are part of the assessment, not an afterthought.

Trademarks

A word about the names on this page

Platform and product names on this site (AWS, Microsoft Azure, Google Cloud, Kubernetes, PostgreSQL and others) identify the technologies our engineers build on. They are the trademarks of their respective owners. 3S holding OÜ is an independent software-engineering company and is not an agent, reseller, support provider or authorised representative of any of them, and this site does not offer support for their products.

In practice this means: we will architect and build a system that runs on a given cloud platform, and we will not represent ourselves as that platform’s support desk, reseller or certified partner unless and until we actually hold that status and can evidence it. We hold no such status today, and no partner badge appears anywhere on this site.