Should I let AI choose my tech stack?
No. Let it comment, not choose. The stack decides what you can debug late at night, what you can deploy, what it costs to run and who else can work on it. Those are your constraints, and the AI doesn't carry them. If a tool picks the stack and the folders, you inherit a codebase nobody can explain, including you.
There is a quieter problem too. Asked for a stack, an AI tends to suggest a popular default, not the one you know. You end up maintaining a framework you chose by accident.
How do I choose a stack for an app I'm building with AI?
Answer four questions, in this order.
- What do I know well enough to debug? The AI will write most of the code. You still have to read the error paths.
- What does the page need? Look at the architecture from step 3: background jobs, search over text, file storage, sign-in with roles. Pick parts that cover those with the fewest moving pieces.
- Where will it run, and who deploys it? The DONE line in step 5 says it deploys from main. Choose something you can actually deploy that way.
- What can I remove? Every extra database or service is one more thing to watch. If a part you already have can do the job, use it.
Then write the stack as one line, and type it into the chat before you ask Claude anything about technology. That line becomes the STACK line of the brief in step 5.
When is it fine to take the AI's suggestion?
When it's about a part you don't have a view on and that is easy to replace later: a date library, a form helper, a test runner. Ask for the reasoning and the trade-off, and take it if it holds up. The rule is about the load-bearing choices: language, framework, database, hosting and sign-in.
How do I ask Claude about my stack without handing over the decision?
State the choice first, then ask what's wrong with it. "The stack is X, Y and Z. What in the architecture will this make hard?" is a check. "What stack should I use?" is a handover. The first keeps the decision with you and still gets you the AI's knowledge.
What are the common mistakes?
- Asking "what stack should I use?" first. You'll get an answer, and it will anchor you. Decide, then ask what's wrong with your choice.
- Choosing for the demo, not for production. The stack runs long after the build evening.
- Adding a database for one feature. Check whether the one you have already does it.
- Changing the stack mid-build. If the stack is wrong, stop, go back to the page and decide again. Don't let the coding tool swap it inside a prompt.
Which template should I use?
There's no separate template for this step. The decision goes into the STACK line of the build brief, and into the Stack section of the CLAUDE.md file in the free Claude Code starter kit.
What did the stack decision look like in the real JobFuture build?
FastAPI, Next.js and MongoDB Atlas. My call, typed into the chat before Claude could suggest anything.
Then the best idea in the build came from a what-if. Instead of calling the model for every user, a router reuses a saved result when a role is close to one we've already researched, and calls the model only when it isn't. Vector search runs inside Atlas, so it needed no extra database.
Claude · from the sessionYes, I think there's a better design. Spend would follow how unusual the user's case is, not what tier they're on.
The rule that went into the build: reuse when close, check when borderline, call the strong model when new. Quality first. Watch episode 3, the router.
The build brief
Copy it or download it. No email. Credit: "The Paper-First Method by Sohaib Waheed".