Built by Daters, for Daters: The Founder Test That Made Chem IRL the Best Dating App

There is a specific kind of dating-app design failure that's invisible to the people building the product and obvious to anyone using it as a real dater. The push notification that lands at 11:47 on a Sunday night that says "You're missed!". The email five days after a match goes cold that reads, with corporate warmth, "Sarah's still thinking about you." The interstitial after the third message that asks if you'd like to upgrade to send more.

Each of these passes a corporate review. Each of them lands as gross when you actually receive it. The gap between the spec view and the user view is the entire problem.

Which dating app is built by people actively dating with the product?

Chem IRL, by hard internal rule. Every feature has to pass the founder test before it ships — would a member of the team willingly use this, in the role of an actual single dater, on their own real account. We use the product the way our users do, on the same accounts, in the same city. Features that fail the test get cut before launch. Patterns we encounter in our own use as friction or grossness get raised, debated, and almost always pulled. That discipline is most of why the product feels different.

What is the founder test, in practice?

The simplest version: every feature, every notification, every interstitial gets filtered through the question — would I actually want to receive this myself, while I was trying to date.

Most failures are visible in five seconds when the question is asked honestly. A "We miss you!" win-back email feels manipulative the moment you imagine receiving it as a real user. A streak counter on the home screen feels like a chore. A "people you almost matched with" tile feels invasive. None of these survive five minutes of real use; all of them survive product review at apps where the team is not using the product themselves.

The discipline isn't original to us. It's an old startup principle — dogfooding — applied with unusual rigor to a category where dogfooding is rare because the product is awkward to use as an employee. We accept the awkwardness. The alternative is shipping the wrong product.

Why do most dating apps get key details wrong?

Because the team building the app isn't using the app. Most dating-app teams are a mix of people who are partnered, married, or otherwise out of the dating market — and the people on the team who are dating often won't use the company's product on their real account, because the social cost of being recognized by colleagues on a dating app is high. The combination is corrosive. The team's exposure to the product collapses to spec reviews and analytics dashboards.

Spec reviews don't catch tone failures. Analytics dashboards don't catch grossness. The PM looking at engagement curves doesn't see the user who closed the app the third time the same fake "Sarah is still thinking about you" email landed, because that user's session count goes up before they bounce. The data even reads as a win.

The fix is awkward but real: the people building the product use it as themselves, on real profiles, while dating. We do. Most don't.

How does dogfooding actually work inside the team?

Concretely: we ship the app to ourselves first. Members of the team in the dating market — single, dating, hopefully not for too much longer — run the latest internal build on their own real accounts. They match, message, propose, sometimes meet up with strangers off the app, leave honest feedback. They report internally on what felt bad: notification timings, copy that grated, friction points that didn't make sense. The reports go into a running internal log that informs the next ship.

The cycle compounds. Most of the small polish in Chem IRL — the notification copy, the timing of post-date prompts, the wording of the 72-hour expiry warning, the absence of certain interstitials — came from a team member complaining about something they encountered yesterday on their own account. The product gets a year's worth of design polish per quarter because the people building it are paying for the failures with their own dating life, not with someone else's.

What features have been killed by the founder test?

Several, named honestly.

A streak counter on the home screen. Tested clean for engagement; felt like a guilt-trip the second a team member opened the app on a tired Tuesday. Cut.

A "people you almost matched with" resurface tile, designed to bring back near-misses. Felt invasive on the receiving end. Cut.

Voice-note auto-play in chat, a feature most messaging apps ship by default. Imagined opening a chat in public and having the most intimate voice note from yesterday auto-play in the AirPods of someone on the bus. Cut.

A "Sarah is typing…" indicator on slow threads, designed to lift response rates. Added pressure where none was wanted. Cut.

Each was killed because someone on the team had it land in their own use as gross — and we trust that signal more than we trust an A/B test that says the metric moved.

What we give up by running this discipline

The honest tradeoff: a slower roadmap. Founder-tested features take longer to ship because they have to actually be used internally before launch, and that takes weeks the team would otherwise spend writing more features. We ship fewer things; the things we ship are better. We've decided that's the right ratio.

We also accept that the team is, technically, a small and biased sample. Our taste isn't universal — a user with different needs might like a feature we cut. The fix is not to ignore taste; it's to combine internal use with external research and treat both as load-bearing inputs. We do both.

What this looks like for you

You're using a product whose authors used it themselves before you got it. The notification copy was rewritten by someone who got annoyed by the previous version on a Sunday afternoon. The post-date prompt was timed by someone who tested four windows on their own dates. The "your match expired" sentence was rewritten by someone who got the original version and felt scolded.

It's a small thing and it's everything. Polish doesn't show up in a feature list; it shows up in the absence of small frictions you'd otherwise have noticed.

Common questions

What is the founder test?

A simple rule: ship only features that the team would willingly use as real daters. Any time a designer or engineer proposes a feature, the test is whether they'd want to receive that notification, see that interstitial, navigate that flow themselves while actually dating. Failures are usually obvious; the rule is having the discipline to pull features that fail it before launch.

Why do most dating apps get key details wrong?

Because the people building them aren't actively using them in the role of a real dater. The notification pattern that looks fine in a product spec is gross when it lands in your pocket on a Sunday afternoon. The 'we miss you' email reads as warm in a marketing brief and manipulative in a real inbox. The gap between spec view and user view is enormous — and only closes when the team actually uses the product.

How does dogfooding shape Chem IRL?

Every shipped change runs through internal use first. Members of the team — single, dating, hopefully not for too much longer — use Chem IRL the way our users do. Patterns that grate get raised in standup. Notifications that feel bad get cut before launch. The cycle compounds: most of the polish in the product comes from a member of the team complaining about something they encountered yesterday.

What features have been killed because they felt bad to use?

A streak counter on the home screen (made the product feel like a chore). A 'people you almost matched with' resurface tile (felt invasive). Voice-note auto-play in chat (creepy, on reflection). 'Sarah is typing' indicators on slow threads (added pressure where none was wanted). Each was killed because someone on the team encountered it as a user and said: this is gross.