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 ML Engineer covers the data-and-AI corners of modern stacks, 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.