The house is empty. You are not nearby.
The premise. An owner living outside Chennai may have a vacant house or apartment there and no practical way to inspect it regularly. Chennai is the starting point for this experiment, not a permanent boundary. If the manual service works, it could expand to other locations. A neighbour can notice a problem. A relative can visit when available. Neither is a dependable service. A leaking pipe, an unpaid meter, or damage after a storm can sit unnoticed until the next visit.
The proposed service is deliberately manual. Someone visits the property on a schedule agreed with the owner. They take timestamped photographs, record meter readings, check the visible condition of the property, and send a report with any issues. If something needs attention, they can coordinate a repair only after the owner approves it. The service reports what it sees. It does not pretend to control what happens inside an unattended property.
The boundaries. This service would not provide legal verification, structural certification, or a security guarantee. It would not handle cash or valuables. It would not authorise or pay for repairs without approval. A photograph is evidence of a condition at one point in time. It is not an inspection certificate, an insurance policy, or a promise that nothing happened between visits.
Why test it manually. The first version does not need an app. It needs a reliable visit, a clear checklist, good photographs, accurate readings, and a fast way to escalate an issue. A spreadsheet, a phone, and a written report are enough to learn whether owners want this service and whether the work can be done consistently. Building software before answering those questions would hide the operating problem behind a product demo.
The tentative offer. Chennai first. Approximately INR 2,999 per month as an experiment price, with onboarding and repairs priced separately. The price is a starting point, not a market fact. The eventual offer may need different tiers for apartments, independent houses, visit frequency, and the distance between properties.
The test. Put up a landing page that explains the service and its boundaries. Run a fixed-budget Google Search ad experiment for people already looking for help with property oversight in Chennai. The page can ask for the property location, visit frequency, and the owner’s preferred way to talk.
This can show whether people search, click, read the offer, and start a conversation. It can show whether some visitors will discuss a paid engagement at the tentative price. It cannot show retention, operating margins, repair coordination at scale, or profitability. Search and lead behaviour are early signals. They are not proof of a business.
The budget stays fixed. The success condition is paid conversations, not a large waitlist. A waitlist is easy to join and easy to ignore. A person willing to pay for the first month has revealed more. Even that is only an early signal. The service still has to deliver a useful visit, keep trust, handle exceptions, and earn the next month.
Where it stands. This is an idea being tested, not a validated business. The broader lesson is straightforward: sell a painful recurring service before building a product around it. If nobody wants the manual version, software will not rescue the idea.
The open questions are practical. Who feels this problem sharply enough to pay? Is INR 2,999 a credible starting point for the first service area? What belongs in the base visit, and what should cost extra? How much time does a visit, report, escalation, and repair coordination consume? What operating margin remains after travel, labour, re-visits, refunds, and mistakes? The experiment exists to answer those questions without pretending they have already been answered.