Back to notes

February 23, 2026 · 4 min read

A Face Recognition Feature We Said No to Building

A client wanted facial recognition for a 'frictionless' retail experience. The technical ask was straightforward. The ethical case against it wasn't close.

Hot TakeEthics

The pitch was simple and, from a pure engineering standpoint, entirely doable: facial recognition at store entry to recognize repeat customers and pull up their profile and purchase history before they reached a register. 'Frictionless.' 'Personalized.' The kind of feature that sounds great in a product roadmap slide and terrible the moment you imagine explaining it to the person walking in the door who never consented to being scanned.

Why this wasn't a close call

Facial recognition in a physical retail space, applied to every person who walks in regardless of whether they're a customer or just passing through, collects biometric data from people who have no meaningful way to opt out short of not entering the store. That's a fundamentally different consent model than anything else in the client's stack — nobody browsing a website gets tracked without at least the theoretical option of a cookie banner. Walking past a storefront isn't consent to anything.

A frictionless experience built on biometric surveillance isn't frictionless, it's just invisible to the person paying the actual cost.

We said no, in writing, with the reasoning spelled out rather than a vague 'we recommend against this.' We also didn't just decline — we proposed an alternative that got most of the business value without the biometric collection: an opt-in loyalty app with Bluetooth beacon detection, which required active, informed consent and gave the same personalization benefit to customers who actually wanted it.

  • Biometric collection of non-consenting bystanders is a different category of risk than almost any other data practice, and should be treated as such explicitly.
  • Declining a feature is more credible with a documented reasoning and a concrete alternative, not just a refusal.
  • 'Technically feasible' and 'should be built' are different questions, and conflating them is how a lot of bad features ship.
  • The regulatory and reputational downside of getting this wrong usually dwarfs the upside of the feature itself.

The client took the loyalty app alternative. It took longer to build and had a smaller addressable rollout since it required opt-in. It also didn't put us in the position of having built a surveillance system and called it personalization, which is a trade I'd make every time.