A matrimony platform lives on whether its profiles are real. Matching is the visible feature and verification is the one that decides whether any match is worth acting on — and both have to work while handling the most personal data a consumer product ever asks for.
WedsIn was built front to back: the website, the application and the backend behind both, with profiles, matching and verification as one system rather than a front end assembled on top of somebody else's service.
Verification is the feature
Every matrimony platform shows profiles. The difference between them is how much work went into establishing that the person behind one exists and is who the profile says. That work is unglamorous, largely invisible in the interface, and the single thing users are actually paying for.
Matching is a preference problem, not a search problem
Search returns what was asked for. Matching has to weigh criteria that contradict each other, that families and individuals disagree on, and that people state differently from how they choose. Modelling preference as ranked and weighted rather than as filters is what stops the result set collapsing to nothing.
Owning the backend
Profiles, matching, verification and messaging share the same data and the same privacy obligations. Building them together — rather than as a front end over a third-party service — is what keeps that data in one place with one access model, which is the only arrangement defensible for this category of information.