<Let's Talk/>
Tech 6 min read

Our stack in 2026: what we use and why

From frontend to deployment — an honest breakdown of the tools we actually ship with, and the ones we tried and abandoned.

Stack principles

We do not chase trends. When a new framework releases, we give it six months before we consider using it in client work. By then, the rough edges are documented, the community has found the footguns, and we can make an informed decision instead of a hopeful one.

  1. Can a team member debug it at midnight without documentation?
  2. Does it have predictable failure modes?
  3. Will it still exist in three years?
Multiple monitors showing code editors and terminal windows in a dark development environment
The tools that earn a place on this list have been debugged at midnight at least once.
Code on a screen — dark theme editor with syntax highlighting
TypeScript: every project, from day one.
Servers and infrastructure equipment in a data centre
Infra stack: Vercel, Railway, Supabase.
Developer writing code on a laptop with multiple browser tabs open
Next.js 14 App Router in production.

Frontend

Next.js 14Daily driver

App Router is stable enough for production. We default to Server Components and only reach for Client Components when we need interactivity.

TypeScriptDaily driver

Not optional. Every project, from day one. The overhead is real for the first week and invisible after that.

GSAPDaily driver

For scroll-driven animations and complex sequences, nothing else comes close. We use it for our own site and for client marketing pages.

Backend

Node.js + FastifyDaily driver

Fastify replaced Express for us in 2024. The plugin system is cleaner, the performance is better, and the schema validation with Zod makes API contracts explicit from day one.

PostgreSQLDaily driver

We have not found a problem Postgres cannot solve. We reach for Supabase for managed hosting on most projects.

RedisWhen needed

Session storage, rate limiting, queue backing. We do not reach for it by default — only when there is a clear need.

Infrastructure

infra.yml
hosting:
  frontend: Vercel        # zero-config deploys
  backend:  Railway       # simple, predictable pricing
  db:       Supabase      # managed Postgres + auth

monitoring:
  errors:   Sentry
  logs:     Axiom
  uptime:   Better Uptime

ci_cd:
  provider: GitHub Actions
  deploys:  on push to main (staging), tag (production)

What we left behind

GraphQLRetired

Powerful, but the operational overhead was not worth it for most of the products we build. REST with OpenAPI specs gives us 90% of the benefit at 20% of the cost.

PrismaRetired

We loved the DX. We did not love the performance under load or the migration story. We moved to Drizzle ORM.

The stack evolves. This post reflects what we are using today. If something better earns a place, we will update it.

Next post
Company

Year one: what building Aildco taught us