React / Next.js
For interface work, routing, server rendering, and the overall application shape.
Uses
Tools I use to build and run web products.
The exact stack changes by project. These are the technologies I reach for most often and the parts of the product where I use them.
01 / FRONTEND
Frontend
Most application and product UI work starts here. Next.js handles routing and application structure, TypeScript keeps contracts explicit, and Tailwind is usually my styling layer.
TypeScript
For making component, API, and data contracts visible before they become production bugs.
Tailwind CSS
My usual styling layer when the project benefits from fast, consistent component-level work.
02 / BACKEND & DATA
Backend & data
Node.js and PostgreSQL cover a large part of my application work. The database layer depends on the product, the existing architecture, and how much control the project needs.
Node.js
Application logic, route handlers, integrations, background work, and services around the frontend.
PostgreSQL
The default relational database for products with structured data and relationships that need to stay dependable.
Drizzle
I use it when I want a thin, strongly typed SQL layer and clear visibility into the underlying database.
Prisma
Useful where its schema and workflow fit the application architecture or an existing codebase.
MongoDB
A project-specific choice for document-shaped data and systems already built around its model.
03 / CMS & CONTENT
CMS & content
I work on the full content path: modelling, localization, APIs, editor experience, and integrations. Payload and Strapi are choices made around project requirements, not competing defaults.
Payload / Strapi
For structured content systems, custom editorial workflows, localization, and application integrations.
GraphQL / REST
For exposing and connecting content or application data in the form the consuming product needs.
MDX
For content that should stay close to the codebase while still supporting rich, reusable presentation.
04 / DELIVERY & INFRASTRUCTURE
Delivery & infrastructure
Shipping is part of the product work. These tools cover deployment, reverse proxying, process management, CI/CD, and the DNS, CDN, and security edge around an application.
Docker
For repeatable application environments and packaging services with their operational requirements.
Nginx / PM2
For reverse proxying and process management where a directly managed server is the right delivery model.
GitHub Actions
For checks and deployment workflows that make releases repeatable rather than manual.
Cloudflare
For DNS, caching, delivery, and the security controls at the edge of a production application.
How I choose tools
Newer is not automatically better.
I start with the product and its constraints. A tool is useful when it fits the existing codebase, the people maintaining it, the data model, and the place it has to run—and when a production problem will still be understandable later.
existing codebaseteam familiaritydata modeldeployment environmentmaintenance costdebuggability
Need help shipping or untangling a web product?
I am most useful when the problem crosses layers: UI, API, database, CMS, deployment, or an existing codebase that has become difficult to change safely.