My Tech Stack in 2026: What I Use and Why

My stack is boring on purpose. Every tool on this list earned its place by surviving real deadlines, real clients and real bugs at 1 a.m., not by trending on a Tuesday.

People ask me what I use, usually right after they see a project and want to know whether the answer is some secret framework. It isn't. I started as a UI/UX designer, moved into frontend, then full stack, and this year I took on a Technical Project Manager role at NovaNext where I still write and review code every week. That path shaped the stack more than any benchmark did.

So here is what I actually reach for in 2026, and the reasoning behind each choice.

Design: Figma, still

Everything starts in Figma. Not because design has to be pixel-perfect before code, but because a frame is the cheapest place to be wrong. Moving a button in Figma costs ten seconds. Moving it after the API, the form validation and the tests are wired up costs an afternoon.

I lean heavily on components and variables in Figma so that the design file already looks like the codebase it will become. Colors, spacing and type sizes live as tokens, and those tokens map almost one to one onto Tailwind. I'll write about that handoff in detail soon, because it's where most projects quietly lose time.

Frontend: React 19, Next.js 16, TypeScript, Tailwind CSS v4

Next.js 16 with the App Router

For anything that lives on the web and needs to be found, Next.js is my default. The App Router, Server Components and Turbopack mean I can render most of a page on the server, ship less JavaScript, and still drop into client components where interaction matters. My portfolio runs on it, including the scroll-driven frame animations on the home page.

I don't pick Next.js for internal tools that sit behind a login and never need SEO. For those, a plain React app talking to an API is often simpler, and simpler wins.

React 19

React 19 removed a lot of ceremony. Actions and the newer form hooks mean less hand-rolled loading state, and useSyncExternalStore has become my go-to for small pieces of global state that come from outside React, like browser APIs. I reach for it more than I reach for any state library.

TypeScript everywhere

I don't start JavaScript projects anymore. TypeScript isn't about catching typos; it's about making the shape of the data a shared contract between me, my teammates and, increasingly, the coding agents I work with. When an API response changes, I want the build to tell me which twelve components broke.

Tailwind CSS v4

Tailwind v4 with CSS-first configuration fits the way I think as a designer. Tokens go into @theme, components use utilities, and I stopped fighting specificity years ago. At Aankhijhyal Technologies I spent a good chunk of time removing redundant CSS from older components, and that experience convinced me: the fewer bespoke stylesheets a team writes, the fewer they have to untangle later.

TanStack Query for server state

Most "state management" problems I've seen were really server-state problems: caching, refetching, loading flags, stale data. TanStack Query handles all of that. Local UI state stays in useState. Shared client state, when it exists at all, is small enough for context or a tiny store.

Backend: Django 6 and Django REST Framework

This is the choice people find surprising from a frontend-first developer. Why not Node all the way down?

Because Django gives me an admin panel, an ORM with migrations that just work, authentication, permissions and a mature ecosystem on day one. For the kind of products I build, like restaurant management with POS and inventory, the hard part is business rules and data integrity, not raw request throughput. Django is very good at modelling business rules.

Django REST Framework sits on top for the API layer. Serializers double as validation, viewsets keep CRUD endpoints short, and the permission classes map cleanly onto role-based access control, which matters a lot when a product has many staff roles.

• Django 6: models, migrations, admin, auth, background-friendly structure.
• DRF: serializers, viewsets, permission classes, pagination, filtering.
• PostgreSQL: the default database for anything that matters.

Data: PostgreSQL and Supabase

PostgreSQL is the one decision I never revisit. Constraints, transactions, JSON columns when I genuinely need flexibility, and solid full-text search for smaller projects.

Supabase is what I use when a project needs a Postgres database, auth and storage quickly without a custom backend. Prototypes, side projects and small client tools often start there. If the business logic grows complicated, I move it into Django. Supabase being plain Postgres underneath makes that migration less painful than it sounds.

Mobile: Flutter

My Japanese-learning app, Kanjiro, is built with Flutter. One codebase, both platforms, and a widget model that feels natural coming from React. I picked it for Kanjiro because the app is offline-first: hiragana drills, flashcards and streaks should work on a bus with no signal. Flutter made it straightforward to keep everything local and sync later.

I don't force Flutter onto web projects. For the web I stay with React.

Deployment: Vercel and a VPS with Nginx + Gunicorn

Two lanes, depending on what's being deployed.

1. Frontends and Next.js sites go to Vercel. Preview deployments for every branch are worth it alone. Clients can click a link instead of me recording a screen.
2. Django backends go to a VPS behind Nginx and Gunicorn. It's cheap, predictable, and I understand every layer. When something breaks I can SSH in and read logs instead of guessing.

I've tried fancier setups. For small teams and Nepali SMEs that watch every rupee of hosting cost, a well-configured VPS still makes a lot of sense.

AI tools: Claude, ChatGPT and coding agents

I use Claude and ChatGPT every day, along with coding agents inside the editor. They draft boilerplate, explain unfamiliar code, write first versions of tests and catch things I'd miss in a tired review. They don't decide architecture and they don't merge code I haven't read.

The stack matters less than knowing exactly why each piece is there and what you'd replace it with if it stopped working.

Hardware: MacBook Air M4

Everything above runs on a MacBook Air M4. No fan, long battery life, and it handles Next.js dev servers, a Django backend, Postgres and a Flutter emulator at the same time without complaint. Given how often power used to cut out in Nepal, a laptop that lasts a full working day on battery still feels like a luxury I appreciate.

What I deliberately don't use

A stack is also defined by what it leaves out.

• Redux by default: TanStack Query plus local state covers almost every case I hit.
• Microservices: one well-structured Django app beats five tiny services for a small team.
• CSS-in-JS runtimes: Tailwind gives me the same co-location without the runtime cost.
• A new framework per project: consistency across projects lets me move people between them.

Where I've landed

If you're early in your career, don't copy this list. Copy the method. Pick tools that let you ship, learn them properly, and only swap one out when you can name the specific problem it's causing. Mine is React and Next.js on the front, Django and Postgres on the back, Flutter for mobile, Figma before all of it. It isn't exciting, and that's exactly why it works.