Redesigning the Stack Recommender: From Static Suggestions to Interactive Architecture Decisions
How Modern DataTools redesigned Stack Recommender with interactive customization, shareable URLs, evidence quality, integration visibility, and clearer methodology.
EB
Egor Burlakov
••4 min read
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.
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.
EB
Written by Egor Burlakov
Engineering and Science Leader with experience building scalable data infrastructure, data pipelines and science applications. Sharing insights about data tools, architecture patterns, and best practices.
Explore Further
Dive deeper into the tools and categories mentioned in this article.
