Tech stack — 16 tools
What we build with
A short list on purpose. Every tool here has a long support horizon and a deep hiring pool, because the real test of a stack is whether someone else can maintain it after we are gone.
02 tools
Language
One language across the stack, so types cross the network boundary instead of stopping at it.
TypeScript
The default for everything we write. A shared type between the API and the client catches an entire category of bug before it runs.
Python
Where the work is data or model-shaped and the ecosystem is genuinely better for it.
04 tools
Frontend
Rendered on the server where it matters, interactive where it earns it.
React
Boring in the best sense: the largest pool of engineers who can maintain what we leave behind.
Next.js
Server rendering, routing and the image pipeline in one place, so pages are fast on real devices without a bespoke build.
Tailwind CSS
Design tokens that live in the same file as the markup. Styles stop drifting from the design system.
One codebase for iOS and Android when a native shell is not the point of the product.
03 tools
Backend & data
The data model first. Most backend pain is a schema decision made too early.
Node.js
Same language as the client, so there is one mental model and one set of shared types.
PostgreSQL
Relational by default. Reach for something exotic only when the data genuinely is.
Caching, queues and rate limiting, where the alternative is abusing the database.
04 tools
Infrastructure
Environments defined as code and deploys that are boring on purpose. If shipping is scary, the roadmap is not real.
Docker
Local, staging and production that actually match, so 'works on my machine' stops being a sentence anyone says.
AWS
The default target. We deploy where you already are rather than moving you for our convenience.
Test, preview and deploy on every pull request. No manual production steps.
Infrastructure in version control, so an environment can be rebuilt from scratch rather than remembered.
03 tools
Design & quality
The parts that decide whether the thing is usable and whether it stays working.
Figma
Design in the same tokens and components the code uses, so approval and implementation are the same artifact.
End-to-end tests on the journeys that cost money when they break — not on a coverage percentage.
Errors from real users, with the context to act on them, rather than a support ticket describing a blank screen.
Selection
How we decide
The rules behind the list above, stated plainly so you can disagree with them before the project starts rather than after.
Boring beats new
We pick tools with long support horizons and deep hiring pools. You should be able to hire a maintainer after we are gone, and that gets much harder if we chose something fashionable.
Your stack wins over ours
If you already run something and run it well, we work in it. Tell us early — if it is something we cannot support properly we will say so rather than learn it on your budget.
Fewer moving parts
Every service added is another thing to monitor, patch and explain. We add one when the problem genuinely needs it, not because the architecture diagram looks better.
No lock-in to us
Infrastructure as code, standard hosting, your accounts. Nothing here requires our continued involvement to keep running.
Next
See it applied