Tech-Stack Selection
Choose the right stack without falling for hype or sunk cost.
A recommended stack with the trade-offs and the decision criteria made explicit.
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.
Help us choose a technology stack (or a specific tool) and debate it on the merits, not the hype. THE DECISION: [what you are choosing — language, framework, database, platform, etc.] THE OPTIONS: [the candidates on the table] CONTEXT: [team skills, scale, timeline, existing systems, budget] PRIORITIES: [what matters most — speed to ship, scale, hiring, cost, maintainability] Debate: 1. Fit to the actual problem and scale — not the problem you wish you had. 2. Team capability and the real cost of learning curve. 3. Maintainability, hiring pool and long-term support. 4. Performance and scale headroom versus over-engineering for it. 5. Lock-in, ecosystem maturity and the boring-tech argument. 6. The cost of being wrong, and how reversible the choice is. FINAL SYNTHESIS: - A clear recommendation with the top three reasons. - The strongest case for the runner-up, so the trade-off is honest. - The conditions under which we would choose differently.
An illustrative excerpt for a hypothetical brief of this type: 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. Every real run is generated fresh from your specifics, debated across rounds, and audited before the verdict.
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.
Recommendation forming: Rails and Postgres core for the stateful workflow, one clean seam reserved for future burst processing, and the decision documented with its reversal condition — revisit if processing volume or team composition changes materially. The runner-up case is real, which is exactly why it goes in the record next to the choice.
Prefer drop-and-go? Use the Tech-Stack Selection tool — team pre-seated, included with Plus.
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.