How to Push Back on an Unfamiliar Tech Stack Recommendation

A developer or agency recommends a piece of technology you’ve never heard of. Maybe it’s a database, a framework, or a specific platform. Your instinct might be to defer entirely — they’re the expert, after all. But an unfamiliar recommendation deserves a real conversation, not automatic approval or automatic rejection. Here’s how to handle it well.

Unfamiliar Doesn’t Mean Wrong

It’s worth saying plainly: a technology you’ve never heard of isn’t inherently a bad choice. New and specialized tools exist because they solve real problems better than the well-known alternatives in specific situations. Dismissing every unfamiliar suggestion out of caution can push your team toward safe-but-suboptimal choices just to avoid an uncomfortable conversation.

The goal isn’t to insist on only using technology you recognize. It’s to make sure the recommendation is reasoned, not reflexive — and that you understand enough of the trade-off to be comfortable living with the consequences.

Why Pushing Back Is Reasonable

You’re the one who will depend on this product working, who will pay to run it, and who will need to hire around it later if the relationship with this developer ever ends. Those are legitimate reasons to ask questions about a decision you’ll be living with long after the recommendation is made — even if you can’t personally evaluate the technical merits.

How to Push Back Constructively

Start with genuine curiosity, not confrontation. “Can you walk me through why this fits our product better than something more common?” invites a real answer. “Why would you use something so obscure?” invites defensiveness. The information you get back is often better with the first framing.

Ask what problem it solves that a more familiar option doesn’t. Every legitimate unfamiliar recommendation should map to a specific requirement of your product — not general enthusiasm for the tool.

Ask about the downside, specifically. Every technology choice has a cost somewhere — smaller hiring pool, less mature documentation, higher hosting cost, steeper learning curve for whoever maintains it later. A developer who’s thought it through can name the downside without being pushed. One who can’t may not have weighed it seriously.

Ask what happens if this developer or team is no longer available. Could another developer reasonably pick up the codebase? If the honest answer is “probably not easily,” that’s a real, quantifiable risk worth weighing against whatever benefit the unfamiliar tool provides.

Get the reasoning in writing, briefly. Not a contract clause — just a short summary in an email or doc: “we’re using X because of Y, and the main trade-off is Z.” This isn’t about distrust; it’s about having a record you can revisit if the decision becomes a problem later, and it tends to sharpen the reasoning on both sides.

Questions That Separate Sound Reasoning From a Weak Justification

You ask	Sound reasoning sounds like	A weak justification sounds like
Why this over something familiar?	Specific technical requirement it solves	“It’s better” / “it’s more modern”
What’s the downside?	Names a real trade-off clearly	Insists there isn’t one
What if you’re not available later?	Explains handoff or documentation plan	Brushes off the question
Has your team used it before?	Direct answer, with context	Vague or avoided

When to Actually Push Back Harder

• The justification is entirely about the tool’s reputation, not your product’s needs. “It’s what everyone’s moving to” isn’t a reason connected to what you’re building.
• The team has no direct experience with it. Recommending something they’d be learning on your project, without disclosing that, is a bigger risk than the technology itself.
• You sense the recommendation serves their interest more than yours — for instance, a tool that happens to be great for their portfolio or resume but adds complexity you don’t need. This is uncommon, but worth naming as a possibility if the reasoning feels thin.

If any of these apply, it’s fair to ask for a more mainstream alternative, or a second opinion, before proceeding. For the broader set of questions to bring into this kind of conversation from the start, see Technology Selection Questions to Ask Before Hiring a Development Team, and if the specific debate is REST vs GraphQL or another architecture-level choice, our post on REST API vs GraphQL for Your MVP shows what a well-reasoned version of that conversation looks like.

The Bottom Line

Pushing back on an unfamiliar tech stack recommendation isn’t about distrust — it’s about making sure the reasoning behind a decision you’ll live with is sound, and that the trade-offs are visible rather than hidden. A good developer welcomes this conversation because it’s exactly the kind of scrutiny that produces better decisions. If a team resists a respectful “help me understand why,” that reaction tells you more than the technical answer would have.

Frequently Asked Questions

Is it okay to question a developer's technology recommendation?

Yes. Asking for the reasoning behind a recommendation is a normal, healthy part of working with a development team — it's not the same as second-guessing their technical expertise.

What if a developer can't justify why they chose an unfamiliar technology?

That's a legitimate reason for concern. A confident, experienced developer should be able to explain their reasoning in terms connected to your product, not just assert that it's the right choice.

Should a founder insist on familiar, mainstream technology only?

Not necessarily — sometimes a newer or less common tool is genuinely the right fit. The goal isn't to force familiarity, it's to make sure the reasoning is sound and the risks are acknowledged, not hidden.