Posted on February 14, 2026 at 10:32 AM
There are too many options out there, and if you're already a bit unsure, that abundance doesn't help. It usually just leads to more indecision. So this is me laying out what I use right now. Not what I'll use forever. Not what you should copy blindly. Just what works for me today.

I've been a developer for close to 10 years. I've gone through a ridiculous number of languages, frameworks, libraries, tools, and trends. Some of them stuck. Most didn't. I've also changed my "main stack" more times than I can remember. That's normal. If you never change your stack, that's usually a red flag, not a virtue. What you're reading here is a snapshot, not a doctrine.
For personal projects of any real size, I'm using TypeScript with strict mode on. I'll be honest: I hated TypeScript at first. It felt like busywork. Extra code. Slower momentum. Not enough payoff. That opinion didn't survive bigger projects. Once things get complex, TypeScript starts paying rent. It catches errors before they ship. IntelliSense actually helps instead of getting in the way. The code explains itself better, especially when you come back to it months later. At this point, it's also just the norm. If you open a serious frontend or Node.js codebase today and it isn't using TypeScript, that's the exception. I still teach JavaScript a lot. But when I'm building something I care about? TypeScript.

I'm not here to crown React as the best frontend framework. It isn't. I use it because I know it best. I've used Vue. I've used Angular. They're fine. I'm fastest and most comfortable in React, so that's what I reach for. For small tools, I'll often skip Next.js and just use React with Vite. If I don't need SEO, server rendering, or anything fancy, I don't force it. A small SPA with a fast UI is sometimes all you need. For larger apps, I usually go with Next.js. Server components by default. Client components only when I need hooks, events, or interactivity. API routes or server actions instead of spinning up a separate backend unless there's a good reason. It's performant, popular, and doesn't fight me. That's the bar.

I use Tailwind CSS. Almost exclusively. Outside of tutorials, I honestly can't remember the last time I wrote traditional CSS. Probably a couple of years ago. Yes, the class lists get long. Yes, your JSX looks messy sometimes. I'm fine with that trade-off. Tailwind removes a whole category of decisions and context switching. I don't think about naming things. I don't think about file structure. I just style the component and move on. Occasionally I'll pull in shadcn/ui for pre-built components, but even then I usually customize them heavily.

I'm using Postgres, hosted on Neon. I used MongoDB for years. It worked, until it didn't. Pricing got out of hand. One production project was running into the thousands per month. Even a demo app for a course, not a real business, was around $600/month. That was enough. Neon's pricing is predictable. Branching alone is worth it. I can experiment without risking production data, which removes a lot of stress. Relational databases aren't fashionable, but they're boring in a good way.
ORM: Prisma
I use Prisma to interact with Postgres. There are other good options. Drizzle is solid. I mostly ended up on Prisma by chance and stuck with it because it does what I need. Data modeling is straightforward. Migrations are manageable. Prisma Studio is genuinely useful for inspecting and editing data. Could I switch? Sure. Do I feel the need to? Not really.

If I'm using Next.js, I usually deploy on Vercel. They build Next.js. The integration is smooth. Push to main, it builds, it deploys. That's it. I came from the FTP and cPanel era. FileZilla uploads. No version control. No safety net. Waiting forever for uploads and hoping nothing broke. Compared to that, modern deployment feels almost suspiciously easy. For backend services and APIs, I use Render. It gives me the same simplicity for backend deployments without managing a server myself. It beats maintaining a DigitalOcean droplet by a wide margin.

I'm not going to pretend I write exhaustive tests for everything. When I do write tests, I use Jest. For automation, linting, testing, builds before deploy, I rely on GitHub Actions. Nothing fancy. Just enough to catch obvious breakage.
Right now, I'm using Claude Code inside VS Code. I tried Cursor. It's good. Claude Code fits my workflow better. I don't vibe code large apps anymore. I tried. It backfired. What works better is heavy context: project rules, architecture notes, coding style docs. I write code manually, test manually, and then use the AI as a reviewer. Redundancy. Bugs. Missed patterns. That's where it helps. Letting an agent run wild on a large codebase? I've learned that lesson already.
Two production projects currently run on this setup.
webutils.io started as a place to collect all the small tools I kept bouncing between sites for: PDF tools, file compression, favicon generation, fake data, and so on. Most tools run client side, so they're fast. There are also dev focused utilities like diffing, grid and flexbox generators, gitignore creation, TypeScript interface generators, etc. It's free. No registration required unless you want favorites. Auth is handled with NextAuth. There's an admin area for managing users, tools, and analytics. AI was used, but not blindly. A lot of manual review and cleanup.
devsheets.io is a cheat sheet platform. The goal wasn't to dump documentation. It was to capture what I actually want to remember: the useful parts, with quick references and realistic examples. There are sheets for Git, TypeScript, Python, Express, DOM manipulation, even AI prompting. More are coming, across different languages. There's also a health related SaaS in progress using the same stack. It's a symptom tracker with analytics and AI generated correlations. I'm deliberately careful there. No diagnoses. No medical claims. Just patterns and suggestions. There will likely be a paid tier, but it's not close to finished.
That project started as pure vibe coding. It collapsed under its own weight. Fixing one thing broke three others. That failure was useful.
Sometimes Next.js is the wrong choice. I built a fake REST API service similar to JSONPlaceholder at apiocker.com It's an Express app. The frontend is just a static HTML file in a public folder. The API is the product.
Same with apiprobe.dev, an open source HTTP client tool. Think Postman lite. Both are open source. If you want to contribute, feel free. Not everything needs a meta framework.
If your current stack works, don't change it because someone else uses something different. If it doesn't work, then yeah, maybe try some of this. Or don't. Stacks are tools, not identities. Mine will change again. Yours probably should too. That's where I'm at right now.
Please login to add a comment
← Back to User's Blog Page