Putting Maharashtra’s co-operative housing law into the software

A housing society looks like a small community. Legally, in Maharashtra, it’s a co-operative society with a statute, model bye-laws, a registrar and a long tail of court rulings. Most society software ignores all of that and gives you a spreadsheet with nicer fonts. We read the rules first.

Before building V2 we wrote four research briefs — on units and billing, building spaces, unit merges and real amenity rulebooks from societies in Pune, Mumbai, Hyderabad and Kolkata. Every claim that rested on a secondary source is marked [uncertain] in the brief, and where the product depends on one, the docs say so. Here’s what made it into the code.

Not every charge is billed the same way#

A maintenance bill isn’t one number. It’s a set of charge heads, and the law says how each may be computed. ViharSync supports exactly three billing bases:

The interesting one is the rule that a co-operative housing society may not bill service charges per square foot. Condominiums can; a CHS can’t. So the society’s legal form is part of its data, and when a CHS tries to create a per-square-foot service-charge head, the API refuses with a specific error rather than quietly allowing it. (This rule is flagged in our docs as pending verification against primary sources — we’d rather say so than pretend.)

Interest, capped and cited#

Societies may charge interest on arrears — but only simple interest, only on overdue principal, at most 12% a year, and only if the General Body passed a resolution for it. In ViharSync, those aren’t guidelines in a help article; they’re database constraints. The rate can’t exceed 1,200 basis points, and a non-zero rate can’t be saved without the resolution reference. That reference is printed on every bill line that charges interest.

Payments settle interest before principal, so interest never earns interest. It sounds pedantic until you’ve sat through an AGM argument about it.

Notices need proof; complaints need clocks#

Two things the bye-laws care about live today in WhatsApp groups, where they can’t be proven. We built replacements for exactly those two.

Notices with acknowledgement. When a notice needs it, each member’s acknowledgement is timestamped. That record is the proof of service, and the committee can see who has and hasn’t acknowledged.

A complaint register with statutory clocks. Complaints are numbered like C/2026-27/0001. The committee must acknowledge within 3 days and decide within 15 — or 7 for urgent categories like leakage, lifts, electrical and security. Overdue flags are computed when you read the register, not by a scheduler that might not run. Resolving or rejecting needs reasons, and a resident can reopen within 7 days of the decision.

A unit number is a legal identifier#

Our first “generate units” dialog assumed flats are numbered floor × 100 + n. Committees couldn’t map their real buildings onto it. Real buildings have stilts, podiums, refuge floors, shops with their own number series and ground floors labelled G01 or 001. So V2 has a building builder, and three rules from the research shape it:

• Unit numbers are stored exactly as typed. “A-101” and “A101” may be different legal flats.
• Parking, gyms and refuge areas are not units — they’re never billed. Parking is an allotment, not property, a point the Supreme Court settled in 2010.
• Merged flats are closed, never deleted, because their history still matters to the books.

The gate has rules too#

Not everything is statutory. Some rules are just about respecting people. A guard sees a flat’s phone numbers only while a walk-in visitor is waiting for approval, so guards never end up with a phone directory. If nobody answers in 30 minutes, the visit expires. And if a guard decides to call a resident, the other residents of that flat are notified, so nobody is let in behind anyone’s back.