The stack we work in
We are deliberately narrow. A team that claims twenty languages is a team that is learning one of them on your project. Anything not on this list we will either learn on our own time or tell you to hire someone else.
- TypeScript
- Python
- Go
- Kotlin
- Swift
- SQL
TypeScript on both sides of most web products, so one engineer can follow a feature from the database to the screen. Python where the data and model libraries live, Go for services that must be small and fast, Swift and Kotlin for native apps.
- React
- Next.js
- Vue
- Tailwind CSS
- Vite
- Playwright
React and Next.js by default, because your team can hire for them after handover. Vue when your product already uses it. Playwright for end-to-end tests that run on every change.
- Node.js
- FastAPI
- NestJS
- GraphQL
- gRPC
- REST
Node.js or FastAPI, depending on where the rest of the product lives. REST for most integrations, GraphQL when many clients read the same data in different shapes, gRPC between internal services.
- PostgreSQL
- Redis
- ClickHouse
- Elasticsearch
- Kafka
- dbt
PostgreSQL first and usually last: most products never outgrow it. Redis for queues and caching, ClickHouse when analytics would slow the main database, Kafka only when events really have to be replayed.
- AWS
- Google Cloud
- Docker
- Kubernetes
- Terraform
- GitHub Actions
AWS or Google Cloud in your own account, never ours, so the infrastructure is yours from day one. Everything is described in Terraform and deployed from CI, which is what makes a clean handover possible.
- OpenAI
- Anthropic
- Gemini
- pgvector
- LangGraph
- PyTorch
Hosted models from more than one provider behind one interface, so a price change or an outage is a configuration change rather than a rewrite. pgvector keeps retrieval next to data you already back up.
- Swift / SwiftUI
- Kotlin / Compose
- React Native
- Expo
Native Swift and Kotlin when the app depends on device features or performance. React Native with Expo when one team has to ship iOS and Android and share logic with the web.
- Figma
- Storybook
- Linear
- Sentry
- Grafana
- OpenTelemetry
Figma and Storybook, so design and code describe the same components. Sentry, Grafana and OpenTelemetry, so a problem shows up on a dashboard before it shows up in a support ticket.
If your product already runs on something else, we work in your stack. A rewrite is a decision with a business case, not a preference.
How we choose for a new project
What your team can maintain after we leave matters more than what is fashionable. A stack nobody on your side can hire for is a dependency on us, and we would rather not sell you one.
If the product already runs on something that works, we keep it. A rewrite is recommended only with a written business case: what it costs, what it saves and when it pays back.
A tool we have not run in production is named as a risk in the discovery document, not learned quietly on your budget.
Tell us what you are building
A short description is enough to start. We reply with questions, a range and the two or three things that would change it.