Blindr- Fall for the words, not the face
A conversation-first dating app built and directed end to end with AI where the photo is the last thing you see, not the first.
Case study
Blindr
A dating app that hides faces behind a live map and a timed conversation designed and shipped solo with AI as a build partner
Role
Product Designer & Builder (solo)
Platform
iOS / Android (Expo, React Native)
Timeline
4 week, May 2026
Tools
Figma, Cursor, TestFlight
Overview
Analysis of exiting dating apps
Tinder
Value proposition: The had a a blind date feature, pair two people in a timed chat before either can see the other's profile or photos; reveal only happens if both swipe right afterward.
Solving our problem? Yes, this is the closest any major app has come to Blindr's exact mechanic, and it worked. Tinder reported a 40% lift in matches versus a normal Fast Chat. But it was launched as a side feature inside Explore, not the core product, and it's no longer something Indian users can reliably find in the app today. (After reading several articles, I think their exit from India’s dating app market in 2022 may have come down to timing. Indian users were still adapting to swipe based dating, making it difficult for a photo free experience that asked people to connect with complete strangers.)
Bumble
Value proposition: Women message first full photos and prompts visible immediately.
Solving our problem? No. Bumble is the default model photos-first, swipe first that Blindr is positioned against, not a competing attempt at the same idea but is one of the most popular app in India.
Happn
Value proposition: Women message first full photos and prompts visible immediately.
Solving our problem? No. Bumble is the default model photos-first, swipe first that Blindr is positioned against, not a competing attempt at the same idea but is one of the most popular app in India.
Tribal
Value proposition: A compatibility-focused dating app that uses a 44-question quiz to understand users. It shows how well two people match across different areas of life, and profiles keep photos blurred while displaying compatibility scores and personality traits.
Solving our problem? Partially. Photos are hidden at first, which is similar to Blindr's approach. However, users can still see compatibility percentages and personality trait scores before any conversation begins. As a result, people can start forming opinions based on numbers rather than interaction. There is no requirement to chat before revealing more information, no countdown timer, and no structured conversation flow. Underneath the hidden photos, it still feels like a traditional swipe based dating app.
Taken
Value proposition: Voice first matching a mandatory recorded voice intro stands in for photos, which stay locked until a mutual match.
Solving our problem? Partially, and closest in spirit. Taken commits hardest to "no photos for strangers" of anything in this set. But it replaces live conversation with a recorded voice clip you swipe on — there's no real-time exchange, no timer, no two people actually talking to each other before the reveal decision.
One thing I'd flag before we finalize this: the Tinder paragraph mixes a verifiable fact (the 40% stat, the Explore placement) with our own speculation (the India-readiness theory). I wrote it with the parenthetical clearly marked as our assumption — keeping that separation visible matters, since presenting a guess as established fact is the exact thing we corrected earlier in this conversation. Want me to soften that distinction further, or is this framing clear enough as-is?
What was missing
Tinder Blind Date: closest attempt, but adds its own friction. Answer an icebreaker quiz, get algorithmically paired, then talk to whoever you're matched with, not someone you actually chose
Bumble / Happn: decision made on photos first, no conversation happens before that judgment at all
Tribal: photo is hidden, but a match score and trait gauges are shown before any talking. The decision is still pre conversation
Taken: photo replaced by a voice clip, but it's still something you swipe on, not someone you talk to
Possible Approach
Talking to someone new shouldn't require this much setup.
It's not about starting a conversation from nothing either. There should be something to go on, a bio, a few interests, something that lets you say something specific to that person, just not a photo or anything that turns the first move into a judgment based on appearance
The match should be the outcome of a conversation, not a gate you pass through to get to one
From this point, the refinement process became much more visual. While Cursor was able to recreate the overall layout and functionality, many of the design details existed only in Figma. To close that gap, I started pulling exact values- spacing, borders, shadows, and other visual specifications directly from the designs and feeding them back into the prompts.
The first decision: presence over profiles
What if, instead of scrolling through a feed of profiles, the user just opened the app and landed on a map?
Not a map of people who were online at some point today. A map of people who are on the app right now, at this exact moment, the same way you would notice someone is actually around when you walk into a room.
That was the starting point. After a short onboarding, the user arrives on a live map. The avatars on it are not a list of matches or recommendations, they are simply whoever happens to be using the app at that same moment, filtered to their preference.
Most apps show presence as a tag, "active," "online," sometimes accurate, sometimes just a label that has not updated in hours. On Blindr, an avatar on the map means one specific thing: that person is genuinely there right now, not at some point earlier today.
The Blindr's tech stack
Language
This had to work on both iPhone and Android, without building two separate apps. That led to React Native, written in TypeScript. One codebase, both platforms.
Database
The map needed to show who else is online, where they are, and whether they match your preference. That's not something the phone alone can know. So this needed a database, which led to Supabase.
Apple Maps
Google Maps
Google Maps charges for use on iPhone. Apple's own map does not. So iOS uses Apple Maps, Android uses Google Maps, purely for that reason. Apple's default style looked a bit plain, fixed with a free custom style file from GitHub.
Describing the journey to AI, and what came back
I described the entire user journey to AI in plain language. Not a flow diagram, just a description of what should happen, step by step. The phone number screen, the OTP, a short profile form, then a map where avatars only show up if someone is actually online and nearby.
The deeper part of the idea was described the same way. Tap someone, send a green flag/request, the other person gets a short window to accept, then a timed blind chat opens. When the timer ends, both people decide if they want to continue. Photos stay hidden the entire time, only unlocking if both say yes.
What came back was a working first version, built directly from that description. It already had the right bones.
What AI built, what I changed
The goal was never to have AI design a finished brand from the first prompt. The first output was meant to prove the mechanics worked, the timer, the reveal, the live presence. Once that was confirmed, the focus shifted to making it feel like something real, a brand, a tone, a reason to trust it with something as personal as a blind conversation.
Welcome screen
AI Built: A plain dark screen. The name Blind Date in pink text, a basic tagline, two flat buttons, and small legal text at the bottom. Functional, but generic, nothing about it said this was a different kind of dating app.
My Changes: A full hero photo of two people back to back, blindfolded, set in a candid, almost editorial moment. A small heart logo above the wordmark Blindr, the same tagline now sitting on top of an actual image instead of empty space, and the same two buttons, now feeling like an entry point into something, not just a form.
Key decisions behind the change:
The name changed from Blind Date to Blindr, shorter, more like an actual app name people would search for or remember
A hero image was added specifically because the entire idea depends on an emotional hook before anyone signs up, an empty dark screen could not carry that
A small heart logo was introduced as a mark that could live on its own, on the app icon, splash screen, and anywhere else the brand needed to show up without the full wordmark
The tagline stayed exactly the same through this change, because the words themselves were never the problem, only the screen carrying them
Phone number and OTP screen
AI Built: A plain dark screen with a heading, "Blind Date," and the tagline directly underneath. A simple input box, a basic "Send code" button, and the OTP screen right after it, just six numbers in a box with a plain "Verify" button. Functional, but with no visual hierarchy, the heading and the input field carried equal visual weight, nothing pulled focus to what mattered.
My Changes: The same flow, restyled with a clear question instead of a flat label, "Can we get your number, please?" with a short line underneath explaining why phone numbers are needed, "to make sure everyone on Blindr is real." The OTP screen became individual number boxes instead of one input field, easier to scan and fill at a glance, with a visible resend timer and a note (The code shown here, 847291, is not a real OTP. It is a fixed code saved in the database purely for testing, so i could log in repeatedly without using up our SMS limit on Twilio.)
Key decisions behind the change:
The layout and components here are standard, phone input, OTP boxes, this is how most apps handle login, and there was no reason to reinvent it. The actual decision was in the copy, explaining why a phone number is needed, instead of just asking for it
Onboarding Flow
AI Built: AI gave a basic, single screen form, name, age, gender, and preference all together, with one "Continue" button. It worked, but it was a generic form, not really thought through as an onboarding experience.(I no longer have that exact screen saved, but a bio field was part of what AI gave us early on.)
My changes: Broken into a proper sequence of screens, one decision at a time, name and birthday, gender and bio, an avatar picker, interest tags, photo upload, and a short screen before landing on the map. We also wanted more than what AI gave us, so a few things were added that did not exist in the first version at all, the avatar picker and the interest tags step being the main two.
Key decisions behind the change:
The avatar picker did not exist in the original output. Since photos stay hidden until a mutual match, this became the only visual identity a user has early on, so it needed its own step.
The interest tags step replaced a blank "describe yourself" box with actual categories to choose from, easier to fill than staring at an empty text field.
Splitting one screen into several made each step a quick decision instead of one long form to get through.
Map screen
AI Built: AI's version only had two states, online or not online, with no in between and no thought for what that wait should feel like. The bottom navigation had three tabs, profile, Discover, and Nearby, but Discover and Nearby did not do anything, the map itself was already the discovery and nearby experience.
My changes: A proper loading state was added for that wait, so it feels like the app is actually searching instead of just stuck. The navigation changed to Home, Chat, and Profile, Home being the map, Chat for matched conversations, and Profile as a real section instead of just a picture with no use.
Key decisions behind the change:
The loading screen makes the search feel alive, instead of a blank pause, to protect the feeling that people on the map are real and active
A backup message was added for when the search takes longer, so it doesn't feel like the app is broken
Discover and Nearby were removed since they did the same job as the map already
Chat was added so conversations have a permanent place to return to
Profile became a real section, since managing your own information was missing before
How map actually runs behind the screen
The heartbeat: Every 15 seconds, the app sends an update to the database saying "I am still here," along with the current location. Online isn't a fixed switch, it's calculated from how recent that last update was. If too much time passes without a new one, the person is automatically treated as offline.
The nearby check happens on the server, not the phone: The app doesn't pull every user and filter on the phone. It calls one function on the database itself, asking for only the people who are nearby, online, and match preference, all filtered before anything is sent back. This same function is also where the two way gender check happens, both people's preferences are checked against each other in that one request.
Refreshing without the user doing anything: The app automatically asks for an updated list every 5 seconds while the map is open. The database can also push a signal the moment someone's status changes, online, offline, or moved, so the map updates right away instead of waiting.
Going offline isn't instant: Sending the app to the background doesn't mark someone offline right away, only after staying away for a while does that happen, so quickly checking a notification doesn't kick anyone off the map.
Overlapping people get spaced out: If two people are at nearly the same spot, the app nudges their pins apart on screen, while their real location stays accurate underneath.
Sending and Accepting request
Suzy's Device
Rohit sees Suzy nearby on the map and sends her a request.
Rohit's Device
The moment Rohit sends that request, it reaches Suzy's device instantly, pushed to her in real time, she does not need to refresh or check anything.
When the chat timer ends and its a Yes
Rohit's Device
Suzy's Device
This is the screen both people see the moment the 5 minute timer runs out that is there in the chat screen.
The mutual continue screen ends with a decision, but the reveal itself didn't have a moment of its own, it just dropped straight into a regular chat with photos already unlocked. Since this is the one moment the entire conversation has been building toward, it felt like it deserved its own screen, not just a quiet change happening in the background.
This screen plays automatically the instant both people choose "Let's go." The same blurred photo cards from the mutual continue screen are reused here, but now they animate from blurred to fully clear, followed by both names appearing underneath. From there, a single button leads into the normal chat, now unlocked, with no timer running.
When the chat timer ends and its a No
When the chat ends and one person chooses not to continue, both people land on a screen, but not the same one. What each person sees is written specifically for the position they're in, not a single generic message reused for both sides.
Rohit's Device
Rohit is the one who tapped "Not this time." His screen reads "Good conversation, wrong person," with "That's not a loss, that's clarity" underneath. This is written for the person making the decision, the conversation wasn't bad, it just didn't lead anywhere, and the copy gives him permission to feel fine about that instead of guilty for ending it.
Suzy's Device
Suzy is the one whose interest wasn't returned. Her screen reads "Not a match," with "It says nothing about your worth" underneath. She didn't make this decision, it was made about her, so the copy is doing the more sensitive job here, softening an outcome she had no control over, without pretending it doesn't sting a little.
Other screens
What this project actually taught me
1
Working on this on my own, from start to finish, felt amazing. Things I thought I'd need a developer for, like how OTP actually reaches a phone, or what tool to use for that without paying anything during testing, I figured out myself. The map was the part I'm most proud of, seeing real people show up live on it, based on where they actually are, without any developer writing that for me. A lot of prompting and fixing went into it, but I got there.
2
I also finally understood something developers always say, that changing one thing can break something else without you realizing it. This happened to me directly. I added an option to upload more photos from the profile page, a screen I built much later. That one change ended up breaking the photo upload step back in onboarding, a totally different screen I hadn't even touched. I used to not really get why developers were so careful about this. Now I do, because I lived it.
3
Working on something this big, by myself, also shifted how I think as a designer. My first instinct used to be the screen, how it looks, how it feels to use. Here, my first question became, how do I actually make this work? Functionality came first, every time. Once something actually worked, that's when I'd go back and spend time polishing the interface, the writing, the small touches that make it feel good to use. That order flipped for me while building this, and I don't think it's flipping back.