Tech-Stack Selection
Choose the right stack without falling for hype or sunk cost. Rival frontier models argue it out and hand back a recommended stack with the trade-offs and the decision criteria made explicit.
A recommended stack with the trade-offs and the decision criteria made explicit.
Signed off by an independent Final QA audit — with a “verify before you rely on this” list, never a black box.
Why this team
Stack debates are usually proxy wars — hype versus sunk cost — so the seats are chosen to cancel those forces: the Software Architect evaluates fit to the actual problem, the CTO judges what the team can actually operate and hire for at ten times the load, and the Performance Engineer tests claims about scale against arithmetic. The First-Principles Thinker strips vendor marketing to what the tool must actually do, the Contrarian argues the unfashionable option on merit, and the Pragmatist prices the learning curve in shipped-features foregone.
The seats are spread across rival frontier labs — GPT, Claude, Gemini and Grok — so it’s a genuine cross-model review, not one AI in costumes. How a run works →
What the debate sounds like
An illustrative excerpt — A two-founder team building a B2B document-workflow product is torn between the stack they know (Rails and Postgres) and a serverless TypeScript stack a respected friend swears by.
The unpriced line item in this comparison is fluency: you ship your first customer-visible feature in week one on Rails, versus week five while learning a new mental model of state. For a two-person pre-revenue team, four weeks of shipped features is the difference between having and not having design partners this quarter. The friend’s stack is not wrong — it is wrong for who is holding it.
Derive the requirement before the religion: document workflows are long-lived stateful processes — drafts, approvals, versions. That is the one workload where a stateless function model adds friction rather than removing it, because every step must reconstruct context a monolith keeps in hand. The problem shape argues for the boring relational core regardless of anyone’s taste.
Steelmanning the serverless case anyway: if the product’s core were spiky, embarrassingly parallel document processing — OCR bursts, batch transforms — pay-per-invocation beats idle servers and the argument flips. Worth checking the roadmap honestly. If that workload is coming, carve out that one path as functions later; it does not need to be the foundation.
Questions
Can it compare two specific technologies, not just philosophies?
Yes — name the candidates and the debate runs on their actual properties: maturity, hiring pool, operational burden, ecosystem, failure modes. The persona mix keeps it honest about the boring dimensions (who maintains it at 2 a.m., who can you hire) that comparison blog posts skip.
What if my team already disagrees — can this arbitrate?
Paste both positions as they are actually argued internally. The Steelman-style treatment means each side gets its strongest version stated before the trade-off is judged, which tends to defuse the internal politics: the losing option gets an honest runner-up case and a written reversal condition, not a dismissal.
How does the council avoid just recommending whatever is popular?
The Contrarian seat exists to argue the unfashionable option and the First-Principles Thinker strips marketing claims to mechanics, so popularity enters only as what it really is: a proxy for ecosystem maturity and hiring. The verdict states the conditions under which the recommendation would be wrong.
Your material is used only to run your review — never to train public models. Encrypted in transit and at rest. Security & privacy →
Rather assemble it yourself — your own minds, your own brief? Open the full council →