We try to stick to a single language. We use Typescript for everything. We know many more, but regardless we’ll do everything with Typescript where it is good enough.

For Web and Mobile. We continue to assess other options as serious ones pop up, but nothing much better, and its ecosystem has ever shown up.

We'll use NodeJS as a default choice for backends. We keep one eye on Deno; and another on Bun. We may use those but basic Node remains our standard choice.

We use this for websites. It has the needed features like SSR, SSG, ISG, and a routing architecture which is a perfect fit for websites. No need to poke around with the build.

An ORM with excellent developer experience. It doesn’t abstract too much, produces efficient queries, and provides strict typing for all DB access alongside solid migrations. We’ve used it extensively against Postgres, but Drizzle now has the upper hand and is our default for new projects.

Databases come and go, except Postgres, it always stays because it is solid and extensible for most use cases.

Great for Caching and Queueing. Sometimes as a message bus.

It’s easy to pick up. It has very little abstraction. It produces CSS as external style sheets which are important for Website projects.

ShadCN is a collection of accessible and customizable React components built with Tailwind CSS, offering a foundation for building modern, consistent UI designs.

It served us well for Web Apps, but we’ve settled on Tailwind + ShadCN, which give us less abstraction and easier customisation. We would not start a new project on Chakra.

Similar to Heroku, moderately priced, and it handles the boring ops work that repeats itself in every project. Lets us stand up scalable web apps with Postgres + Redis — production and staging environments, automatic deployments and distributed logging — in a few hours. We now prefer Digital Ocean Apps for its more lenient pricing, and Render still lacks object storage, which is a big gap for us.

Serverless deployment platform. Great for websites when paired with NextJS. Global CDN. Automated website performance monitoring built in.

UX/Design tool of choice. Good for communicating ideas.

Used along with Cursor and Claude Code. This is a fast developing space and the preferred AI coding tools may change every other week.

One of the AI coding tools preferred along with Codex and Cursor.

One of the AI coding tools preferred along with Claude Code and Codex.

We'll use React Native as the default choice for mobile apps. It keeps us in TypeScript and close to the React stack we already use on the web. We still reach for Swift or Kotlin when an app should be fully native, but React Native remains our standard choice.

Headless CMS with a Visual Editor. It’s extensible enough for most our use cases in websites and has among the best user experiences for content editors.

Pairing Sanity with Shopify projects is a great choice because of their excellent integration.

Modern, react-oriented, and battle-tested in our production-grade projects animation framework. Creating a bit more complicated animations with this tool feels like a breeze ;-)

We’ve trialed Remix and Next.js remains our preferred option. Given the amount of API churn and the project’s shifting direction, we do not consider it a stable choice for new projects.

We usually don’t have a need to muck about with build tools since we always base our projects on frameworks that make the build tool choice for us, but Vite is on the radar when it’s not an option.

Our default choice when we need full programmatic control of anything webgl/3d. We do not use this often enough though so it's mostly been employed in minor one-off cases.

Super fast all-in-one Javascript runtime. We can use it but currently the advantages aren't enough to dethrone NodeJS as the default choice in client projects.

Currently our go-to for full-stack apps. We prefer to architect our apps as single full-stack deployables with back- and frontend in the same codebase when it makes sense, which is almost always in our projects, and T3 is a very good fit.

A solid alternative to Next.js and a strong choice alongside our T3 stack for building full-stack React applications. TanStack Start aligns well with our preference for keeping the frontend and backend in a single codebase and deployable. We particularly like its type-safe routing, server functions, and relatively unopinionated approach, giving us more control over the architecture without sacrificing developer experience.

Convex currently offers the best AI-boosted development experience we’ve found. Coding agents can deliver a full-stack React app on Convex out of the box without MCP servers, which makes it a very compelling platform for delivering end-to-end web apps as fast as possible.

Keeping our eye on this if we’d get a specific use case, but its ecosystem is too minimal, nor does its advantages bring enough value considering its disadvantages in comparison to React.

We’ve trialed VueJS and deduced there is no reason to use it over React. For our engineers and projects, it’s worse in all regards.

We’ve trialed this when the use case seemed to be a fit. We find it has too many rough edges and it diverges too much from our core JS foundation.

We rarely need pure backend frameworks. If we did, we’d explore other options before trialing NestJS again. E.g. Moleculer, AdonisJS, or just plain express.

Many PaaS providers have per-developer pricing which rubs us and our clients the wrong way. Digital Ocean has a wide feature set and decent pricing; without the unreasonable per-developer pricing model.

We find Astro to be superior in certain use-cases, particularly when content is crucial and optimal performance is needed to satisfy SEO gods.

Drizzle ORM is a lightweight, TypeScript-first Object-Relational Mapping library designed for simplicity, type safety, and seamless integration with modern JavaScript and SQL workflows.

Payload CMS is a NextJS process-hosted, TypeScript-based headless content management system that offers extensive customization, robust APIs, and a developer-friendly experience. We've actively trialed it, but are a bit cautious after the acquisition by Figma.

When the work sits on the JVM, Java is the language we start from. It remains our baseline for long-lived backend services and for codebases that are already Java.

Our preferred JVM language when we want Java interoperability without the ceremony. We use it for backend services that live next to Java and Spring.

The application framework we use for JVM services. It gives us a production-ready shape for HTTP APIs, data access, and the operational pieces around them.

A Kotlin-native HTTP framework for JVM services that should stay small. We use it when a service does not need the full Spring stack.

A strong fit for small, fast services and infrastructure tooling. We use it when a backend should be a single binary with straightforward concurrency.

We use Python where its ecosystem is the advantage: data processing, integrations, automation, and services built around those libraries.

Our default way to build and ship React Native apps. It takes care of the native project, builds, and updates so the work stays in the JavaScript workflow.

When an app should be native on Apple platforms, Swift is the language. We use it for iOS work that should not go through React Native.

Our UI toolkit for native Apple apps. We build Swift interfaces in SwiftUI and drop down only where a screen needs something SwiftUI does not cover.

The native choice for Android. We use Kotlin with the Android SDK when an app should be Android-first rather than shared through React Native.

The cloud we reach for when a system needs AWS’s range of compute, data, and managed services. We start with the simplest fit, from Lambda and Fargate through to EKS when Kubernetes earns the operational cost.

A default cloud alongside AWS when the workload or the client’s estate is on Google Cloud. Cloud Run, Cloud Functions, and GKE cover the same ground we use on AWS.

We can operate Azure when a client is already there, including Functions, Container Apps, and AKS. We would not start a new platform on Azure.