Technology

Technology as a way to reduce risk, not a list of trendy tools.

The stack serves the system, not the other way around. We choose tools we can run in production: typed languages, tested code, clean APIs and real observability. We fit the architecture to the business problem and surface the important tradeoffs early - before the build gets expensive.

Stack

Tools we can run

We work with TypeScript, Ruby, Elixir, Go, PostgreSQL, Redis, GraphQL and REST, on Docker, Terraform and CI/CD. The exact stack follows the system, but every choice has to be something we can also run once it's live.

Standards

Tested, observable, ready to release

Code under test, clean boundaries between services and observability from day one. Deployment, monitoring and documentation are part of the work, and senior review keeps quality where production needs it.

Architecture

Decisions that lower the cost of change

Architecture should reduce risk and make change easier, not decorate diagrams. We surface tradeoffs early, expose clean APIs and integration boundaries, and fit them to real constraints rather than fashion.
  • Typed, tested code
  • Clean APIs and boundaries
  • Infrastructure as code
  • Observability and monitoring
  • Senior review

Technical calm

Technology decisions should make a system easier to live with.

A stack only makes sense if it can be understood, tested, maintained and changed. We want a system to be readable after launch, not just quick to build - because that's what decides how much every later change costs.

Readable architecture

Boundaries, dependencies and tradeoffs are named in plain language, not buried in implementation detail.

Production habits

Testing, monitoring, deployment and failure handling are part of the build, not an afterthought.

Room to change

We prefer systems that can evolve without every new idea becoming a rewrite.

AI speeds up repetitive work. Architecture, security, review and production responsibility stay a matter of senior judgment.

The stack we run

Not decorative logos - tools we actually take to production.

Each of these technologies has a concrete use. We pick them to fit the shape of the problem, not the other way around - and we stay with them through maintenance, not just the build.