Invest in Rojsaathi
We are pre-launch, with no paying societies. This page is the thesis, the mechanism, and — plainly — what we have not yet proven.
The problem
Every small building keeps the same books, all on paper, all thrown away every year.
- At the gate, a guard keeps a paper register nobody reads.
- In the building, everything — dues, notices, who's coming and going — is argued over a WhatsApp group with no memory.
- In the treasurer's laptop, an Excel sheet of maintenance dues gets messier every year and gets handed to next year's committee.
- In every kitchen, a fourth book nobody sees: who came, how many days, what's owed to the maid, the cook, the milkman — kept from memory, and argued over on the first of the month.
Why this segment is unserved
Not because nobody has built society software. Because nobody can afford to sell it to a building this size — in any city.
The incumbents' sales motion costs more than the account is worth: field visits and a committee cycle running months, against an account worth a few thousand rupees a year. Their cost to acquire a society routinely runs ₹45,000–75,000 — for an account worth roughly ₹10,800 a year, they simply don't show up.
Directories can't come up either — they hold no society, no payment record, no trust. A listing there is pay-to-play, and residents know it.
This isn't a city problem. A seventy-flat building in Mumbai is exactly as small an account as one in Nagpur — incumbents skip it there too. We're not choosing cities by size; we're choosing small buildings, and small buildings exist in Nagpur, Pune and Mumbai alike.
Where we are launching
Nagpur, Pune and Mumbai — pin code by pin code, not city by city.
We are not spreading three cities thin to look bigger. The trust signal that ranks a plumber depends on density — enough neighbours in one building, one street, one pin code, actually using the ledger. So growth is measured in density, not the number of cities on a map: each of the three gets the same one-pin-code-at-a-time approach the model depends on.
The flywheel
Cheap society software isn't the business. It's the on-ramp to it.
- Low-cost society software gets a building in the door.
- A free-forever attendance and billing ledger drives daily use — every mark, every payslip.
- Daily use becomes a record of who actually paid whom.
- That record becomes the ranking signal for ad-hoc discovery — plumber, electrician, one-off help.
- Discovery earns a lead fee, which funds going deeper into the next building in the same pin code, not further out.
The moat
Ranked by neighbour usage. Unbuyable. Unfakeable.
A vendor's rank inside a building comes only from neighbours who used and paid them — never from distance, never from a fee. You cannot pay your way higher in a resident's list, ever — that is the one thing that would break the only asset a directory cannot copy.
The ledger underneath it — attendance, billing, the payslip — stays free forever, for anyone, society or not. The moat depends on daily use; a paywall on the ledger would starve it.
How the cost model works
The software is cheap because there is no salesperson in it.
A committee creates its own society in the console, uploads its own flat list, and invites its own residents. Nobody from our side visits, calls, or sits through a committee meeting to close the account — that's the entire reason this runs at zero field sales and roughly ₹0 CAC.
That is also why an account this small can be served at all. An incumbent carrying tens of thousands of rupees of acquisition cost per society cannot afford to go this far down-market; a model that spends nothing to acquire an account can.
Unit economics of one mature society
Two lines: a subscription for using the tools, and a fee on services actually delivered.
A society pays a small flat subscription for the tools it uses directly — visitor management, dues, notices. Separately, every ad-hoc job booked through neighbour-ranked discovery — a plumber, an electrician, a one-off helper — carries a 12% lead fee, paid by the vendor on collection. We never hold the money; it moves directly, customer to vendor, by UPI.
Because there's no field team and the cost to serve an existing society is close to infrastructure alone, most of what a dense, active building generates is margin, not overhead. We're not publishing a rupee total here — the next section explains why.
What we have not proven yet
Here are the two numbers that would falsify this, stated as plainly as we can.
- Willingness to pay is stated, not converted. Four of the five societies we surveyed said they'd pay for this — but a verbal yes is not an invoice paid. Converting that yes into signed, paid subscriptions is, on its own, the single most important unvalidated fact in this plan.
- The job volume is an estimate, not a measurement. We believe a dense, active society could generate somewhere in the range of 20 to 40 ad-hoc jobs a month once discovery is live — but that number comes from field conversations, not from a single month of real usage. Treat it as a guess with a range, not a fact.
- Cash may never fully digitise. The two-tier earnings record is built to pull cash payments onto UPI — a worker's verified digital earnings should be worth more to her than a number nobody can check — but nothing guarantees residents actually pay that way at the volume the model needs.
- We're not showing you a revenue table. Any number we could put here is arithmetic run forward from the two unproven assumptions above. Projections are arithmetic on stated assumptions — a projection built on an unmeasured input isn't a forecast, it's a hope with formatting.
It is probably not a unicorn. That is a legitimate finding, not a failure. Even our best case is a profitable, regional business, not a venture-scale bet — in a real, underserved market nobody else can economically reach.
Get in touch
If the two numbers above are the ones you'd want measured before anything else, that's exactly the conversation we want to have.
This opens your own email app. Nothing is stored on our side.