Why We Push Back on "Just Make It Like [Competitor]"

It's one of the most natural requests in the world: a client points at a competitor's product and says, "just build us something like that." It's an understandable starting point - a competitor's app or site is tangible proof that something works, and it's a lot easier to point at than to describe from scratch. It's also, more often than not, the wrong brief to build from. Here's why we push back on it, and what we ask for instead.

You're Seeing the Result, Not the Reasoning

What a competitor shipped is visible. Why they shipped it that way almost never is. A feature might exist because of a specific technical constraint they were working around, a business decision that made sense for their scale but not yours, or a legacy choice they'd change today if it weren't expensive to unwind. Copying the visible result without the reasoning behind it means inheriting decisions that may not fit the problem you're actually solving.

We've built products for clients who wanted to replicate a competitor's checkout flow, only to find - once we actually mapped it - that the flow made sense for a business with a completely different order volume and return policy. What looked like a best practice was really a decision shaped by circumstances that didn't apply.

"Like Them" Usually Means Several Different Things at Once

When a client says "like [competitor]," they're rarely pointing at one specific thing. It might be the visual polish, a particular feature, the overall speed of the experience, or just a general sense of professionalism the competitor projects. These are different problems with different solutions, and treating them as one instruction to copy produces a worse outcome than addressing each one directly. Part of what we do early on is pull apart what "like them" actually means in concrete terms - is it the checkout speed, the visual design,the onboarding flow - because the fix for each is different.

Competitors Aren't Solving Your Constraints

A competitor's product reflects their budget, their team size, their existing tech stack, and their specific user base - none of which are yours. A feature that works well for a company with a large support team to handle edge cases may not translate to a smaller operation without that safety net. Building "like them" without accounting for what's actually different about your business means building something that looks right and doesn't fit.

It Can Lock You Into Someone Else's Roadmap

Products evolve. If the target is "match what they have today," that target moves the moment the competitor ships their next update - and chasing a moving target is a losing position, not a strategy. We'd rather build toward what your users specifically need, which doesn't shift every time a competitor changes their product, than aim at a snapshot that's already out of date by the time development finishes.

What We Ask Instead

When a competitor comes up as a reference point, we treat it as useful information, not a spec. We ask what specifically about their product is working for the client's own users, what problem it's actually solving, and whether that problem exists in the same form for the client's business. From there, we design toward the actual need - sometimes that lands somewhere similar to the competitor's approach, and sometimes it doesn't, because the right solution for a different business with different constraints often looks different once you build it from the problem instead of from the reference.

Where Competitor Research Still Genuinely Helps

None of this means competitor products are irrelevant - they're often useful for understanding what users already expect, spotting gaps a competitor hasn't addressed, or validating that a general approach works in the market. The distinction is using a competitor as one input into a decision versus using them as the decision itself. The first makes a product better. The second just makes it derivative.