# Tech stack A tool is a means. What a client buys is the judgement that picks the right one and the discipline to run it well — but you asked what we work with, so here it is, and every line of it is backed by work in [the portfolio](/portfolio/). ## Languages and runtimes **Python** for data work, automation and services. **Go** where a single static binary and low overhead matter. **TypeScript** and modern JavaScript on the web tier. **SQL** as a first-class language rather than something an ORM generates — most of the performance work we are called in for lives there. **Bash** for the glue, written to be read. ## Data **PostgreSQL** is the default, and we go a long way with it before reaching for anything else — partitioning, replication, extensions and the query planner. We also run **MS SQL Server**, **BigQuery**, **SQLite** and **Redis**, and the spatial stack on top: **PostGIS**, **QGIS**, **GDAL** and **ArcGIS**. Pipelines are built to be re-runnable and idempotent, because the question after an incident is always "can we replay it". ## Cloud and infrastructure **Google Cloud** and **AWS**, with **Azure** where the client already lives there. **Linux** underneath everything — Debian and Ubuntu. **Docker** and **Kubernetes** for the workloads that earn them, and plain systemd units for the ones that do not. **Ansible** and **Terraform** describe the machines, so an environment is a document rather than an archaeology project. **Caddy** and **nginx** at the front. ## Running it in production **Prometheus** and **Grafana** for metrics, structured logging for the rest, and alerts that fire on symptoms a user would notice rather than on every twitch of a graph. CI pipelines that build, test, scan and deploy without a person in the loop. Backups taken, and restores tested. ## The web tier Static-first where it fits, because a page that is a file is a page that cannot fall over: **Hugo** builds this site. **Django** and **PHP** where there is an application to serve. Semantic HTML, hand-written CSS, and accessibility treated as a requirement rather than an audit finding. ## How we choose Boring technology, chosen deliberately, beats novel technology chosen by default. We pick for the problem, for what your team can operate after we leave, and for how the thing fails rather than how it demonstrates. When the right answer is the stack you already have, we say so — and when it is not, we say that too, with the reasoning written down. This site is its own worked example: the [credits page](/credits/) names every piece of technology behind it, down to the typeface and the backup tool. If you would rather have a supplier with opinions than one with a preference list, [tell us what you are building](/contact/) *(and we will argue for them)*.