There is no shortage of software aimed at Indian property. A short search returns dozens — MyGate, NoBrokerHood, ADDA, Society Book, and the enterprise imports Yardi, AppFolio, Buildium — most well-built, most reviewed in the same listicles, most quietly converging on the same demo. So why does a manager running a mixed portfolio still keep the real numbers in a spreadsheet?
Because "property management software" is not one category. It is three different businesses wearing the same label, and the packaged products are each built for exactly one of them. The trouble starts the moment your operation touches two.
This is a field guide for picking software if you manage residential or commercial property in India — a society, a set of rentals, a building you maintain under contract, or some combination. We will separate the three shapes the market conflates, show where the packaged products end, and lay out what to build instead of replace.
Three businesses pretending to be one category
The listicles file society apps, rental tools, and facility-management platforms under one heading. They should not. Each models a different business with a different centre of gravity.
Society management — MyGate, NoBrokerHood, ADDA, Society Book — is built for a Resident Welfare Association collecting maintenance dues from owner-occupants. Its centre is community: visitor and gate management, the noticeboard, complaint logging, amenity booking, and shared-cost accounting. The resident is a member, not a customer, and the money flows one way — flat to society.
Rental management is built for a landlord or managing agent collecting rent from tenants. Its centre is the lease: rent schedules, renewals, escalation clauses, security deposits, and the move-in/move-out condition trail. The resident is a tenant on a contract with an end date, and the money carries tax obligations the society world rarely touches.
Facility management is built for an FM company maintaining a building it does not own, under a service-level agreement. Its centre is the work order: assets, preventive-maintenance schedules, vendor contracts, and SLA clocks. The "resident" is a client paying for upkeep, and the product lives or dies on whether complaints become closed jobs.
A single gated community fits the first shape cleanly. A landlord with ten flats fits the second. A facility firm fits the third. But the operators who actually pay for software are usually straddling — a developer's maintenance arm running the society and leasing the unsold commercial floor and maintaining a second project under contract. Three shapes, three packaged products, three logins, and a finance picture that lives nowhere.
Where the packaged products end
The packaged products solve the resident-facing top layer genuinely well, and you should not try to rebuild it. The friction sits underneath, in four places.
The money trail does not reconcile
Every packaged app records collections. None of them reconciles those collections against the bank. A resident pays by UPI with a garbled reference. A tenant splits rent across two transfers. A cheque bounces a week after the app marked the dues cleared. A commercial client pays one lump sum against eight invoices. The app shows collected; the bank statement shows something adjacent; the gap becomes a monthly hunt the accountant does by hand, line by line.
This is the single most expensive seam in property operations, and it is structural. The receipt, the expected due, and the bank line are three separate facts, and a single "paid" flag cannot hold all three. A reconciliation surface that matches them — and flags the ones that do not match — is the first thing most of our internal-tools work for property operators ends up being.
The work-order loop never closes
A resident logs a leaking pipe. The complaint lands in the society app. A vendor is called — on WhatsApp, off-system. The vendor fixes it, sends a bill on paper, and the bill is paid from a different ledger. The complaint is marked resolved; the cost attaches to nothing; and at the year's end nobody can say what the building actually cost to run, or which vendor is worth keeping.
The loop has five links — complaint, assignment, vendor, invoice, closeout — and the packaged tool owns the first and last while dropping the three in the middle. Wiring that loop end to end is the same problem we solved for a maintenance operator in our Northridge Mechanical work: a job is not closed when someone clicks resolved, it is closed when the cost is booked and the client is billed. Property is no different.
Compliance is treated as someone else's problem
This is where the Indian context bites hardest. Rent above the statutory threshold attracts TDS that the payer must deduct and deposit, with rates and limits set by the Income Tax Department under Section 194-I and 194-IB. Commercial rent and most facility-management fees attract GST that has to be invoiced and filed. Society maintenance carries its own audit obligation under the relevant state cooperative-societies law. The packaged app collects the money and then hands all of this to an accountant to reconstruct from exports — which is exactly where books and collections drift apart, and exactly where penalties and disputes are born.
Multi-entity is invisible
A real portfolio is several legal entities — the society, the landlord's holding company, the FM contract. Each needs its own books, its own statements, its own audit trail. The packaged products assume one entity and one building. The moment you have two, the finance picture fragments across logins, and the consolidated owner statement — the one number the owner actually wants — gets assembled by hand every quarter.
The straddle compounds the other three seams. A receipt that does not reconcile is now ambiguous across entities. A work order raised under the FM contract gets billed to the wrong ledger. A TDS deduction that belongs to the rental entity lands in the society's books. Each seam was already expensive on its own; the multi-entity reality multiplies them, because the manager is reconciling not one set of facts but three that keep leaking into each other. This is the quiet reason the spreadsheet survives — it is the only place all three entities sit side by side, and no packaged product was built to hold them together.
What to build instead of replace
The instinct, faced with three logins and a spreadsheet, is to commission "one platform to replace everything." That is the expensive mistake. The resident app is a commodity built better and cheaper than you could; keep it. Build the operations layer the commodities flatten.
In practice that means three surfaces, shipped in order of how much money they leak:
- Collections and reconciliation. One ledger per entity, every receipt matched to an expected due and a bank line, exceptions surfaced instead of hidden. This is almost always the highest-leak surface and the first to build.
- The work-order loop. Complaint to assignment to vendor to invoice to closeout, with cost booked against the unit and the vendor — so the building's true running cost is a query, not a year-end excavation. The resident-facing complaint can still originate in the app you already run; the loop behind it is yours. A light automation layer handles the reminders, escalations, and recurring-dues runs that otherwise eat a manager's week.
- Compliance and statements. TDS on rent, GST on commercial and FM fees, society audit exports, and the consolidated owner statement — generated from the same data the collections layer already holds, not re-keyed from exports.
A resident or tenant mobile experience sits on top when it earns its place — but it is the last thing to build, not the first, because the packaged apps already do the resident side well. The operations layer underneath is what nobody sells you.
What it costs, honestly
The packaged apps sit at ₹3–15 per flat per month — for a 200-flat society, ₹600–3,000 a month. That is the right price for the resident layer, and you should pay it. A custom operations layer on top — collections reconciliation plus the work-order loop — is typically ₹7–14 lakh for a competent boutique team over 7 to 11 weeks. Going wider, with multi-entity accounting, GST and TDS handling, owner statements, and asset and AMC tracking, runs higher and is a 4-to-6-month build best done in stages, not one shot.
The number tracks how much of your specific operating logic you are encoding — the entities, the tax treatments, the reconciliation rules — not a count of screens. And because the logic keeps shifting as the portfolio grows and the rules change, most operators keep a small support retainer rather than treating the build as finished. The resident app does the heavy lifting at the front; you are paying for the operations layer it was never built to be.
If you are running a mixed property portfolio and the monthly reconciliation has become a hunt, that is the signal — not a feature you are missing, but a seam between three products that were never meant to meet. Talk to us about the build; we will help you find the one surface worth owning before you spend on the rest.