The Sovereign Stack

Building without permission in 2025.

I didn't study computer science. I learned to code by building. My stack reflects this reality—not what's academically pure, but what compounds leverage into outcomes. The best technology stack is the one you actually use.

Why Your Stack Matters (and why most don't)

Technology is power, but only if it multiplies your ability to create and ship. Most developers optimize for elegance. They debate Rust vs. Python. They obsess over architectural patterns. Meanwhile, the builder ships. The best stack is opinionated about problems, not tools. Mine is.

The Layers of My Stack

Layer 1: Ideation → Claude(Skills) & Gemini

Every product starts in thinking. Most developers skip this step. They reach for the keyboard. They start with code. I start with Claude—not because it thinks for me, but because it organizes thinking with me. I dump an idea—half-formed, messy, contradictory. Claude asks the right questions back. We iterate. By the time I'm ready to build, I've already solved 80% of the problems in conversation. This saves months. The principle: The cost of building the wrong thing is infinite. Thinking is cheap.

NDLR : used Claude Skills to create a template of command to create your first input of project (exemple : prd-generator based on new idea)

Layer 2: Backend Complexity → Claude Code

Not all code is created equal. Some of it is rote. Some of it is hard. For the rote stuff, GitHub Copilot is fine—fast and accurate enough. For the complex logic that actually matters, I use Claude Code. Claude understands context: paste a codebase, refactor a workflow, optimize a query while understanding why the query matters to the rest of the system. Other LLMs (Sonnet, Grok) are good for speed. Claude Code is better for depth. The principle: Match the tool to the complexity of the task. Simple problems don't deserve complex thinking.

Layer 3: Prototyping → Streamlit

Between idea and product is prototype. Most people skip this step. They jump straight to "building the real thing" and realize the idea was wrong. Streamlit is how I avoid this tax: Python → data processing → interactive dashboard. No frontend frameworks. No CSS debates. Just logic and interface. In hours I can put a human face on a backend idea, test assumptions, and ask "do you want to buy this?" Streamlit makes prototyping the fastest path from "I think this could work" to "this actually works." The principle: Test the idea before you optimize the implementation.

Layer 4: IDE Intelligence → Multi-LLM Approach

I break convention here. Most developers pick one IDE, one LLM. I don't. GitHub Copilot is my baseline: fast, integrated, GitHub-aware. But Copilot has blind spots. So I use multiple LLMs simultaneously:

• Grok Code Fast for speed. It ships rough code quickly; I refine it.
• Claude Sonnet 3.5 for reliability. It understands nuance, catches edge cases, and explains architectural choices.
• Gemini 3 for perspective. It sees certain domains differently (data processing, complex algorithms). When Sonnet and Grok disagree, Gemini is the tiebreaker.

This isn't complexity for its own sake; it's optionality. If one LLM is stuck, I switch. If one is mediocre, I have another review it. I treat them like junior developers—useful, but not infallible. The principle: Optionality is underrated. Use multiple tools. Keep the best output. Discard the rest.

Layer 5: Design & Frontend → Figma + Multi-LLM

Design and frontend are now the same problem. Figma is where I think through interfaces. It's where I validate the idea visually before I code it. Then I move to code with the same multi-LLM approach:

• GitHub Copilot for quick components.
• Sonnet 3.5 when the design is complex and needs to be pixel-perfect.
• Grok when I need to ship fast and "good enough" is good enough.

UI is communication. Get the design right, then automate the implementation. Most developers reverse this. The principle: Think in Figma. Build with code. Use AI to compress the gap between them.

Layer 6: Deployment → No Vendor Lock

This is where most people lose autonomy. They deploy to Vercel, AWS, Heroku—then they're trapped. Pricing goes up. Features disappear. They're stuck. I refuse this. Cloudflare Pages & Workers is my default: fast, cheap, handles static and serverless, no vendor lock. Replit is my fast-track for prototypes: full environment in the browser, perfect for sharing. For anything I truly own, I self-host with Coolify or Dokploy—open-source, runs anywhere, costs pennies. Your infrastructure is part of your business; if someone else controls it, they control your business. The principle: Choose platforms that give you control. Avoid platforms that give platforms control of you.

Layer 7: Automatization → n8n or Gumloop

Code matters little if you have to run it manually. Workflows matter. n8n and Gumloop turn one-off scripts into products that run without me. I connect APIs, build workflows, and create products that work while I sleep: someone signs up → email triggers → data flows → output ships. This is where the Account Manager hat is valuable: I know the problems enterprise customers actually have. One good automation is worth ten mediocre jobs. The principle: Build things that work while you sleep. Everything else is a job.

The Real Stack

Here's what's not on the typical stack list, but it's the foundation of everything:

• Curated optionality: I don't use every tool. I use the right tool for each problem. Judgment matters—knowing when to use Claude vs. Copilot vs. Grok, when to prototype vs. build, when to self-host vs. use a platform.
• Speed over perfection: I iterate in days, not months. I prototype in hours, not weeks. The cost of being wrong is low. The cost of being slow is infinite.
• Constraints as clarity: I'm not building for Google-scale. I don't have unlimited capital. Constraints force elegance and ruthlessness about what matters.
• The knowledge layer underneath: My tools work because I understand why I'm using them—data infrastructure from Synergy, enterprise sales from business development, AI from obsessive study. Tools don't replace thinking; they amplify it.

Why This Stack Works

Most stacks are built bottom-up: learn a framework, learn a language, build. My stack is top-down: start from the outcome, find the simplest path, and pick the tools that compress it. Each layer answers one question: How do I compress the time from idea to shipped product?

• Ideation: How do I think more clearly? Claude.
• Backend: How do I handle complexity? Claude Code.
• Prototyping: How do I test assumptions fast? Streamlit.
• IDE: How do I avoid context-switching? Multi-LLM approach.
• Design: How do I validate before building? Figma.
• Frontend: How do I ship UI fast? GitHub Copilot + multi-LLM.
• Deployment: How do I own my infrastructure? Cloudflare, self-hosting.
• Automation: How do I build products that run themselves? n8n, Gumloop.

Each tool has one job. Each job has one tool (or a chosen set).

The Multi-LLM Philosophy

Here's what most people get wrong: they treat AI as a replacement for thinking. "Let Claude code the whole thing." I treat AI as a tool for thinking—different tools for different problems.

• Use Grok when you need speed and don't care about optimal.
• Use Sonnet when you need depth and can afford to wait.
• Use Gemini when you need a different perspective.
• Use Copilot when you need integration and convenience.

Train yourself to be a conductor, not a musician. You're not writing the symphony; you're directing the orchestra. The principle: The best engineer isn't the one who codes the most. It's the one who chooses the right tools and compresses execution time.

What's Not in My Stack

Kubernetes. Docker Swarm. Terraform. Java. Complex microservices. GraphQL when REST works. These are powerful and sometimes necessary at scale. I don't use them because I haven't needed to yet—and I won't until the problem forces me to. Too many developers learn the coolest frameworks, then wonder why they're not shipping. I ship first. I optimize when pain forces me to. The principle: Complexity is a cost, not a feature. Only pay it when you have no choice.

Why This Matters Now

We're at an inflection point. AI has made coding accessible. It hasn't made judgment accessible. The scarce resource isn't engineering anymore; it's knowing what to build, why to build it, and when to ship instead of optimize. Your stack should reflect this. Mine does. I don't optimize for "best practice." I optimize for outcomes. I don't use cutting-edge technology because it's cutting-edge. I use it because it moves the needle on problems I actually have. Most importantly: I know my stack well enough to break it, violate it, and adapt it. A stack you don't understand is just fashion. A stack you understand deeply is leverage.

The Invitation

Stop asking "what's the best tech stack?" Start asking "what do I want to build?" Then pick the smallest set of tools that gets you there. Your stack doesn't need to be impressive. It needs to work. It needs to compress the time from thinking to shipping. The future belongs to builders—not tool collectors, not people who optimize endlessly. People who ship fast, iterate, and learn from real users instead of imagined problems.

What's your stack built for?