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.
Toggle for a quick summary or the full breakdown
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
Blindr is a conversation first dating app where photos stay hidden until both people have actually talked. You go live on a map, send an anonymous request to someone nearby, talk for 5 minutes with no photos visible, then both people choose together whether to see each other at all.
The idea isn't new. A handful of apps have tried versions of "talk first, see faces later" some lean on blurred photos, some on voice notes, some on async card-swiping. What's different about Blindr is in how those pieces fit together, and where the lines get drawn on trust, rejection, and timing. That comparison, and the reasoning behind each decision, is what the rest of this case study walks through.
Problem
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
The Idea
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.
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.)
Connect to Content
Add layers or components to swipe between.
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
Check out other AI-built products.
Habit me
This was my first attempt to actually build something on my own through AI. It is an app to store pictures and categorise them.
Cursor
React Native
Mobile app
Oops, looks like you're on mobile. Sorry for the inconvenience. This portfolio is designed for desktop for now.
Oops, looks like you're on tablet. Sorry for the inconvenience. This portfolio is designed for desktop for now.