Technologies
A short list of tools we know well.
Choosing a stack is a business decision as much as a technical one. It decides what hiring costs and how hard the system is to change, and you live with it for years. This is what we build with, and the reasoning behind each choice.
How we choose
Four rules that settle most of the decisions.
- 01
Boring by default
We pick tools that are easy to hire for, will still be supported in a few years and behave under load the way they do in a demo. Anything newer has to earn its place on the project in front of us.
- 02
We keep the list short
We know a short list of tools properly, which is worth more to you than a long list we've touched once. If your estate needs something outside it, we'll bring in a specialist instead of improvising.
- 03
Fit the estate you have
If your organisation runs on Microsoft, we'll build in .NET on Azure. If your team knows Vue, we build in Vue. What you can maintain after we've gone matters more than what we'd pick for ourselves.
- 04
Infrastructure as code, and monitoring on every system
Infrastructure, pipelines and environments live in a repository, so changes are reviewed and can be rolled back. Every system ships with metrics, traces and alerts someone on call can act on.
The stack
What we build with, and when.
Frontend
Interfaces that stay quick to use, and to change, as the product grows.
- TypeScript
- The default for everything we write, front end and back.
- React
- Our pick for interfaces that will be worked on for years.
- Next.js
- Server rendering, routing and edge delivery for most of the web products we build.
- Tailwind CSS
- Styling driven by design tokens, so several teams can work on one UI without it drifting.
- Vue / Nuxt
- If your team already writes Vue, we'll write Vue.
Backend & APIs
Services with clear contracts and enough logging to tell what they're doing.
- Node.js
- APIs and services that share types with the front end.
- Python
- Data pipelines, automation and anything near machine learning.
- .NET / C#
- Enterprise back ends, and estates that are mostly Windows.
- Go
- Services that take a lot of traffic, and infrastructure tools.
- GraphQL
- One graph over several back ends, when that's what the front end needs.
- REST / OpenAPI
- APIs designed contract first, with clients and docs generated from the spec.
Mobile
Cross-platform by default, native when the app needs it.
- React Native
- One codebase for iOS and Android, dropping to native where performance needs it.
- Expo
- Managed builds, over-the-air updates and getting into the app stores.
- Swift
- Native iOS when the app needs something only the platform can do.
- Kotlin
- Native Android, for the same reason.
Cloud & DevOps
Infrastructure as code and automated deployments, with a bill that makes sense.
- AWS
- Our default cloud for regulated and enterprise work.
- Google Cloud
- Data-heavy platforms and analytics built around BigQuery.
- Azure
- Organisations already on Microsoft, and .NET estates.
- Vercel
- Hosting for Next.js front ends with no servers for anyone to run.
- Docker
- The same build on a laptop as in production.
- Kubernetes
- Only when the workload is big enough to justify running it.
- Terraform
- Infrastructure written as code, reviewed and versioned like the rest.
- GitHub Actions
- CI/CD, with a preview environment for every pull request.
Data
Storage, streaming and analytics that keep working when the volume goes up.
- PostgreSQL
- The database we use unless there's a specific reason not to.
- Redis
- Caching, job queues and rate limiting.
- Kafka
- Moving events between systems when there are a lot of them.
- Elasticsearch
- Full-text search and log analytics.
- dbt
- Analytics models written in SQL, with tests and documentation.
AI & Automation
LLM and ML features that are tested properly before anyone relies on them.
- OpenAI / Anthropic APIs
- LLM features, with evaluation, guardrails and a cap on the bill.
- LangChain / LlamaIndex
- Retrieval over a company's own documents and data.
- pgvector
- Vector search inside Postgres, so there's no extra database to run.
Quality & Observability
Testing, monitoring and design tools that are part of every project.
- Playwright
- Browser tests that run in CI on every change.
- Storybook
- Component documentation the designers use too.
- Sentry
- Error tracking, tied to each release.
- Grafana / OpenTelemetry
- Metrics, traces and alerting for everything we run in production.
- Figma
- Where the design system lives, linked to the code.
Something else in your estate?
Ask, and we'll tell you straight whether it's a fit.
If your systems run on something that isn't listed here, tell us anyway. We integrate with Java, PHP, Ruby, VB6, Access and mainframe estates on a regular basis, and now and then we help a client move off one of them altogether.