Technology and standards

The stack we trust, and the standards we hold.

We do not chase tools. We pick the ones that have survived real traffic and real on-call, then hold them to standards that make a system safe to change at 3am. This is what we reach for, and why.

How we choose

Proven first. Novel only when it earns its place.

Every tool in a production system is something a human has to understand, patch, and debug under pressure. So our default is proven technology with a long operational record and a large pool of engineers who already know it. We optimize for operability and for the person carrying the pager, not for a resume or a conference talk.

New tools do get adopted, but they have to earn it. That means a concrete problem the current stack cannot solve, a clear operational story, and a way back out if it disappoints. We would rather run a slightly boring system that everyone can reason about than a clever one that only its author can keep alive.

How we run an engagement

Selection criteria

  • Operational track recordYears in production at scale, not a promising benchmark.
  • A team that can run itEnough engineers know it that you are not locked to one person.
  • Debuggable under loadClear failure modes and real observability, not a black box.
  • A way outWe avoid tools that trap your data or your architecture.

The stack

What we reach for, by layer.

These are the defaults across most engagements. We adjust to your existing platform and constraints, but this is the ground we know deeply and can support in production from day one.

Languages

Go and Rust for services that must hold their latency budget, TypeScript at the edges and in the browser, Python where data and model work lives. We match the language to the failure mode, not to fashion.

Go Rust TypeScript Python

Data

PostgreSQL is the default system of record until it stops fitting. Kafka carries events between services, ClickHouse answers analytical questions in milliseconds, and Redis takes the load off the hot path.

PostgreSQL Kafka ClickHouse Redis

Infrastructure

Kubernetes for workloads that need it, described entirely in Terraform so environments are reproducible and auditable. We run on AWS and GCP, and we keep the platform portable enough that neither one owns you.

Kubernetes Terraform AWS GCP

Observability

OpenTelemetry instrumentation from the first commit, feeding Prometheus for metrics, Grafana for dashboards and alerts, and Loki for logs. When something breaks, the answer is already on a graph.

OpenTelemetry Prometheus Grafana Loki

AI

We serve models with Triton and vLLM for throughput that holds under concurrency, train and fine-tune with PyTorch, and orchestrate multi-step agent flows with LangGraph behind guardrails you can measure.

Triton PyTorch vLLM LangGraph

Engineering standards

The bar every system clears before it ships.

Tools change from project to project. These practices do not. They are what keep a system safe to change once it is carrying real traffic, and they are baked into how we build rather than bolted on before a launch.

Coverage target80% on core logic
Deploy modelProgressive delivery
InstrumentationOn by default
RunbooksWritten, not assumed
  • Tested where it mattersA coverage target of 80% on core business logic, with the critical paths under integration and load tests, not just unit tests that assert nothing.
  • CI/CD with progressive deliveryEvery change flows through automated pipelines and reaches production behind canaries and feature flags, with an error-budget check that rolls back on its own.
  • Security and least privilegeSecrets managed, dependencies scanned, and every service granted only the access it needs. Least privilege is the default, not an audit finding.
  • Observability by defaultTraces, metrics, and logs are wired in from the first commit, so a production question has an answer on a dashboard rather than in a debugger.
  • Documented runbooksEvery service ships with a runbook covering how it fails, how to tell, and what to do about it, so on-call is a checklist and not a scramble.

Defaults and exceptions

What we start with, and when we deviate.

A default is a starting point that is right most of the time. Here is where we begin on the decisions that shape a system, and the specific pressure that makes us pick something else.

Decision Our default When we reach for something else
Primary datastore PostgreSQL for the system of record ClickHouse when analytical queries dominate, a key-value store when access is purely by key at extreme scale.
Messaging Kafka for durable event streams A lighter queue such as NATS when ordering and replay are not needed and operational weight matters more.
Deploys Progressive delivery on Kubernetes A managed serverless target for spiky, low-traffic workloads where running a cluster is not worth the overhead.
Language Go for most services Rust when the latency or memory budget is tight, Python when the work is mostly data and model code.
They talked us out of a trendy database we were set on and onto Postgres. Two years in, that call is why the platform is still boring to operate.
SR
Sofia Reinhardt
CTO, Helio Energy

Start

Want this stack behind your product?

Tell us what you are building and the constraints you are under. We will tell you which of these tools fit, and where your problem needs something different.

Start a project See capabilities