The day your second project looks nothing like the first
You're not a developer, and you're building your app with AI. At first, everything goes fine.
Your agent has you create your first git repository (the place where your code lives). It picks a language, a framework (the base toolbox your app is built on), a database, a way to handle user accounts. You didn't ask for any of that. It made choices, and those choices are consistent with each other. Your app runs.
Three months later, your product has grown. You have customers, orders, data to look at. You want a back office to manage all of it.
So you do what seems logical: a new project, a new repository. You open your agent and give it roughly the same request as the first time. "Build me an admin app to manage my customers and orders."
It builds you a back office. It works. And it has nothing in common with your app.
Your app is in TypeScript. Your back office is in Python.
You don't notice right away, because both of them work. You notice the day they have to live together.
The trap isn't picking the wrong stack. It's never having picked one.
Why the AI doesn't make the same choice twice
It's not a bug. It's how an agent normally works.
When you ask it to create a project, it has no memory of your first repository. It doesn't even know it exists. It answers the question you asked, with whatever seems most likely for that specific question.
And "most likely" depends on the words you use. "An app" and "a back office" don't trigger the same reflexes. Neither do "a dashboard", "an API", "an internal tool". Each phrasing has its favorite ecosystem. Change three words, change the language.
It's like bringing in two architects who have never spoken, three months apart, to build two buildings on the same plot. Each does good work. But one installed 220-volt outlets and the other 110. Both houses are livable. The plot, though, has become a headache.
An agent amplifies what already exists in your project. In an empty project, there's nothing to amplify. So it starts from zero, and zero is never the same twice.
What it costs you, concretely
On paper, two projects that work are two projects that work. In real life, here's what you just bought yourself.
Two languages. Each language has its tools, its libraries, its traps. The AI juggles both effortlessly. You don't. And the day you bring in a developer, you need someone who masters both, or two people.
Two deployment pipelines to maintain. CI/CD is the mechanism that checks your code and puts it online with every change. With two stacks, you have two of them. Two configurations to understand, two places that can break, two sets of settings to redo when a service changes its terms.
Two authentication systems. This is the most painful one. Your app handles accounts one way, your back office another. Result: either you log in twice, or you have to build a bridge between the two. And a bridge between two login systems is exactly the kind of place where security holes settle in.
Two ways to deploy. Two hosts, or two configurations at the same one. Two bills. Two sets of passwords and keys to protect. Two procedures to know when it goes down on a Sunday night.
Two architecture logics. Each ecosystem has its own way of organizing things. You had started to understand how your app was laid out. The back office is laid out differently. Everything you had learned is useless on the other side.
And there's the cost that doesn't show up in the list: every fix is done twice. A business rule that changes (a new order status, a new way of computing a price) means two implementations, in two languages, kept aligned by hand. You'll forget one. That's where the bugs are born where the app says one thing and the back office says another.
| One stack | Two stacks | |
|---|---|---|
| Changing a business rule | One place | Two places, in two languages |
| User login | One system | Two systems, or a fragile bridge |
| Going live | One pipeline | Two pipelines, two hosts |
| Hiring or delegating | One profile | Two profiles, or a unicorn |
| What you learned about your code | Reusable everywhere | Valid on one side only |
The problem isn't Python or TypeScript
Let's be clear: both are great. Python is excellent. TypeScript is excellent. You could build your entire product with either one, and it would hold.
The problem isn't the choice. It's the absence of a choice.
A kitchen where every drawer comes from a different store works too. Every drawer opens. But nothing fits together, every repair needs a different part, and nobody but you knows where the cutlery is.
It cuts the other way as well. The latest trendy framework, the one everyone on LinkedIn is talking about this week, is not a reason to start your third project on it. A standard, consistent stack, any decent developer can pick up. A collection of brilliant choices made at different moments, nobody wants to pick up.
Consistency is worth more than novelty. In a product, that's almost always true.
How to pin your stack down without being technical
You don't need to understand the technologies to make this decision. You need to write it down, and hand it to your AI every single time.
1. Have your current stack described
Open your first project, the one that runs, and ask your agent this:
Describe this project's stack in ten lines maximum:
language, framework, database, user account handling,
hosting, how it's deployed, and how the code is organized.
Be concrete, with exact names and versions.
You get your project's ID card. You don't need to understand all of it. You need to keep it.
2. Store it in a file at the root
Create a file at the root of your project and paste that card in. Agents read these files automatically when they work in your project: CLAUDE.md for Claude Code, AGENTS.md for Codex and most of the others. A STACK.md file you paste into the conversation yourself does the job too.
It looks like this:
# Stack
- Language: TypeScript
- Framework: Next.js
- Database: PostgreSQL via Supabase
- User accounts: Supabase Auth
- Hosting: Vercel
- Deployment: automatic on every push to the main branch
- Organization: one folder per feature
Every new app or service of this product uses this stack.
If you think another choice is better, explain why and
wait for my approval before writing any code.
The last sentence matters as much as the list. It turns a silent choice into a conversation.
3. Start every new project with this card
The day you want a back office, an API, an internal tool, whatever: your first sentence to the agent is "here's my stack, don't stray from it", followed by the card. Before you even describe what you want to build.
You just did in thirty seconds what a technical team takes several meetings to decide.
4. Ask yourself whether you really need a new project
It's the question nobody asks, and it's often the right one.
A back office, in most cases, is one more section of your existing app. Same users, same database, same business rules. The only difference: pages reserved for you and your team. No need for a new repository, new hosting, or a new login.
Creating a separate project is a decision, not a reflex. Ask your agent: "can this back office live inside the existing project?". Nine times out of ten, the answer is yes, and you just sidestepped the whole problem.
What if it's already too late?
You've read this far with a knot in your stomach, because you already have two stacks. It happens to a lot of people, and no, you don't have to rewrite everything tomorrow morning.
Designate a main stack. The one where your users and most of your code live. That one wins.
Freeze the other. No more new features on that side. It keeps running, it stops growing. Every new thing gets built in the main stack.
Bring things over as you go. When you have to touch a piece of the frozen project, that's the moment to rebuild it on the other side, rather than fix it in place. The move happens piece by piece, with no D-day.
And be honest about what deserves to stay. A script that runs once a month to send an export, in Python, off in its corner, is not a problem. The problem is two living applications, with users, that have to evolve together.
The only case where switching stacks is defensible
It exists. Your stack genuinely can't do something you need, or you're hiring a team that masters something else. In that case, you switch, and you switch for the whole product, with a plan.
What's not defensible is switching because a new framework came out, or because the agent felt like it that day. You don't change languages with every new room in your house.
Key takeaways
- Your AI picks a stack for every new project, and rarely the same one twice. If you don't decide, it decides for you.
- Two stacks means two languages, two deployment pipelines, two login systems, and every fix done twice.
- Have your stack described, store it in a file at the root, and start every project by pasting it to your agent.
- Before creating a new repository, ask whether it can live in the existing project. Often, it can.
- Consistency is worth more than the latest trendy framework.
You don't need to know how to code to make this decision. You just need to make it.
Want a product that holds together as one piece?
That's my job: building fast with AI, on a stack that's been decided, consistent, and that another developer can pick up after me. If you're looking for someone to build or take over your product, check out my custom development offer.
Already have two projects that don't talk to each other and don't know which one to keep? Book an audit: in 3 days, you know what's solid, what's risky, and what to fix first.
And to get more articles like this one, sign up for the newsletter. No spam, just what you need to know.
