Why we built a South Asian dating app with no caste filter.

There is no caste filter on Saath. Not as a feature, not as a premium gate, not as a profile field, not anywhere. It is enforced at the database. Here is what that looks like, and why it had to be that way.

The category most South Asian dating apps still have.

If you open the major existing South Asian dating apps and walk through onboarding, somewhere around the "tell us about yourself" step, the field will appear. Sometimes it is called community. Sometimes background. Sometimes, more honestly, it is just called caste. Below it is a dropdown of two or three dozen options, and a clear filter on the other side: show me only people who are.

Some apps have removed it from the public dropdown but kept it as a back-end signal. Some have hidden it behind premium. Some let parents add it to a child's profile through a "family preferences" doorway. The category persists.

And the reason it persists is not that people are asking for it loudly. It persists because removing it is uncomfortable, and keeping it is the path of least friction. A small percentage of users will leave if the filter goes away. A different percentage will be quietly hurt for as long as it stays. Most product teams pick the side that keeps the revenue chart growing.

Why we picked the other side.

We are building Saath for the diaspora. Most of the people we are building for already left the country where caste was the structural answer to every question. A lot of them carry the inheritance and would like to put it down. A few of them have parents who never will. A small number of them have been told, very explicitly, that they are the wrong category to date.

If we ship the filter, we have decided in advance which of those groups we are willing to lose. The math is straightforward: the people for whom caste filter is the dealbreaker are not the people we want to build a community around. The people for whom no caste filter is the dealbreaker are exactly who we are building for.

So the filter does not exist. And to make sure it does not creep back in through workarounds, we did not just leave it out of the UI. We enforced it at the database.

How we enforce it technically.

This is a product decision, but it is also a code decision, and the code decision matters more. Anyone can write a marketing page that says no caste. We wrote a database trigger.

Here is the rough shape of it. Every time a user updates their bio, their prompts, or sends a direct message intro, a PostgreSQL trigger runs private.first_caste_phrase against the incoming text. That function does three things:

• Normalizes the text. Lowercase, replace hyphens and dashes with spaces, collapse whitespace.
• Strips allowlist phrases. "Caste no bar" and "no caste preference" are allowed: they are how people opt out of the system, not into it.
• Scans for any block phrase on the list, using word boundaries so we do not accidentally catch words that contain the letters incidentally.

If any block phrase is found, the insert or update is rejected with a clear error. The user sees a friendly message ("This kind of community preference is not part of how Saath works") instead of the raw SQL exception.

The list of block phrases is in two places: the client-side code (so we can warn the user before they hit submit), and the database migration (so the trigger has the same list). A unit test parses both files and asserts the lists are identical. Adding a new phrase to one without the other fails CI. The lists cannot drift.

We do the same enforcement on intro messages. Caste-coded language in the very first message someone receives is the worst version of the problem, so the trigger catches it on the way in, not after.

What we do not do.

We do not try to guess caste from surnames, photos, regions, or any other proxy signal. The whole point is to take the category off the table. If a user wants to mention their region or their family tradition in their own words, that is their bio to write. We are not going to make a recommendation engine that learns it implicitly either. The discovery algorithm is built from city, language, age, gender preference, mutual interests, and culture filters that users choose themselves. Caste is not an input, not a hidden weight, not a model feature.

The cost we pay for this.

We will not be the right app for every user. Some people open a South Asian dating app specifically looking for the filter, and they will close ours within a minute. That is the explicit cost.

The smaller cost is engineering: writing the triggers, writing the phrase lists, writing the tests that keep them in sync, mapping the database exceptions back to friendly client-side copy. None of that is hard, but it is real work that other apps just did not do.

The benefit is the community we get to build instead. A community where the question is not which kind, but which person.

One more thing.

This is not the kind of decision we want to be proud of. We would rather it be unremarkable. The goal is for caste filtering on dating apps to feel, eventually, the way redlining feels in housing: like an artifact from a moment we have moved past, that nobody serious in the category would consider reintroducing.

We are not there yet. But this is one of the first apps that just does not have it, and we are willing to be loud about that until the rest of the category catches up.