Over the last few days, we redesigned the Stack Recommender to make it more useful for people who are actually selecting data infrastructure, not just browsing tool rankings.
The goal was simple: if someone is building a modern data stack, ML platform, real-time analytics setup, governance layer, or AI agent stack, the recommender should explain not only what it suggests, but why, how strong the evidence is, and where the integration risks are.
Because "trust us, this stack is good" is not a methodology. It is a horoscope with a pricing page.
One Product, One Workflow
Previously, we had two related experiences:
- Stack Recommender
- Stack Builder
That created unnecessary friction. One page generated recommendations, another page handled customization, and the relationship between the two was not obvious enough.
We merged them into a single canonical experience: /recommend
The flow is now: Choose requirements -> Generate recommendation -> Customize the stack interactively if needed.
The result is no longer a static recommendation page with a separate customization button. The recommendation opens directly into the richer interactive stack view.
Shareable, Restorable Recommendations
Recommendations now use a clean URL format: /recommend?arch=<archetype>&tools=<tool-slugs>
For example: /recommend?arch=modern-data-stack&tools=airbyte,clickhouse,dbt,metabase
This means a user can customize a stack, copy the link, send it to a teammate, and reopen the same configuration later.
Unknown, duplicate, or incompatible tools are ignored rather than breaking the page. The URL is a state container, not a foot-gun.
Better Stack-Level Metrics
The interactive result now puts the main decision signals at the top:
- Stack Score
/100 - Community Health
/100 - Integration Coverage
/100 - Estimated Monthly Cost
The score scales are explicit because a score without a denominator is just decorative math.
Integration Evidence Is Visible
The recommender no longer just says that tools "fit together", but shows which tool pairs have verified integrations and which pairs do not have verified integration evidence in our dataset.
The graph now uses:
- Solid green lines for verified integrations
- Dashed gray lines for unverified integration pairs
Compatibility badges were also rewritten from vague labels such as 'Partial fit' to factual labels like: '2 verified, 1 unverified'
Hovering over the badge shows the actual peer tools involved. That matters because "2 of 3 integrations" is only useful if users know which integration is missing.
Evidence Quality Is Now Explicit
The recommender now reports confidence in the evidence behind the recommendation.
Evidence quality looks at signals such as:
- Source coverage
- Review-backed quality data
- Adoption and community data
- Metadata completeness
- Verified integration coverage
- Role fit inside the selected stack archetype
This score does not replace the recommendation score. It answers a different question: "How strong is the evidence behind this recommendation?"
That distinction matters. A tool can be a strong fit but have weaker public evidence. Another tool can have extensive evidence but be less suitable for a specific architecture.
Editorial Signals Are Part of the Model
The recommender was originally driven mostly by external and structural signals:
- GitHub activity
- Package downloads
- Deployment fit
- Cloud fit
- Budget constraints
- Integrations
- Existing tools
Those signals are useful, but incomplete. They can understate vendors where public repo or package activity does not fully represent enterprise adoption, product breadth, or managed-platform value.
We added more review-page and editorial signals, including:
- Quality score
- Review-backed signals
- Enterprise relevance
- Pricing details
- Pros and cons-derived trade-offs
- Archetype-aware scoring
This is especially important for vendors such as Databricks, where GitHub/package metrics alone do not fully capture lakehouse, ML platform, governance, and enterprise adoption strengths.
Enterprise Fit Became More Explicit
The recommender is now more aware of architecture archetypes.
For example, Databricks should not be treated like a generic storage option in an ML platform recommendation. It has specific strengths around:
- Lakehouse architecture
- Enterprise data platforms
- ML and AI workloads
- Unified analytics workflows
- Governance and platform consolidation
The recommender now has better logic to reflect those cases instead of treating every slot as a popularity contest.
What This Means for Practitioners
Data technology selection is rarely about finding "the best tool" in isolation.
Professionals usually need to answer harder questions:
- Will these tools work together?
- Which tool is strongest for this specific architecture?
- What trade-offs are we making?
- Is the evidence behind this recommendation strong?
- Can we explain this recommendation to engineering, data, and procurement stakeholders?
- Can we modify the stack without starting over?
The redesigned Stack Recommender is meant to support that kind of decision-making. It is now less of a static suggestion page and more of an interactive architecture workspace.
Finally, don't hesitate to check our updated methodology to understand better the details of the evaluation models behind the recommendations.