DEV Community

CinfiniteDev
CinfiniteDev

Posted on

Copying Is Inevitable. Copying Flaws Is Not.

Hey Folks ,

So, I wrote about Ola Web's cramped map a while ago.

A bookmarklet. A quick fix. A story about small UX gaps that ship.

Then I opened Uber's web app.

And I had to blink.

Same layout setup. Same cramped map. Same missing fullscreen button. Same nothing-you-can-do-about-it.

At first I laughed. Then I looked closer.

There are PMs defining requirements. Engineers writing code. Managers running sprints. Leadership setting vision. Hundreds of people, day in and day out, building this thing.

And this is what ships.

A map you can't expand. No fullscreen. No resize. In a product where the map is the main interface.

It makes you wonder — what are we all doing? Where is the meaningful work, the high impact, high stakes, high ownership — the craftsmanship everyone talks about? What happened to engineering? Not the process — the craft.

This needs to move beyond talks. Beyond tweets. Beyond "we'll fix it in the next sprint." Real execution. Real attention to what ships. Not because someone asked — but because we should care enough to notice.


Two Apps. Same Flaw.

Ola Web Uber Web
Map cramped? Yes Yes
Fullscreen button? No No
Resize option? No No
Bookmarklet that fixes it? Yes Could be — approach is the same

This isn't about picking on either company. It's about a pattern.


The Uncomfortable Truth: We Copy Flaws Too

Competitive benchmarking is standard practice. You look at what the competition does, and you build something similar. Faster. Better.

Except sometimes "similar" means "identical" — flaws included.

Here's how it happens:

It doesn't matter who shipped it first. What matters is that two independent teams arrived at — or converged on — the same constraint.

Maybe one team saw the other and replicated it. Maybe both teams used the same SDK or design system that imposed the layout. Maybe both faced the same deadline pressure and made the same cut.

Either way, the result is the same:
Two codebases. Two teams. One identical UX gap.

Nobody copied a feature. They copied a constraint.


Why This Slips Through

Feature parity is usually measured in terms of what exists, not how well it works.

  • "Does Uber have a map?" → Yes. ✅
  • "Does it work?" → Technically yes. ✅
  • "Is it actually comfortable to use?" → ...❌ Nobody blocked release for comfort. But comfort is what users feel every time they open the app.

The Same Kind of Fix Works for Both

The bookmarklet I built for Ola follows a simple pattern: inject a toggle button, find the map container, expand it.

The flaw is the same. The fix category is the same. That's what matters.


How to Break the Pattern

There's nothing wrong with looking at competitors. But here's what to do differently:

1. Ask "why" before "what"
Don't just replicate the UI. Understand the constraint that produced it. Was it a deadline? A technical limitation? A design compromise?

2. Check if the UX is actually good
If your competitor's feature feels cramped, janky, or incomplete — that's not a feature, that's a problem. Don't inherit it.

3. Improve, don't imitate
The goal of looking at competitors is to build something better. If you're building the same thing with the same flaws, you're not competing — you're cloning.

4. Add friction checks to your QA
Alongside your regular testing, ask:

  • "Is this actually comfortable to use?"
  • "Would I want to use this every day?"
  • "Did we copy this from someone who also cut corners?"

The Bigger Pattern

This isn't about maps. It's about how the industry converges on mediocrity.

When every team copies from every other team, and nobody stops to ask if the thing being copied is actually good, flaws spread like bugs. They become the baseline. They become "how it's done."

And users just accept it — because both apps have the same problem, so where else is there to go?


What You Can Do

If you're building a product:

  • Audit one feature your team copied recently
  • Check if the original had flaws you inherited
  • Fix it — even if the original still has the problem

If you're a user:

  • Call it out
  • Build tools like bookmarklets if you can
  • Don't assume "everyone does it this way" means it's right

Takeaway

Copying is somehow inevitable in the industry.

But copying flaws is how we move sideways.

The next time you look at a competitor's feature, don't ask "can we build this?"

Ask: should we?


Top comments (0)