Our tech stack
What we build with, and why each thing earned its place.
Every tool here has to justify itself on two counts: does it make the site better for your visitors, and can somebody else maintain it after us.
Choosing tools is mostly about who has to live with them. A framework that saves us a week and costs you a developer who can maintain it in three years is a bad trade, and we have made it before.
So the list below is not the newest possible stack. It is the one where the tools are fast, widely known, well documented, and likely to still be here when you need a change made.
We also change our minds. WordPress was the right answer for years and still is for some projects. Bun replaced part of what Node.js did for us because it measurably shortened every build. Neither of those was a matter of principle.
Next.js
Server rendering, routing, image handling and caching in one framework, so the parts that decide speed are designed to work together rather than bolted to each other.
Bun
Installs and starts markedly faster than the alternatives, which shortens every build and every local run. We use it for new services and for tooling on every project.
Node.js
The safe default when a library or a hosting environment expects it, and still what most of the ecosystem is tested against. Nothing is lost by using it.
React
A large pool of developers who can read the code after us, which matters more for your long term costs than any technical argument about frameworks.
TypeScript
Catches the mistakes that would otherwise become a support call. Renaming a field breaks the build instead of silently breaking a page in production.
Tailwind CSS
Styling that lives with the markup and cannot drift into an unused stylesheet nobody dares delete. The shipped CSS stays small because unused rules never get built.
PostgreSQL
Dependable, well understood, and it handles far more load than most businesses will ever need. We reach for something else only with a reason.
Vercel and AWS
Vercel for the smoothest Next.js deployments, AWS or a plain server where you need more control or already have infrastructure. Your account either way.
Honest limits
When we would tell you to use something else.
A studio that recommends the same stack for every project is describing its own convenience, not your requirement.
When we would still use WordPress
A site that is mostly articles and pages, edited by people who already know the admin screen, with no custom logic behind it. WordPress does that well and there is no reason to charge you for something more complicated.
When we would use plain HTML
A handful of pages that rarely change and have no forms. It will be the fastest thing on the internet and it will cost you almost nothing to host. We have recommended this and lost the larger project by doing it.
When we would not use Bun
When a project depends on a package with native bindings that only supports Node.js, or when your hosting environment expects Node.js and cannot be changed. Node.js is not a compromise, it is the default the whole ecosystem tests against.
When we would build native rather than a web app
Deep hardware access, background location, or a genuine commercial need to be in the app stores. For booking, ordering, tracking and account access, a progressive web app does the same job for a fraction of the cost.
Why we avoid heavy 3D on marketing pages
A WebGL scene can cost a second of blocking time on a mid range phone, and crawlers and audit tools often cannot render it at all. Where a page needs motion, vector illustration and CSS give most of the effect at a tiny fraction of the cost. Everything animated on this site is drawn that way.
How we decide about a new tool
Three questions. Does it measurably improve something you would notice. Can another developer pick it up. Will it still be maintained in three years. Two out of three is not enough.
This site is the working example.
Next.js 16, React 19, Tailwind v4, built and installed with Bun. Every illustration is inline vector art with CSS animation, so there is no image request and no JavaScript on the path to first paint. Run it through PageSpeed and see.