The tools, and
why we use them.
An honest list of what we reach for, plus some opinions about why. We'd rather use a boring tool that works than a clever one that doesn't.
How we choose
what we use.
Three principles we come back to whenever we're tempted to add a new tool to the stack.
Boring beats clever.
We default to tools that have been battle-tested in production by thousands of teams. PostgreSQL over the database-of-the-month. Python over the language with the best benchmarks. The interesting part of the system should be what we build with the tools, not the tools themselves.
Use one good tool, not three okay ones.
Most projects suffer from too many moving parts, not too few. We'd rather lean hard on PostgreSQL's full-text search than add Elasticsearch. We'd rather use Celery for everything async than mix it with three other queue systems. Fewer pieces means fewer things to break.
Models are commodities. The system isn't.
The model you use will be replaced in eighteen months. The pipeline around it — the data work, the evaluation harness, the retry logic, the monitoring — is what actually determines whether it works. We treat model choice as a swappable component, not a foundation.
The list,
by category.
Not a religion. We pick tools because they fit the problem in front of us, and we change our minds when better options show up.
Claude API · Neo4j · Python · scikit-learn · PyTorch · LangChain
Django / DRF · PostgreSQL · Celery · Redis
React · Next.js · Tailwind CSS
AWS · Docker · GitHub Actions · Nginx
The model you use will be replaced in eighteen months. The pipeline around it is what determines whether the system works.
That's fine.
We'll work in yours.
This list is what we reach for when starting from scratch. If you already have a working stack and just need someone who can build inside it, we're happy to do that too.
Get in touch→