Backend
Node.js by default, Python or Go where they fit better.
Different problems want different runtimes. Most of our backend work is TypeScript on Node.js because it shares a type system and a hiring market with the frontend. For data-heavy or scientific workloads we use Python (Django for full-fat apps, FastAPI for typed services). For high-throughput, low-latency, or operational tooling we use Go.
Whatever the runtime, the principles are the same: contract-first APIs, observability from day one, idempotent jobs, and a test suite sized to the risk.
Tools we reach for
Node.js
JavaScript runtime — our default for full-stack TypeScript apps.
Python / Django
Batteries-included framework for data-heavy or admin-heavy apps.
Python / FastAPI
Typed Python framework for fast, well-documented APIs.
Go
High-throughput, low-latency services and CLI tools.
REST
Default API style for partner-facing surfaces.
GraphQL
API style for rich first-party clients with complex query needs.
When we reach for it
- Full-stack TypeScript apps (Node.js)
- Data-heavy or analytics-heavy apps (Python)
- High-throughput services or workers (Go)
- Public APIs (REST or GraphQL depending on consumer)
When we don't
- JVM-only environments unless your team is JVM-native
- Niche runtimes with thin hiring markets
Frequently asked
How do you decide between Node, Python, and Go?
Workload first. Full-stack typed app — Node. Data, ML, scientific, or large Python ecosystem reach — Python. High-throughput, low-latency, or systems-style work — Go. Hiring market second.
Do you use serverless?
Yes, for the right workload — event-driven jobs, scheduled functions, glue between systems. We do not put primary application logic on serverless unless cold starts are acceptable.
Microservices or monolith?
Monolith first for almost everything. We split into services only when a clear boundary justifies the operational cost.
Need a team that ships in this stack?
Tell us the workflow. A one-page summary back within 48 hours and a proposal within a week.