Matrimony Apps
How Kundli Matching Is Implemented and Tested in a Matrimony App
Kundli matching in a matrimony app is a deterministic calculation: take two sets of birth data, compute each person's Moon position with an astronomical ephemeris, derive the nakshatra and rashi, apply the ashta koota rules to score up to 36 points, then run the manglik and dosha checks the client's tradition uses. The hard parts are not the arithmetic. They are getting birth data and time zones right, agreeing which tradition's rules apply, testing against charts an astrologer has already verified, and handling horoscope data as the sensitive personal data it is.
Quick answer: A matrimony app computes kundli matching by converting both birth data sets to UTC and coordinates, computing Moon positions with an ephemeris, deriving rashi and nakshatra, scoring the eight kootas out of 36 and applying the manglik and dosha rules of the tradition the client specifies, all tested against astrologer-verified reference charts.
- Inputs: date, time and place of birth for both people, converted to UTC and to geographic coordinates.
- Engine: Swiss Ephemeris or an equivalent ephemeris for planetary and Moon positions; a sidereal ayanamsa such as Lahiri unless the client specifies another.
- Score: eight kootas (Varna 1, Vashya 2, Tara 3, Yoni 4, Graha Maitri 5, Gana 6, Bhakoot 7, Nadi 8) adding up to 36.
- Checks: manglik status for each person, Nadi and Bhakoot dosha, and the cancellation rules the tradition allows.
- Testing: unit tests against reference charts verified by an astrologer the client nominates, plus property tests for time-zone and boundary cases.
- Privacy: horoscope data collected with separate consent, stored encrypted, shown only under the profile owner's visibility settings.
In this article
Birth data and time zones
Most wrong results come from the input, not the maths. A matrimony app collects date, time and place of birth, and each has a trap. Time is entered in local time, so the app must convert it to UTC using the time zone that applied at that place on that date, including historical offsets; a 1975 birth in Coimbatore and a 1998 birth in Dubai are not both IST. Place is a city name typed by a parent, so it is resolved to coordinates with a geocoder and shown back for confirmation. Unknown birth time is common; the app records it as unknown and computes what it can (rashi and nakshatra from a noon Moon position, with a flag) rather than inventing 12:00.
- Store the original local entry, the resolved time zone and the UTC instant separately, so a correction is auditable.
- Validate ranges (a date in the future, a time of 24:30) at entry, not at matching time.
- Let the profile owner mark birth time as approximate or unknown; the result screen carries that flag through.
Ephemeris and ayanamsa
The Moon's longitude at the birth instant gives the rashi (sign) and nakshatra (one of 27 lunar mansions, each 13°20′, divided into four padas). We compute it with Swiss Ephemeris or an equivalent ephemeris, in sidereal coordinates. Sidereal means subtracting an ayanamsa from the tropical longitude; Lahiri is the usual default in India, and others (Raman, KP) exist and give different nakshatras near boundaries. The ayanamsa is a configuration value, agreed with the client, never hard-coded.
Swiss Ephemeris is dual-licensed (AGPL or a commercial licence); a closed-source matrimony app needs the commercial licence, which we scope into the proposal. The positions are cached per profile: birth data does not change, so the Moon position, rashi and nakshatra are computed once at profile save and stored, and matching reads them.
The eight kootas
Ashta koota matching compares the two Moon positions on eight factors with fixed maximum points that total 36. The tables for each koota are standard and small; we keep them as data, not code, so a client can review them with their astrologer.
- Varna (1). Compares the rashi-based varna of bride and groom.
- Vashya (2). Mutual influence by rashi group.
- Tara (3). Counts nakshatras from one to the other, both directions, and scores on the remainder modulo 9.
- Yoni (4). Compatibility of the animal symbols assigned to the 27 nakshatras.
- Graha Maitri (5). Friendship between the rashi lords.
- Gana (6). Deva, Manushya or Rakshasa temperament by nakshatra.
- Bhakoot (7). Relative position of the two rashis; some positions (2/12, 5/9, 6/8) score zero and raise Bhakoot dosha.
- Nadi (8). Adi, Madhya or Antya by nakshatra; the same nadi scores zero and raises Nadi dosha.
The commonly used bands are below 18 not recommended, 18 to 24 acceptable, 25 to 32 good and 33 to 36 excellent. These are conventions, not law; the client decides the bands and the wording families see.
Manglik and dosha checks
Manglik (Kuja dosha) is checked from Mars's house position counted from the Lagna, the Moon and, in many traditions, Venus: Mars in houses 1, 2, 4, 7, 8 or 12 marks the chart as manglik, with the second house included in South Indian practice and excluded in some North Indian readings. That alone shows why the rule set has to be configurable. Cancellation rules are more varied still: both partners manglik, Mars in its own or exalted sign, specific aspects, and others depending on the school. Nadi dosha and Bhakoot dosha also have exceptions, for example the same nadi with different nakshatras or the same rashi.
We implement the rules the client's astrologer specifies, list every exception in a configuration file the astrologer signs off, and show in the result which rule fired. We do not pick a school for the client.
Configuration per tradition
Everything that differs between traditions is configuration: ayanamsa, chart style (South Indian, North Indian, East Indian) for display, whether the Moon chart or the Lagna chart drives manglik, which houses count, which cancellations apply, the score bands, and the labels shown in Tamil and English. A community platform can carry more than one configuration and apply the one that matches the profile's community. The configuration is versioned, so a rule change is dated and old results can be recomputed on request.
How we test it
Before build, the client nominates an astrologer who supplies reference pairs: birth data for two people and the expected rashi, nakshatra, koota-by-koota points, total, manglik status and dosha verdicts. Those become unit tests; a build does not ship if any reference pair fails. On top of that:
- Boundary tests at nakshatra and rashi edges, where a different ayanamsa flips the result, to confirm the configured ayanamsa is applied.
- Time-zone tests: births near midnight, during historical offset changes, and in places east and west of India.
- Property tests: the score is symmetric where the rules say it should be, totals never exceed 36, and unknown birth time never produces a Lagna-based verdict.
- A regression set of anonymised real pairs, re-run on every ephemeris or configuration change.
The test report is handed over with the code, so a future developer can see what the client's astrologer agreed to.
Showing the result in the app
Families do not want a table of eight numbers. The profile card shows the total (for example 28/36), the manglik status of both, and a one-line verdict in the band wording the client chose; a detail screen lists each koota with its points and a short explanation, highlights any dosha and the cancellation that applied, and offers a shareable PDF for the family astrologer. Where the tradition uses full chart compatibility beyond ashta koota, the detail screen includes both charts in the configured style. A profile owner controls whether their horoscope is visible at all; a match score is shown only when both sides allow it.
Privacy and performance
Birth date, time and place identify a person and reveal religion and community, so horoscope data is collected with its own consent step, stored encrypted, excluded from search indexes, and deleted with the account. Computation happens on the server, never by sending birth data to a third-party astrology API unless the client chooses one and its data terms are reviewed. Because positions are cached at profile save, scoring a pair is a table lookup, and a daily recommendation run for tens of thousands of profiles completes in minutes on a single worker.
This is the same engine we describe on our matrimonial app development page and build for Coimbatore bureaus and communities; the cost of adding it to a platform is in the matrimony app cost guide.
FAQ
What is the maximum score in kundli matching?
36 points, from eight kootas: Varna 1, Vashya 2, Tara 3, Yoni 4, Graha Maitri 5, Gana 6, Bhakoot 7 and Nadi 8. Commonly used bands treat under 18 as not recommended, 18–24 acceptable, 25–32 good and 33–36 excellent, though the client sets the bands shown in the app.
Which ephemeris and ayanamsa does a matrimony app use?
Swiss Ephemeris or an equivalent ephemeris for the Moon and planetary positions, with a sidereal ayanamsa; Lahiri is the usual default in India and others such as Raman or KP can be configured. The ayanamsa changes results near sign and nakshatra boundaries, so it is agreed with the client's astrologer and tested at those boundaries.
How is manglik dosha checked in software?
By Mars's house position from the Lagna, the Moon and often Venus: houses 1, 2, 4, 7, 8 and 12 mark manglik, with the second house included in South Indian practice. Cancellation rules vary by school, so they are kept in a configuration the client's astrologer signs off, and the result shows which rule fired.
How do you test kundli matching before launch?
The client's astrologer supplies reference pairs with expected rashi, nakshatra, points per koota, total, manglik status and dosha verdicts; they become unit tests that must pass on every build, alongside time-zone, boundary and property tests and an anonymised regression set.
Does adding kundli matching change the cost of a matrimony app?
Yes. It is an optional module on our matrimony platforms; the cost guide puts it at roughly ₹1–2.5 lakh on top of the MVP, depending on chart styles, ayanamsa options and report generation, plus the Swiss Ephemeris commercial licence where the app is closed source.