A boring stack, in the good sense of the word
We pick technology to fit the project, not the trend and not whatever we feel like learning.
A system meant to run for five years needs tools that will still have people to hire for five years from now.
Frontend
- TypeScript
- Vue
- Nuxt
- React
- React Native
- Flutter
TypeScript everywhere, no exceptions — an error caught by the compiler is two orders of magnitude cheaper than the same error found by a user.
More
Vue and Nuxt as the default for new projects: server rendering, routing and image optimisation work out of the box, without assembling a framework from five libraries. React where the client's team already knows it or the existing code is written in it.
Backend
- Node.js
- PHP
- PostgreSQL
- Redis
Node.js as the default runtime, because one language on both sides genuinely shortens the time it takes to get into a project.
More
PHP when we take over an existing system or integrate with one we are not rewriting. PostgreSQL for anything with structure that has to stay consistent; Redis for queues, sessions and whatever can be lost on restart.
Infrastructure
- Vercel
- Google Cloud
- Docker
- GitHub Actions
Accounts opened in your name, not ours — the only configuration in which changing vendor doesn't mean a migration.
More
Vercel for web applications and sites, Google Cloud for systems with their own backend and data that has to stay in a specific place. Docker so the local and production environments are the same environment. GitHub Actions for tests and deploys — a deployment should be boring and repeatable.
AI
- language models
- semantic search
- document extraction
Language models deployed where they shorten specific work, not where they look good in a demo.
More
Semantic search for internal knowledge nobody can find with a keyword search. Document extraction where somebody currently retypes data out of PDFs into a system. Each of these has a measurable effect — and if it can't be measured, we advise against the rollout.
In depth
How we choose
Three questions, in this order. Does this technology solve a problem we actually have? In three years, will we be able to find someone who knows it? Can it be replaced if it turns out to be a dead end?
A technology that only passes the first question is a risk transferred to the client. Most of the spectacular delivery failures we have watched from the sidelines began with picking a tool that five people in the region use.
What we don't use
We don't build on a proprietary, closed engine — it is the most effective lock-in mechanism we know of, which is why we don't have one. We don't put technology that hasn't left experimental status into a system meant to run in production. We don't rewrite working code onto a newer framework merely because it is newer.
What this means for you
The repository, the economic rights and every infrastructure account are yours from day one. Documentation and tests are written so another team can take the system over without our involvement. That isn't goodwill — it is the condition that makes the choice of vendor reversible.
Got an idea? Let's talk.
The first call is free. We reply within one business day.