Matrimony App Development Case Study

The challenge

InscoMont Services had recently entered Indian matchmaking with two products, the Sthal Matrimony application and a second application, Rishta Dobara, that did not yet exist. The Sthal app had been built by another vendor and was not meeting the business, with problems in its design, its flow and its performance, and InscoMont had the domain expertise to say what was wrong but no in-house technical team to fix it. That left them dependent on the vendor who had written the code for every judgement about whether a change was feasible, which is the position in which a consumer product stops responding to its own market. The work therefore had to cover two different things at once, restructuring a live application that already had users, and building a new one from nothing.

The approach

We started by reviewing the existing systems to establish what data sources were actually available, which measures the business intended to run on and where the delivered application diverged from the requirement, and turned that into a written specification rather than a list of complaints. Delivery ran in stages. Quick fixes went out first, so the business team was not blocked while the larger restructuring was designed, and the fuller rebuild followed against agreed scope with dated deliverables. Alongside the applications we handed over the documents that let the client hold the product themselves, functional and KPI specifications, architecture and screen designs, logical and physical data models, acceptance criteria, SQL script and business logic documentation and a user manual, together with a production server with role-based access for business users. After go-live a dedicated team stayed on the product, because a consumer application in its first year generates a continuous stream of behaviour changes and defect reports that have to be turned round in days rather than releases.

The outcome

In the three months after the rebuilt mobile application launched it was downloaded 12,000 times, with a crash ratio of about one per cent, and average active session duration rose as the flow stopped getting in users' way. The administrative side of the product mattered as much as the consumer side; the client's back-office team was able to run its own day-to-day administration without calling the development team for routine changes, which is what actually removes the dependency on a vendor. Because the front end and back end were worked on in parallel during the change-management period, the business logic and interface changes InscoMont asked for as they learned their own market could be released inside the deadlines a live consumer product imposes.

Inheriting somebody else’s application is a different job from writing one, and the temptation is to declare it a rewrite on day one. That would have taken the client’s live product off the market for the length of the rebuild.

What you actually have to establish before touching inherited code

The first question is not what the code does. It is whether the code you were handed is the code that is running. A handover is often a squashed snapshot — one commit called “initial commit” and one called “add all files” — with the change history that would explain any of it gone.

So the review looked for the gap between three things: what the business said it had bought, what the application does, and what is actually deployed. A specification written against the running system is worth more than a list of complaints, because a complaint can be argued with and a divergence cannot.

Why a matrimony product is two matching problems, not one

This is the piece most easily got wrong, and it is worth stating plainly. Browsing and scoring are different questions and they need different machinery.

Browsing is a hard filter: show me approved, active profiles of the right gender, within an age band, a height band, an income band, and within the education, religion, caste and dietary sets I have chosen. Age is the interesting one, because it is not a stored number — it is a window on the date of birth, and computing it any other way goes wrong on the day somebody has a birthday.

Compatibility is a score, and it applies to profiles that have already passed the filter. It weighs how closely a candidate matches stated expectations across the same dimensions, and it has to have an answer for missing data, because an incomplete profile is not the same as a mismatched one.

The trap is holding a user’s criteria twice — once as the filter they browse with and once as the expectations the score is computed against. Two separately editable copies of the same intention will diverge, and when they do the list and the percentage beside each row are answering different questions. If two features describe the same user preference, they should read the same record.

What a back office has to cover before the vendor dependency actually ends

Handing over an administrative console is the deliverable people underestimate, because the dependency does not end when a console exists. It ends when the console covers the changes the business makes routinely.

For this product that meant profile approval with a recorded reason, quick and advanced search, plans and promotional codes, the reports the commercial team runs on payments, boosts, subscriptions and attrition, reported and blocked profiles, system users and their roles, and the reference data a matchmaking business edits most often — religion, caste and sub-caste.

The honest test to apply afterwards is to list every change the client asked for in the following year and count how many needed a developer. Anything hardcoded that a market changes its mind about — the list of acceptable identity documents, the regions a user can search in — is a future support ticket wearing a constant’s clothing.

Why the rename you want is a data migration

Inherited codebases carry misspellings that have hardened into the data contract. A misspelt field name is not a cosmetic problem once it is a column, a collection name, a route path and a key in a mobile client that users have already installed.

Renaming it means migrating the stored documents, shipping a server that accepts both, and waiting for the old app versions to fall out of use. That is a real project, and the correct decision is usually to leave it alone and document it. Tidiness that costs a migration is not tidiness; it is a change of scope.

What made the staged delivery work

Quick fixes went out first, so the business team was not blocked while the larger restructuring was designed, and the fuller rebuild followed against agreed scope with dated deliverables. Fixing the worst of it immediately, documenting the system properly and only then restructuring is slower to describe and faster to arrive.

The documentation and the admin console were the deliverables that ended the dependency, which is the point of building a first product properly rather than shipping something that only its author can maintain.