Building DesiPG: what it takes to run a multi-app PG management platform

India's PG (paying-guest) accommodation market runs on a notebook, a WhatsApp group, and a landlord's memory of who paid rent last month. It's a genuinely large, genuinely underserved market, and it's a hard one to build software for, because the software has to work equally well for a PG owner who's never used anything more complex than WhatsApp, and a tech-comfortable guest who expects an app to feel like every other app on their phone. DesiPG is our answer to that: a two-sided platform we built and continue to operate, and this is what it actually took.

Two very different users, one connected system

A PG owner and a PG guest have almost nothing in common as users. The owner needs to manage floors, rooms, and beds; track rent and staff; and see the health of their business at a glance. The guest needs to find a verified room, complete KYC without visiting an office, and pay rent without a bank transfer negotiation. We built these as genuinely separate mobile apps rather than one app with two modes, because forcing both experiences into a single interface would have compromised both.

• Owner app: property setup, ledger and rent collection, staff accounts with restricted roles, food menu and pricing management
• Guest app: verified PG search, digital Aadhaar-based KYC, rent payment, real-time chat with the owner, a personal QR code for meal attendance

The four-app decision, and why we didn't monorepo it

Guest mobile, owner mobile, an admin webapp, and the NestJS backend: four independent codebases sharing only an API contract, deliberately not a shared monorepo. Each app has its own release cadence. The backend deploys continuously, the admin webapp deploys frequently, and the mobile apps deploy on app-store review timelines that are entirely out of our control. Coupling those into one repository would have meant a mobile app store review blocking an unrelated backend fix, or vice versa. The cost is some duplicated patterns across the two mobile apps, a cost we accepted deliberately, in exchange for real independence.

Trust is the actual product

The technically hardest part of DesiPG isn't the CRUD around rooms and rent, it's the trust layer that makes a guest willing to hand over their Aadhaar details and an owner willing to accept a stranger into their property. Every PG goes through manual admin review, photos, address, amenities, KYC, before it's publicly listed. Every guest completes digital KYC through Aadhaar and Digilocker before an owner approves them. Neither side is trusting the other blind; both are trusting a review process in the middle.

Payments as the system of record

Owners pay a monthly subscription per PG property, tiered by room count, with a 30-day free trial. Guests pay nothing directly to the platform. Making this work reliably meant treating the Razorpay webhook, not our own database write, not the client's confirmation screen, as the actual source of truth for payment and subscription state. An eight-state subscription lifecycle, reconciled against webhook events, is what lets an owner's dashboard always reflect what actually happened with their payment, even if their app crashed mid-checkout.

Building for language, not just translation

The owner app ships in five Indian languages: English, Hindi, Kannada, Telugu, and Tamil, because a PG owner running a property in Bengaluru or Chennai often isn't most comfortable operating a business app in English, and most competing tools in this space are English-only. This wasn't a translation pass bolted on at the end; the app was structured for localization from the start, which is a meaningfully different (and cheaper, long-term) engineering decision than retrofitting it later.

What we'd tell another team building something similar

• If your product connects two sides who don't know each other, design the verification and trust layer before you design the delight features. It's the actual product, even if it's not what shows up in a demo
• Independent apps with a strict API contract cost you some duplicated effort, but buy you real deployment independence. Worth it once mobile app-store timelines are in the mix
• Treat your payment gateway's webhook as the only source of truth for payment state, from day one. Retrofitting this after real transactions are flowing is much harder
• If your users don't share a first language, structure for localization from the first sprint, not as a later expansion

“The hard part was never storing a room and a rent amount. It was building a system two strangers could trust enough to actually transact through.”