Stack

I'm opinionated about tooling. Every technology here was chosen after building something real with it, not from a tutorial, not from a blog post, but from hitting the edge cases and deciding it was still worth it.

This page reflects my current defaults. The right tool always depends on the problem, these are just the ones I trust most right now.

Languages

The languages I think in, ordered by fluency.

TypeScript

My primary language for everything that ships. I stopped writing plain JS the moment I experienced a refactor where the types caught what tests didn't. The overhead is zero once you stop fighting it.

JavaScript

The foundation. I understand it deeply enough to know exactly when TypeScript is saving me and when it's just ceremony.

C / C++

My primary language for DSA, where I focus on problem solving, algorithms, and writing efficient code with a strong grasp of fundamentals.

Python

My go-to for ML experimentation, scripting, and anything that needs to move fast without caring about the runtime.

SQL

Learned while working with databases; now mostly use ORMs like Prisma and Drizzle, but still understand what’s happening under the hood.

Bash

Enough to write CI scripts, Docker entrypoints, and glue code without reaching for Node.

Frontend

Next.js

My default for any serious frontend project. The App Router's server components model changed how I think about data fetching, pushing async work to the server and shipping only the minimum to the client. I've shipped production apps with ISR, dynamic routes, and edge middleware, and I still find things in the docs I haven't tried yet.

// Streaming RSC with Suspense - no client-side loading state needed
export default async function Page() {
  return (
    <Suspense fallback={<Skeleton />}>
      <UserDashboard data={fetchData()} />
    </Suspense>
  );
}

Backend

Node.js + Express

The runtime I know best for I/O-bound services. Express is boring in the best way, it does exactly what you ask and nothing else. I layer on Zod for runtime validation at every boundary, which eliminates an entire category of runtime errors.

Socket.IO

I built a real-time chess platform with 30+ WebSocket events, distributed game clocks, and horizontal scaling via the Redis adapter. Socket.IO's room abstraction, automatic reconnection handling, and reliable event delivery made the hard parts tractable. I've seen what rolling your own WebSocket layer looks like in production, and I prefer not to take that path unless there's a clear reason to.

BullMQ

For anything that shouldn't block the request cycle. I use it for delayed jobs, retries with backoff, and worker queues. On the chess platform it handles game clock expiration with lag compensation. Backed by Redis, survives restarts, and the dashboard visibility is genuinely useful in production.

Data

Prisma

Type-safe queries without writing raw SQL for every CRUD operation. The migration workflow is clean, the generated client is good, and it gets out of the way when I need a raw query.

Drizzle

When I need closer to the metal. The schema-as-code model is excellent and it's faster than Prisma in benchmarks that actually matter at scale.

PostgreSQL

My default database. ACID guarantees, rich indexing, full-text search. For anything that needs to be reliable, Postgres is the answer.

MongoDB + Mongoose

For document-shaped data where the flexibility is a genuine feature, not an excuse to skip schema design.

Redis

Sessions, rate limiting with sliding window algorithms, distributed locks for race prevention, pub/sub for Socket.IO scaling. The in-memory model makes it the right tool for anything that needs to be fast and ephemeral.

Auth

Better Auth

Authentication is one of the areas where I most want a well-maintained library doing the heavy lifting. Better Auth gives me email/password, Google OAuth, and TOTP-based 2FA out of the box, with session management, rate-limited auth flows, and a clean TypeScript API. I've wired it up with transactional emails via Resend and React Email, the kind of system that's tedious to build well and even more tedious to maintain.

Rolling your own auth is a security liability. I've seen enough CVEs from custom session implementations to have a firm policy against it.

Bun - the runtime performance numbers are real. Waiting on ecosystem maturity.
tRPC - type-safe API contracts end-to-end. Considering it for internal services.