Full Stack DevelopmentSoftware ArchitectureEngineering MindsetProductivity

Why I’m Committing to This Tech Stack (And Not Switching Again)

Author
AuthorAdam Goujdami
PublishedNov 26, 2025
Read Time5 min read

I have built about a dozen projects over the last few years.

Some were just for me, some were for actual people, others for clients. But looking back, I had a problem.

Every time I started a new repo, I felt the need to change my tools.

One month I was all in on Django because I liked Python and it promised to handle everything. The next project, I would be rewriting my frontend with Vite because I read it was faster. Then I would jump back to raw Node.js. Then I would swap my database to MariaDB just to see what would happen.

I was getting work done but it was exhausting. I was spending half my energy fighting new configurations instead of just building the application.

I realized that to build software that is actually solid and maintainable, I needed to stop experimenting and start mastering.

So I made a decision. I picked four tools. I decided that for the next few years, I am sticking to them.

Here is the stack that finally brought sanity to my workflow.

The Backend: NestJS

I used to think I wanted freedom. When I used raw Node.js, I could put files wherever I wanted.

But after building a few apps, you realize that freedom usually just turns into a mess. You come back to a project two months later and you can't find anything.

NestJS fixed that for me.

It is organized. It forces me to put things in the right place. There is a folder for Controllers, a folder for Services, and a folder for Modules. It matches how I think when I map out a system.

Why I’m Committing to This Tech Stack (And Not Switching Again)

The best part is that it shares the same language as my frontend. I write TypeScript on the backend and TypeScript on the frontend. I don't have to mentally switch between Python and JavaScript anymore. It is one language for the whole stack. Speaking of Frontend:

The Frontend: Next.js

Frontend development can be a headache. I have wasted so many hours setting up routers and figuring out why images weren't loading fast enough.

Next.js (specifically the App Router) just handles it.

I create a file and it becomes a page. I fetch data and it shows up. It is fantastic for SEO because the content is rendered on the server.

Is it the absolute fastest framework on earth? Maybe not. But it can be optimized to be incredibly fast. More importantly, it is fast enough for 99% of use cases. It handles the hard stuff so I can focus on the UI.

The Database: PostgreSQL & Prisma

I have learned the hard way that data is the most important part of the app. You can fix a bug in the code but you can't un-break bad data.

Now I use PostgreSQL. It is the standard for a reason. It is boring and I love that. It doesn't break.

To talk to the database, I use Prisma.

I didn't start here. I cycled through raw SQL and other ORMs, but they were either too tedious or too magical. Prisma hits the sweet spot. I write my data structure in one file called "schema.prisma" and it generates all the TypeScript types I need.

This saved me recently. I had to rename a critical column in my database schema on a ride hailing app. in my old projects, this would have broken the app in ten different places and I wouldn't have known until production. With Prisma, I updated the schema file and my code immediately turned red in every place I needed to fix. I caught every bug before I even ran the app.

The Glue: Docker

"It works on my machine."

What software engineer doesn't hate that phrase. I used to say it a lot when I was starting out.

Now I use Docker. I have one simple file, my lovely docker-compose.yml. In my terminal, i type 'docker compose up' and and my whole app starts up. Database, backend, frontend, everything.

It doesn't matter if I'm on my laptop or if I move to a different computer. It runs exactly the same way every time. No more debugging my teammate's code that won't run on my computer for hours...

The Architecture: Standard REST APIs

I don't try to get fancy with GraphQL unless I have a very specific reason. I stick to standard REST APIs.

Why? Because they are simple.

Every developer understands GET, POST, PUT, and DELETE. It is easy to debug. It is easy to document.

I want my backend to be a simple machine. It takes a request, validates it, does the work, and sends back a response. REST does that perfectly without overcomplicating things.

The Trade-Offs

Now let’s be honest. Is this the single most optimal stack for every single problem in existence?

No.

If I were building a video game engine, I wouldn't use this. I would use C++. If I were building a high-frequency trading bot where every microsecond mattered, Rust is the way to go.

I know there are tools out there that might be 5% faster or slightly more lightweight.

But here is the truth. The trade-offs are worth it for majority of web projects.

I am willing to trade that tiny bit of theoretical performance for the massive amount of sanity, structure, and speed of development this stack gives me.

Why I’m Committing to This Tech Stack (And Not Switching Again)

Just Building

Whether you are a student wanting to build your first serious project, or a professional wanting to deliver a product to a client, this stack is among the best you can choose.

It balances structure with speed. It balances safety with flexibility.

For me, this is the stack that lets me deliver.

I don't waste time choosing tools anymore. I just open my terminal, spin up these four things, and start working on the solution.

It feels good to stop searching. It feels good to just build.

Thanks for reading. Share your thoughts.