HomeHow this list gets made
Principles
Six layers, four tools each. The reasoning behind the curation rules, spelled out.
PyStack has six stack layers, four tools in each. Three foundation model categories, three models apiece. Six Agent Skills. Those numbers are a constraint, chosen on purpose and kept that way as the lists change.
A short list is a decision
A long list of tools is closer to a search result. It hands you fifteen options and calls that help. A short list means someone already did the comparing and is willing to stand behind the outcome. Four slots per layer forces a real choice: something has to be the fourth pick, and something else has to miss the cut. Without a hard limit, PyStack turns into another directory, and there are enough of those already.
What earns a slot
Three things, checked in order. It has to have been used in a real project, not just read about. It has to still be maintained, with recent commits, issues that get answered, and docs that track the current API. And it has to solve a problem the reader actually runs into.
None of that is exotic. Most tools that miss the list miss on one of these, usually maintenance. A library can be technically excellent and still get cut because nobody is driving it anymore.
What gets cut
Popularity gets a tool noticed. It doesn't get it included, because GitHub stars measure attention, and attention is easy to buy with a good README and a launch thread. Being new gets a tool a look for the same reason, and tells you nothing about whether it holds up past the first week of use.
The harder cases are the tools that are genuinely good but redundant. When two libraries solve the same problem at roughly the same quality, only one goes on the list. Ties get broken by whichever one has actually shipped in something real.
Show the reasoning, not just the verdict
Every pick comes with a note on why it was chosen and what it beat out. That part is deliberate. A bare list of names asks you to trust a stranger's taste, where a list with reasoning lets you check the logic and push back on it if your situation differs from mine. Disagreeing with a pick should be an argument about the reasoning.
The lists move
Nothing here is permanent. A tool that earns its slot today can lose it in six months if a competitor overtakes it or maintenance quietly stops. Churn like that is expected. A static "best of" list from a year ago is usually wrong by now, and PyStack tries not to be.
What this isn't
This is one engineer's judgment, shaped by the kind of work I do: mostly fintech and open banking, mostly Python, mostly things that had to run correctly the first time. It isn't a survey and it isn't a vote. If your stack looks different because your constraints are different, that's expected. The goal was never to be neutral. It was to be honest about the reasoning, so you can tell where it does and doesn't apply to you.