Tech stack selector
Six questions, five minutes, no email. The reasoning is published, so you can reach the same answer without us.
Three things that decide this
3 things that decide this
- 01You get a shortlist of two or three stacks that fit your constraints, and the reason each one made the list.
- 02It takes about five minutes and asks nothing about your budget or your email address.
- 03It will not tell you which stack is best. There is no such thing, and any tool claiming otherwise is selling something.
Six questions, and what each one rules out
Stack debates run long because people argue preferences. Constraints settle them faster, and there are only a few that matter for a new build.
Six questions cover it, and they are the ones we work through on a scoping call. Each rules something out rather than picking a winner. That is why the result is a shortlist, not a single answer.
Weighting is deliberately simple. Compliance and data shape are hard constraints that eliminate options outright. Team skill and hiring reality narrow what is left. Scale and integration usually decide between two survivors, and by then the choice matters less than either team believes.
- 01What shape is your data? Related records with rules point at a relational database. Genuinely varied documents do not.
- 02What must the system prove? Audit trails, data residency and approval steps eliminate options before anything else does.
- 03What can your team already run? A stack nobody on the team can operate at 2am is the wrong stack, whatever its benchmarks say.
- 04Who will maintain it in two years? Hiring reality in your market rules out more stacks than performance ever does.
- 05What does it have to talk to? An existing system with one good client library will quietly decide your language.
- 06What happens at ten times the volume? Ask this last. Most builds never get there, and designing for it first is how projects stall.
- ComplianceEliminates options outright
- Data shapeDecides the database first
- Team skillNarrows to what you can run
- HiringWho maintains it in year two
- IntegrationExisting systems pull hard
- ScaleLast, and usually least
Running these in the wrong order is how teams end up with a stack nobody can operate.
What each answer points toward
Published so you can reach the same shortlist on a whiteboard. This is the whole method.
| If this is true | It points toward | It rules out |
|---|---|---|
| Related records with strict rules | A relational database, Postgres by default | Document stores chosen for flexibility alone |
| Data cannot leave your infrastructure | Self-hosted components, open models where they fit | Hosted-only tools, however good |
| Small team, broad surface to cover | One language across front and back end | Split stacks that double the context switching |
| Heavy data or model work | Python services, whatever the web layer is | Rewriting mature Python libraries elsewhere |
| Search over your own documents | Postgres with pgvector before a separate database | A specialist vector database as the first move |
| One dominant system to integrate with | Whatever that system's best client library speaks | Fighting a thin or unmaintained library |
Common questions
01Does the tool ever recommend a stack we do not work in?
Yes, and it should. The right stack is the one your team can run. A shortlist that always landed on our preferences would be an advert, not an assessment. Where the answer is a technology we do not build in, we say so.
02Why does scale come last?
Because most systems never reach the volume they were designed for, and the cost of preparing for it is paid immediately. Choose a stack that can be scaled later rather than one that is already complicated in anticipation.
03Is there a single best stack for AI products?
No. Model work pulls toward Python, product work pulls toward whatever your team ships fastest, and the two live happily in one system. Anyone naming one stack for all AI products has not run many of them.
