Client work vs side projects: why I use different stacks

A client project and a personal project are not the same sport.

I have long applied the same logic to both. I used what interested me, what was hype, what I wanted to test. And I quickly learned the hard way that it doesn’t work like that. Choosing a stack is above all a question of context, objective and risk.

In this article, I share with you my personal opinion on how I approach the choice of stack depending on whether I work for a client or on my own projects. You will see that the logic behind it is really different, and that confusing the two can cost you dearly.

Context changes everything

Before talking about tools, we have to agree on one thing: a client project and a personal project do not have the same constraints.

A client project is:

• A budget and a deadline defined in advance
• A client who expects a functional deliverable, not a demo
• Technologies that must be maintainable by someone else (or by you in 6 months)
• Zero tolerance for "I'm testing something new in production"

A personal project is:

• Your own rules of the game
• The freedom to experiment, to break, to start again
• A laboratory where you learn without direct consequences
• The perfect space to test what you want to ship next as a customer

These two worlds have completely different rules. And the stack you choose should reflect that.

For customer projects: reliability above all

On a client project, my first criterion is predictability. I want to know what's going to happen at each step.

The basic principle: use what you know

Now is not the time to discover a new framework. If you are comfortable with Next.js + Prisma + postgres database, this is what you use. Point.

You'll go faster, make fewer mistakes and deliver something you can defend.

Golden rule: A client project is not a training ground. You use what you know, not what you want.

My reference stack for client projects

Here is what I use by default on the vast majority of my missions:

I know this stack by heart. I know where it's stuck, I know how to debug, I know how to deploy. And above all, I know how to deliver on time.

Avoid “hype” stacks

Every year a new meta-framework comes out and everyone gets excited. Remix, SvelteKit, Qwik... These tools can be excellent, but if you discover them on a client project, you will spend more time reading the docs than coding.

Attention: this does not mean that we must remain frozen. This means that you test first on your personal projects, and then gradually integrate with clients once you are comfortable.

For personal projects: experiment without holding back

This is the complete opposite. My personal projects are my playground. I test things that I want, even if it's not yet stable.

The principle: learn by doing

I don't read tutorials to learn. I'm building something. And personal projects are the perfect place for that.

This is how I learned to use n8n for automation, how I experimented with LLMs locally, how I worked on AI agent type architectures... No client would have let me do that directly in production.

What I learned recently during my personal projects

Two tools that my personal projects really allowed me to explore: Convex and Supabase.

Convex is a “full-stack” backend as a service designed for JS/TS devs. You define your functions directly in TypeScript, and Convex manages the database, real-time queries, mutations and even background jobs. No REST to write, no ORM to configure, no server to manage.

What hooked me on Convex:

• Real time: data synchronizes automatically in the client, without WebSocket to manage manually
• Everything is typed from end to end: from the DB schema to the React component, zero friction
• DX is really nice: you stay in your TS codebase, you don't juggle between three different tools

Supabase is another beast. It is the open-source alternative to Firebase, built on PostgreSQL. You have the database, auth, storage and even edge functions, all in a single interface.

What convinced me about Supabase:

• PostgreSQL below: you keep all the power of SQL, with clean relationships and versioned migrations
• Auth is ready in 10 minutes: OAuth, magic link, email/password, everything is there without writing a back line

Both meet different needs. Convex shines on real-time apps. For Supabase: PostgreSQL and standard SQL, everyone knows, everyone can maintain. Today I know exactly which one to release depending on the project, and that's only because I tested them on my own stuff first.

How to bridge the two

What I personally set up is a fairly simple flow:

1. I spot an interesting tool

I read an article, I see a demo, a colleague tells me about it. I note.

2. I integrate it into a personal project

I'm building something small but concrete with it. A side project, an internal tool, anything that forces me to really use it.

3. I evaluate after a few weeks

Is it stable? Is DX good? Could I explain it to a junior? If so, it fits into my potential “client” stack.

4. I am gradually introducing it to clients

First on a non-critical project, with a tech-friendly client. Then in a broader way once I have perspective.

This cycle takes time, but it avoids getting stuck on important missions.

Summary

Conclusion

Choosing a stack is above all choosing according to context. Neither too conservative to never progress, nor too adventurous to never deliver.

My personal projects have allowed me to build a solid and differentiating client stack. And my client stack allows me to finance personal projects where I experiment without a safety net.

The two feed each other. That's the real game.

If you want to challenge your technical choices before releasing them on a critical project, come talk to me directly on LinkedIn. I'm always curious to discover new workflows and discuss what works (or not).