Tech stack
The technologies Engineer ApS builds with: languages, data platforms, cloud and infrastructure, and how we decide what to use.
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.
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 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.
