PG India
A marketplace for paying-guest housing joined to the software owners use to run the building, so a listing reflects real beds instead of a stale advert.
- Status
- In development
- Role
- Sole developer
- Year
- 2026
- Type
- Property marketplace and management platform
Where it stands
Not publicly launched. There are no user, listing or transaction numbers to report, so none are shown.
- Surface
- 68 pages, 46 API route handlers
- Database
- 20 SQL migrations, 5 isolation test suites
- Roles
- Tenant, owner, guardian, admin
There is no public link for this project.
The problem
Finding a PG room in India and running a PG are two separate worlds. Listings live on one side. Rent registers, mess counts and WhatsApp threads live on the other.
Because the two are not connected, listings go stale. A marketplace cannot say a bed is free if the owner's own records are in a notebook.
Goals and constraints
It had to
- Let tenants search, compare, book a visit and reserve a place without their details being passed around.
- Give owners a working management system: rooms, beds, tenancies, rent, utilities and meals.
- Make the marketplace read availability from the management data rather than from a form someone filled in once.
- Keep one owner's residents and finances invisible to every other owner.
Within these limits
- Four roles with very different permissions share one database.
- Identity documents are involved, so verification and storage had to be designed, not bolted on.
- The exact address of a property is sensitive until a visit is confirmed.
My part
Every commit in the web application's repository is mine: product decisions, schema, security rules, interface and integration work.
- Designed the schema and wrote the migrations, including the Row Level Security policies and the isolation tests that check them.
- Built the tenant, owner, guardian and admin areas end to end.
- Built the visit-booking workflow as a role-aware state machine with an audit trail.
- Integrated Razorpay payments with a webhook, and a permanent, printable receipt system.
- Built the owner management modules: rooms and beds, tenancies, rent engine, utility splitting, mess manager and late-fee automation.
What it is
Tenants search and compare listings, request a visit, book, pay, and then live in a dashboard with rent, meals, complaints, agreements and notices. A guardian can follow along through a tokenised link.
Owners register, pass KYC, and then run their property: capacity by room and bed, who is in which bed, what rent is due, how the electricity bill splits, how many plates the kitchen needs tonight.
Admins verify owners and tenants, moderate listings, mediate visits and handle disputes, payments and support.
- Visit booking with mediation
- Requested, admin review, waiting on owner, waiting on tenant, confirmed. Owner and tenant can bounce a proposed time back and forth, and every transition is validated before any write.
- Address privacy boundary
- Before confirmation a tenant sees only the city and area. The exact address, map pin and a temporary owner contact token are revealed once the visit is confirmed, enforced on the server.
- Rooms and beds
- Capacity is modelled as rooms containing beds, and tenancies occupy beds. Vacancy is derived from that, not typed in.
- Rent engine
- Rent configuration, invoice generation, mark-as-received, late-fee automation and a duplicate guard on the rent ledger.
- Utility bill splitter
- Splits a bill between AC and non-AC residents and applies each share to that tenant's rent.
- Mess manager
- Tenants opt in or out of meals from their dashboard and the owner sees real plate counts.
- Verification
- Owner and tenant KYC with in-browser OCR to pre-read documents. A human admin makes the decision; the provider interface is written so an automatic check can replace manual review later.
- Payments and receipts
- Razorpay checkout with a webhook, and booking receipts that are permanent, printable and visible to admins.
Decisions and trade-offs
01A listing is not a property
The marketplace listing is an advert. The managed property is the operational truth. They began as one table and were split into two, with a reconciliation step between them.
The cost. A migration across live relationships and an extra concept to explain to owners. Without it, the management side could never correct the marketplace.
02Authorisation lives in the database
Row Level Security policies decide who can read each row. Each stage of the multi-tenant work shipped with an SQL isolation test that tries to read across owners and expects to fail.
The cost. Policies are harder to debug than application checks, and server-side reads that use the service role must prove ownership first, in one place.
03Visits are a state machine, not a status column
Each action belongs to exactly one role and is legal only from listed states. The table of transitions is the single source of truth for the API.
The cost. Adding a new step means editing the machine, which is slower than adding an if statement and much harder to get wrong.
04Heuristics are labelled as heuristics
Vacancy Radar and Rent Optimizer are rule-based estimates from the owner's own data. They are named that way in the product and in the code.
The cost. Less impressive than calling it AI. It is also accurate.
How it is built
- Next.js App Router with Server Components for data reads and route handlers for writes.
- Supabase for authentication (including phone sign-in), Postgres and storage, accessed through separate browser, server and service-role clients.
- Property-scoped reads filter on the property id and run only after ownership has been resolved once.
- A notification table with an in-app bell centre and event hooks, and a support system with queues and an admin inbox.
Next.js 16 · React 19 · TypeScript · Supabase · PostgreSQL · Row Level Security · Razorpay · Leaflet · Tesseract.js · Tailwind CSS · GSAP
Hard problems
A registration bug let an owner's role fail to persist, sending new owners to a 404.
Traced it to where the role was written relative to the auth callback, fixed the persistence, and added a role-isolation migration so a profile cannot drift between roles.
Financial tables for the management system were readable more widely than intended.
A hardening migration tightened the policies on the rent and billing tables, and the isolation tests were extended to cover them.
Moving from listing-level capacity to rooms and beds without losing existing bookings.
Staged migrations: organisation foundation, property split, rooms and beds, tenancies, then notice and vacancy. Each stage had its own snapshot and test before the next began.
What can be verified
- pages across four rolesCounted from the application's route tree.
- 68
- API route handlersCounted from the application's route tree.
- 46
- SQL isolation test suitesOne per stage of the multi-tenant migration.
- 5
Limits and open work
- Pre-launch. Nothing here has been tested by real tenants or owners at volume.
- Document verification is a manual admin decision today.
- The payment flow is built and wired to a webhook; live-mode operation has not been verified for this write-up.
- The repository is private.
Need something like this built?
Tell me what you are making. I will tell you how I would approach it, and whether I am the right person.
Start a conversation