Skip to main content

Technology

Technology we build with

We pick the boring, proven tool unless there is a specific reason not to. A stack you can still hire for in five years matters more than one that is exciting this quarter: you inherit the maintenance, not us.

Below is what we work in most. If your stack is not listed, ask: the list reflects what clients run, not the limit of what we will work on.

Our stack

What we build with

Grouped by layer, with a note on when each one earns its place.

Frontend

Component-driven interfaces with server rendering where SEO or first-load performance matters.

  • React
  • Next.js
  • TypeScript
  • Tailwind CSS
  • React Native
  • Flutter

Backend

Long-lived server platforms chosen to match your team's existing skills wherever possible.

  • .NET
  • Node.js
  • Java
  • Python
  • Go
  • FastAPI

Cloud & DevOps

Infrastructure as code, reproducible environments and pipelines that deploy on merge.

  • AWS
  • Azure
  • Google Cloud
  • Kubernetes
  • Terraform
  • Docker
  • GitHub Actions

Data

Warehouses and pipelines with tested, version-controlled metric definitions.

  • Snowflake
  • Databricks
  • BigQuery
  • PostgreSQL
  • SQL Server
  • dbt
  • Airflow
  • Kafka

AI

Retrieval, evaluation and human-in-the-loop review around frontier and self-hosted models.

  • Claude
  • OpenAI
  • LangChain
  • pgvector
  • Pinecone

Quality & Observability

Automated testing and production visibility, treated as delivery scope rather than an extra.

  • Playwright
  • Jest
  • xUnit
  • pytest
  • Prometheus
  • Grafana
  • OpenTelemetry

Selection criteria

How we choose between them

Technology choices outlive the people who make them. These are the tie-breakers we apply.

Managed over self-hosted

We run a database or a cluster yourself only when there is a cost, latency or compliance reason. Undifferentiated operations work is not a good use of your budget.

Your team's stack wins ties

Where two options are close, we pick the one your engineers already know. Handover is part of the design.

No framework of the month

New dependencies need a reason beyond novelty, and anything load-bearing has to have a maintained release history.

Working in a stack we have not listed?

Ask. The list reflects what our clients run, not the limit of what we will work on, and we would rather tell you we are not the right fit than learn your platform on your budget.