ROOMRRThree documents from this engagement.
The audit came first, from outside, before we met. The proposal answers what you asked for after. The extras are the things we said we would send over.
We did this before we met you, from the outside, with no access to anything.
No analytics, no code, no team, no app, nothing internal. Everything in here was visible to anyone who cared to look — which is the point. If we could see it, so can a competitor, a search engine, and your first thousand users.
What we examined
Four passes, independent of each other, over roughly three weeks.
| Pass | What it covered | Method |
|---|---|---|
| Product walkthrough | Eight screens end to end — home, sign-in, code search, filters, listing results, owner contact, dashboard, add property | Screen by screen, captured |
| Search surface | Metadata, page structure, indexation, crawler readiness, answer-engine visibility | Scored across eight dimensions |
| Live verification | Homepage, About and Terms, fetched directly | Read as raw markup, not as a rendered page |
| Market work | Indian urban rental demand, supply, and the four platforms you are measured against | Government data, audited filings, published pricing |
What we could not see
Stated up front, because a report that hides its own limits is not worth much.
| The app | In build, not shipped. Section 05 is therefore not an audit — it is what we would check before it ships, and why each item is cheaper now. |
| Your analytics | Traffic, sources, drop-off, conversion. None of it public. Where a number would help, we say so rather than estimating. |
| Your roadmap | Some of what follows may already be scheduled. If so, treat this as confirmation rather than news. |
| Social channel data | Assessed from outside, so no reach, engagement or audience figures. What each account contains is observable; how it performs is not. |
| Load and performance | Not measured here. It needs a run from a real device on a real Indian network, which is worth doing before launch, not after. |
Almost everything in this document is free to fix today and expensive the day after you launch.
That is the real finding. Not that things are wrong — every pre-launch product has things wrong — but that a specific set of decisions is about to stop being reversible. Pre-launch is not a stage. It is a window, and it closes on the day your first real user arrives.
What each decision costs, before and after
Every row is a finding from the sections that follow. The right-hand column is the reason to read them now.
| Decision | Cost today | Cost after launch |
|---|---|---|
| Whether owner phone numbers are exposed | A settings change | Cannot be undone — numbers already out are out |
| Whether tenant-category filtering ships | Removing a dropdown | Owners will have come to rely on it |
| What you measure about a tenant's search | A day of event tracking | The founding cohort passes through once, unmeasured |
| Your URL and indexation structure | A naming decision | Redirect chains, lost rankings, months to recover |
| What the empty state tells a visitor | One sentence | Every early visitor already concluded you were broken |
| What a shared link looks like | Four lines of markup | Every link shared during launch renders as naked text |
| Recovering the Reddit handle | A support ticket | Someone else owns a name you use everywhere |
| Explaining what a property code is | One sentence | Every video you post drives traffic to a field nobody understands |
| Whether the app repeats the website's decisions | A conversation with your build team | Two codebases to change instead of one |
Most audits hand you a list of problems ranked by severity. That is the wrong ranking for a company in your position, because severity is not what is scarce here — reversibility is. A serious problem you can fix any time is worth less of your attention than a small one that hardens permanently in six weeks.
Read the rest of this the same way. Where we flag something, the question we are really asking is not how bad is this — it is how much does waiting cost.
The strongest thing you have written about RoomRR is in your Terms and Conditions.
That is not a joke and it is not a criticism of the site. It is the finding. Your legal pages contain a clearer, sharper product position than any page a customer will ever open — and they contain commitments your competitors would not make.
What is working
Real assets, and more of them than the surface suggests.
- You have already banned what tenants complain about most Your Terms prohibit broker and intermediary listings, duplicate listings, fake properties, misleading listings and incorrect rent information. Across our tenant research, stale and misrepresented listings rank first among complaints about existing platforms, and brokers appearing on owner-only platforms rank fourth. You have written the rule. No incumbent has.
- The product is defined precisely, in one sentence "RoomR is a rental discovery platform connecting property owners and tenants." Clean, accurate, and immediately understandable. It appears in section 1 of your Terms.
- Scope discipline You explicitly do not take part in agreements, negotiations, payments or tenancy management. The last well-funded company to try owning all of that sold for roughly five percent of its peak valuation. Staying out is the right call and you have already made it.
- Trust and entity signals are your highest-scoring dimension Legal entity, registered address, jurisdiction and contact are all clearly stated. On the search audit this scored 72 out of 100 — nearly double every content dimension.
- The pages load clean and readable Content is in the HTML, not locked behind scripts. That sounds minor. It means everything below is a content and structure problem, not a rebuild.
What is weak
Mostly one problem wearing five different hats: the site does not say what it is.
- The homepage never says what RoomRR does or where it works A visitor who arrives without knowing you cannot find out. The word "rent" appears once on the page, inside a tagline.
- The main action is unusable by the people you need, and nothing explains it The primary input asks for a property code. There is a reason for it — codes appear in your property videos, so a viewer can jump straight to that property. Nothing on the page says so. We were looking deliberately, for three weeks, with every public document in front of us, and it still took a long time to work out what that field wanted. A visitor arriving from search or a forwarded link has five seconds and none of our motivation.
- The About page is 43 words It carries the best short description of your intent anywhere on the public site, and then stops. It also drops the footer that every other page has, so the policy and social links vanish.
- One message covers three different failures A mistyped code from a video, a valid code for a delisted property, and a pincode you do not yet cover all return the same line: property not found, try a correct code. The viewer who typed one character wrong concludes the property is gone. At launch, most visitors will see some version of this.
- The listing form is fourteen sections and four scrolls No save-draft, no marked required fields, no image upload despite photos being the single most decisive part of any rental listing. This is your supply funnel.
What is silently costing you
These are not visible as problems. That is exactly why they are the expensive ones.
- A dropdown that creates a permanent record of who was refused Your listing form asks owners to select a preferred tenant — family only, bachelors only, anyone. The practice is common and legal. But an owner refusing someone on a phone call leaves no evidence, while a platform captures it: timestamped, attributed, queryable, on your servers, at whatever scale you reach. A paired study of the Delhi rental market found refusal or worse terms for a large share of applicants by community, including applicants offering above asking rent. You are not creating that behaviour. You are creating the record of it.
- Owner phone numbers are shown in full The contact modal displays the owner's name and number directly. The market leader releases owner numbers by default too — and then sells the owner privacy back as part of a plan costing over three thousand rupees. That is the gap your Terms already position you to attack, and the current build gives it away.
- Your trust promise has no mechanism behind it Section 4 prohibits fake and misleading listings. Section 3 says listings go live immediately on publication. Section 6 states you do not verify ownership or guarantee accuracy. Legally standard, and commercially it means the strongest claim you can make is currently unenforced. This is fixable and it is the single highest-value thing on the site.
- Nothing measures the promise you are making Your stated purpose is saving tenants time, fuel and unnecessary conversations. Nobody in the Indian market has ever measured what a rental search costs in any of those. Neither do you, yet. Instrument it and you own a number no competitor has.
You do not have a positioning problem. You have a placement problem. The position exists, it is sharp, and it is sitting in the one document written to limit liability rather than to win customers.
Move it forward and give it a mechanism — verification, listing expiry, contact control — and you are making a promise the four incumbents structurally cannot match, because each of them earns revenue from the behaviour you would be banning.
Every page on roomr.in has the same title and the same description.
To a search engine, that means your homepage, your About page and your Terms are the same page. This is a ten-minute fix that is currently capping everything else you do.
What a search engine sees on your homepage
Not a summary. This is the complete machine-readable content of the page.
description The simplest and easiest way to rent without any non-sense.
h1 ROOMR
links Home · About Us · Contact Us · Login/Register
body Property code · Find · Get Started
og:title — absent
og:description — absent
og:image — absent
canonical — absent
structured data — absent
Five findings, in the order they cost you
| Finding | What it means in practice | When |
|---|---|---|
| Identical titles and descriptions on every page | Search engines treat near-identical pages as duplicates and pick one to show. You are competing against yourself on every query. Verified across homepage, About and Terms. | Now |
| No social preview tags at all | Every link to roomr.in shared on WhatsApp, LinkedIn, X or Instagram renders as a naked URL — no image, no title, no description. It affects the five channels you already own, and it is part of why property codes are doing work a link should do. For a launch that will run on sharing, this is the highest-leverage markup on the site. | Before launch |
| No location or property pages exist | Rental search is overwhelmingly local — flats for rent in Gachibowli, 2BHK in Kondapur. You have no page that can answer any of those. This is where essentially all organic rental traffic comes from. | Before inventory |
| No structured data | Search engines and AI assistants cannot tell that a page describes a rental property, its rent, its location or its availability. Rich results and AI answers both depend on it. | With property pages |
| Indexation rules are undesigned | Filter combinations, expired listings, sorted views and search results all generate URLs. Decide now what gets indexed. After launch this becomes cleanup, and cleanup means redirects and lost rankings. | Before inventory |
Being found by AI, not just by Google
Two things decide whether an assistant can answer a question about RoomRR: whether it is allowed to read you, and whether what it reads is shaped like an answer.
| Step | What it does |
|---|---|
| Split the crawler decision in two | Training crawlers and retrieval crawlers are different user agents. Allow retrieval so you stay eligible to be cited; decide separately about training. Blocking Google-Extended opts you out of Gemini training with no effect on Google Search. |
| Lead every page with its own answer | Assistants extract the first sentence or two of a section. "RoomR is a rental discovery platform connecting owners and tenants in Hyderabad" belongs at the top of the page, not in clause 1 of the Terms. |
| Publish the entity, consistently | Organization and WebSite markup naming the legal entity, the address and the five social profiles. You already use one handle everywhere — that consistency is exactly what identity resolution rewards, and it is currently undeclared. |
| Mark up the answers you already have | FAQ markup on the questions your Terms answer: is it free, are brokers allowed, who operates it, where does it work. Roughly two-thirds of pages cited in AI answers carry structured data. |
| Keep redirect chains at one hop | Retrieval crawlers abandon after about three redirects and fail silently, with no error anywhere. Googlebot tolerates ten. A chain that looks fine in Search Console can remove a page from AI answers with no signal at all. |
| Date and refresh what matters | Freshness is among the strongest predictors of being cited. A visible last-updated date on listing pages serves the same purpose here as it does for tenant trust. |
Assistants answer questions rather than list links, and right now none of them can answer a basic question about you.
The fix is not more content. It is putting a direct, self-contained answer at the top of each important page, so the first paragraph still makes sense when lifted out of context, which is exactly how an assistant uses it.
The crawler decision is where most teams go wrong, because it looks like one decision and is two. Blocking ClaudeBot does not block Claude-SearchBot. Blocking GPTBot does not block OAI-SearchBot. A team protecting its content from training can remove itself from AI answers without realising, and a team wanting AI visibility can leave training wide open thinking it has opted out. Both are one line in robots.txt — and neither is enforceable against a crawler that ignores it, so anything genuinely private needs blocking at the server, never in a text file.
One thing to skip for now: an llms.txt file. It costs nothing and does no harm, but as of 2026 no major provider has committed to reading it and there is no evidence it affects retrieval. Add it last, expect nothing.
The strongest signal in this whole area is one you are already positioned for. Unlinked brand mentions correlate with AI citation far more strongly than backlinks do, and YouTube mentions are the single strongest measured signal of all. You have one YouTube video and five consistently named profiles. That is the foundation of an entity, and nothing on the site currently declares it.
Nothing here is a rebuild. Your pages are clean, readable and server-rendered, which is the hard part and you already have it. What is missing is description, structure and intent — telling machines what each page is, what it covers, and where it sits.
The order matters more than the effort. Titles and social previews are hours. The location and property architecture is the one to design before you have inventory, because retrofitting a URL structure onto a live catalogue is the most expensive mistake available in this category.
We cannot audit your app. So we audited it anyway.
It is in build and we have no access, which normally makes this a blank section. It does not, because we already know what it will contain. Every decision on the website reappears in the app by default — and the app is the more expensive place to change each one.
What we would check before it ships
Nine items. Each one is a decision your build team is making right now, whether or not anyone has framed it as a decision.
| Check | Why it matters more in an app | Verdict if it mirrors the web |
|---|---|---|
| Event instrumentation | Searches run, listings opened, contacts requested, visits booked, days to signing. In an app this is close to free at build time and near-impossible to backfill. | Do first |
| Preferred-tenant field | Same record, same exposure, plus app-store policy surfaces that web does not have. | Decide first |
| Owner contact exposure | Apps make contact one tap away, which raises volume. In-app calling or masked numbers cost little at build and cannot be retrofitted quietly. | Decide first |
| Listing creation flow | Fourteen sections is hard on desktop and brutal on a phone. Save-draft and camera-first photo upload are app-native advantages you would be wasting. | Redesign |
| Empty and no-coverage states | Store reviews are permanent and public. An app that reads as broken in week one carries that rating for years. | Rewrite |
| Permissions requested at first open | Location, contacts, notifications. Asking for all three before showing value is the most common cause of first-session abandonment. | Sequence |
| Deep links and web parity | Every property should open in the app from a shared link and fall back to web cleanly. Decided at build, painful later. | Design now |
| Store listing metadata | App store search is its own channel with its own ranking. Title, subtitle, keywords and screenshots are the equivalent of everything in section 04. | Not started |
| Review prompt timing | The incumbents prompt at moments of satisfaction, which is why their store ratings sit far above every independent measure. Worth knowing that going in. | Decide |
If you only take one thing from this section: instrumentation is the item that cannot be recovered later.
That means the number is available to whoever measures it first, and you are about to have a cohort of users doing exactly the behaviour nobody has recorded. Instrument it before they arrive and within a quarter you hold a dataset that no incumbent has, that no market report can sell you, and that proves or disproves your own pitch. Skip it and the founding cohort — the only users who will ever show you what an unassisted search costs — passes through invisibly, once.
You reserved five handles and launched none of them. That is a better position than it sounds.
Consistent naming across five platforms is discipline most pre-launch companies do not have, and it is worth more than a head start on posting. The channels are not underused. They are correctly dormant — and the plumbing they would feed into is not ready yet.
Where each account actually stands
Presented flat, because the pattern is clearer without commentary.
| Platform | State today | Reading |
|---|---|---|
| YouTube | One video published — a property walkthrough | The most valuable asset in this section. See below. |
| No posts, low-resolution logo, small follower base | Claimed, never opened. The strongest channel for this category. | |
| Two posts, both 2025, nothing since | Reads as started-and-stopped, which is worse than empty. | |
| Profile not accessible | A broken link in your own footer. Also a handle at risk. | |
| X | No posts, no followers, following one account — the platform's default suggestion | The signature of a signup completed and abandoned. |
The property code is the bridge between these two things
It took us a long time to work this out. That is the finding.
You put property codes in your videos so a viewer can find that exact property. It is a real strategy, and nothing on the website explains it.
It is also invisible. We spent three weeks looking at this company deliberately, with every public document in front of us, and it still took us a long time to understand what that field was asking for and why. A tenant who lands on roomr.in from a search result, a forwarded link or an ad has five seconds and none of our motivation. If a team being paid to understand your product found it hard, a stranger will not find it at all.
There is a fair case for codes on Instagram specifically, where links in captions do not work and a code is a sensible workaround. There is no case for them on YouTube or Facebook, where a description link is one tap and a code is four steps — remember it, leave the app, find the site, type it correctly. And there is no case at all for a code being the first thing a stranger meets on the homepage.
- Almost no content carries a code One video across five channels. The mechanism exists; nothing is feeding it.
- Shared links have no preview No Open Graph tags, so any link you post renders as bare text. The alternative to codes currently looks broken too.
- The field explains nothing No line saying what a code is, who has one, or what to do without one. A mistyped code returns the same message as a city you do not cover.
One video is worth more than the other four accounts combined
You can already produce a property walkthrough. Your listing form cannot accept a photo.
Set that against a finding from section 03. The Add Property form runs to fourteen sections and has no image upload, despite photographs being the most decisive element of any rental listing. You can shoot a walkthrough and the product cannot take a picture. That gap is the whole sequencing problem in one line — the content capability is ahead of the product capability, and activating channels before the product can hold what they send is how a launch moment gets spent for nothing.
What we would do, in this order
| When | Action | Why now |
|---|---|---|
| Today | Recover the Reddit handle | Broken outbound link on your homepage, and consistent handles are the one social asset you actually hold. A support ticket now; someone else's property later. |
| Today | Explain the code, in one line, on the homepage | "Saw a property in one of our videos? Enter its code here." Plus a route for everyone who has not. |
| Pre-launch | Build the brand asset kit | One root cause behind the low-resolution avatar, the missing share image and the inconsistent mark. Fix once. |
| Pre-launch | Add share previews, then per-property share cards | Every listing shares as its own photo, rent and locality. That turns each user into a distribution channel — and it is the better answer to what the code is currently working around. |
| At launch | YouTube and Instagram first, Facebook next | The first two because you have already proven the format. Facebook because its housing groups are one of the largest informal rental channels in urban India, and it is badly under-rated here. |
| Later | Reddit only once the handle is back | City housing subreddits are where Indian renters genuinely ask for help, and where a brand posting badly gets taken apart. High reward, unforgiving. |
| Park | X | Keep the handle. Do not invest in the channel. |
The instinct to hold off has been right. Property content with one listing behind it is worse than silence — it burns the one launch moment you get, in front of the audience most likely to try you first.
But there is a difference between waiting and not being ready. Handles, an asset kit, share previews and an explained code are all pre-launch work. Do those and the channels can be switched on the week inventory lands, rather than starting from zero at the moment you most need them.
You cannot outbuild them. You can outbehave them, and they cannot follow you.
99acres, Magicbricks, Housing and NoBroker have inventory, traffic and brand you will not match for years. That is the honest starting position. It is also less relevant than it sounds, because scale has not made any of them work.
Four facts about the market you are entering
| Rents rose 14% while the platforms did not follow | Over a comparable period one major shrank 17%, two were roughly flat. A rising rental market does not lift these businesses. Whatever the growth story is, it is not the tide. |
| The best-funded player spends ₹1.62 to earn ₹1 | From its last audited accounts. It has not filed since. Scale in this category has not produced profitability for anyone visible. |
| Discovery is solved. Trust is not. | Four apps with ten million downloads each. Tenants are not short of listings — they are short of listings that are real, available, and reachable without their number being resold. |
| Every documented failure is a revenue decision | Stale listings inflate inventory counts. Resold leads multiply revenue per lead. Sales scripts close packages. Exposing an owner's number creates the problem a paid plan then solves. |
Why that last one is the whole opportunity
They are not failing at these things. They are earning from them — which is why they cannot copy the fix.
If RoomRR never earns from reselling a lead, it can promise something the incumbents would have to forfeit earnings to match. If RoomRR expires listings aggressively, it shows a smaller and truer catalogue than a competitor whose inventory count is a marketing number. If RoomRR gives owners real control over who reaches them, it is giving away free what the market leader charges over three thousand rupees for.
Two honest cautions. This defence works at scale and is weak locally — a competitor can bundle privacy free in one neighbourhood to blunt you, cheaply, without changing anything structural. And the direct-owner position you are closest to already has a well-documented failure mode: brokers appearing on owner-only platforms is the fourth-ranked tenant complaint precisely because it has happened to everyone who promised it. Your Terms already prohibit it. The question is whether you enforce it, and how visibly.
Where this could go
Not a forecast. The shape of the thing if the window is used well.
- The only catalogue that is true Every listing verified, dated, and expired on a schedule. Not more listings — fewer, and all of them real.
- What a rental search actually costs Properties viewed, weeks spent, visits made, distance travelled. Unmeasured by anyone in India. Yours within a quarter of launch.
- The code, used properly Explained on the site, printed at the property, and tracked. Every code entry tells you which video, which locality and which channel produced a visit — attribution the portals cannot get, because they have nothing physical and nothing to trace.
High level, and in order. The sequence matters more than the effort.
Nothing here is a full plan and it is not meant to be. It is the order we would work in, and every item traces to something evidenced above. The first horizon is the only one with a deadline attached.
Before launch — the window
- Decide the two defaults. Whether the preferred-tenant field ships, and whether owner numbers are exposed. Both are free today and permanent afterwards.
- Instrument the funnel. Searches, listings opened, contacts, visits, days to signing. This is the item that cannot be recovered later.
- Fix titles, descriptions and social previews. Hours of work. Currently capping every other channel you have.
- Rewrite the homepage and the empty state. Say what RoomRR is, where it works, and — when there is no coverage — say that instead of implying the visitor got it wrong.
- Design the URL and indexation structure. Before there is inventory to migrate.
- Explain the property code and recover the Reddit handle. One sentence and one support ticket. Both cost nothing today.
At launch — make the promise real
- Move the position out of the Terms. The prohibitions you have already written are the strongest marketing you own.
- Give it a mechanism. Verification, listing expiry, freshness dates, a report path. A promise without enforcement is the thing tenants already distrust.
- Go deep in one locality, not wide across cities. Liquidity is local and does not average. Forty properties in Gachibowli beats four hundred across six cities.
- Build the location pages for that locality. This is where organic rental traffic actually comes from.
- Ship the app against the section 05 checklist, not as a copy of the website.
- Switch on YouTube and Instagram the week inventory lands, with share previews already in place so the traffic has somewhere to arrive.
First ninety days — compound it
- Publish what you measure. The search-cost number nobody else has is a story, a sales asset and a recruiting asset at once.
- Per-property share cards. Turn every user into a distribution channel on the platform where flats already circulate — and give the property code a link-shaped alternative.
- Track code entries by source. Which video, which locality, which channel. Cheap to add and it is attribution no portal can match.
- Watch the listing funnel. Abandonment on the add-property form is the first number you will own — and supply is existential.
- Get a legal read on the filtering question and on consent for SMS, WhatsApp and phone contact. Small piece of work, and it is the difference between a communications problem and a structural one.
- Only then, expand. Second locality once the first one closes the loop.
We put this together before we properly sat down with you, from outside, with no access to anything internal. Some of it may already be on your roadmap, and where that is true, take it as confirmation rather than news.
None of the above requires us. It is your product, the findings are yours, and the window is open whoever does the work. We looked because it was interesting, and because a company that has already written the right rules into its own Terms is a more unusual starting point than you probably realise.
What you asked us to price.
Following our meeting, you asked for a technical specification and the cost of building and running the RoomRR platform. This document is that answer, with the parts we cannot yet know marked rather than smoothed over.
Scope, as we understood it
Three workstreams, delivered in two phases.
A single interface for your team to manage listings, users, documents and payments, with system health and platform analytics.
Rent collection, invoicing, receipts, payment history and identity documents, running as a separate service.
Android and iOS from one codebase, carrying the full product for both owners and tenants, from discovery through to rent.
How this document is built
The two principles that made the audit report useful apply to this document as well.
- Where a number rests on something we have not seen, we say so. Where something is still unsettled, it is called out where it arises rather than folded quietly into a number.
- Nothing here requires you to accept all of it. The work is phased, each phase is priced separately, and each one stops cleanly. Nothing in Phase 1 is wasted if you stop there.
Three services, one mobile codebase, and nothing built that you do not need yet.
The architecture is deliberately small. At your launch volumes complexity costs more than it buys, and every component added now is a component to maintain for the life of the product.
The decisions behind it
Four choices that shape everything downstream.
- Separate the money from everything else Payments and documents run as their own service. Rent collection carries obligations the rest of the product does not, and isolating it keeps that boundary clear for auditing, access control, and whoever reviews it later.
- One mobile codebase, two stores There are three frameworks to pick from: React Native under Expo, Flutter, or native Swift and Kotlin. All three are compared in full below.
- Instrument before launch, not after Your proposition is that RoomRR saves a tenant time, fuel and unnecessary conversations. Nobody in the Indian rental market has measured any of the three. Event tracking is close to free at build time and cannot be backfilled.
- Build for one locality first The system is designed to run deep in Hyderabad before it runs wide. That affects search, indexation and how localities are modelled, and it is cheaper to assume now than to retrofit later.
How the pieces fit.
A shared backend serving the existing website, the new mobile application and the admin console, with money and documents isolated behind their own service.
What each part does
| Component | Responsibility | Stack |
|---|---|---|
| Mobile | Full product, both roles, Android and iOS | React Native · Expo |
| Core backend | Users, owners, properties, listings, search, enquiry, instrumentation | Python 3.11 · FastAPI |
| Admin web | Listing review, verification queue, users, payments oversight, health | React · TypeScript |
| Database | Application data, financial records, audit trail | Managed PostgreSQL |
| Documents and payments | Rent collection, invoices, receipts, identity documents | Python 3.11 · FastAPI |
| Object storage | Listing photographs, generated documents, identity scans | S3-compatible |
Mobile framework
All three build the same product. The difference is what happens after we hand it over: who you can hire, and what the ecosystem gives you for free.
Not performance. At this product's complexity all three are fast enough. It is that one TypeScript codebase across mobile and admin means fewer people, and over-the-air updates mean a copy fix does not wait on app store review.
What is in, what is not, and what waits.
Three lists rather than two. The middle one is the point: those are real choices with real prices, not things we have quietly left out.
Included
- Core backend and API
- Admin web application
- Rent collection and payment status
- Invoice and receipt generation
- Identity document capture and storage
- Mobile application, Android and iOS
- Listing creation with photograph upload
- Search, filters, enquiry and owner contact
- Event instrumentation
- Push notifications
- Deployment, monitoring and store submission
Optional
- WhatsApp Business API
- Owner number masking
- Listing expiry and freshness
- Owner payouts and settlement
- Subscription billing
- Third-party identity verification
- Saved searches and alerts
- Owner analytics
- In-app support and ticketing
- Multi-city at launch
- High-availability infrastructure
- Website metadata and indexation work
- Support beyond the warranty period, quoted monthly
Not included
- Redesign of the roomr.in website
- Brokering, negotiation or tenancy agreements
- Languages other than English
- Content, listings or photography
Screen inventory
Drawn from the existing product surface and extended for the new capability.
Home · Search and filters · Listing detail · Owner contact · Bookmarks · My rental · Payments and history · Invoices and receipts · Documents · Profile
Home · My properties · Add and edit listing · Enquiries · Rentals · Incoming rent · Settlements · Documents · Profile
Dashboard · Listing review · Verification queue · Users · Payments · Documents · Health · Analytics
Decisions carried forward from the discovery report
Nine items were flagged as cheaper to settle before the app ships than after. All nine are addressed here, grouped by who has to move on them.
- Owner phone number exposure Masked contact recommended. Numbers already published cannot be recalled, so this is a decision with a deadline rather than a preference.
- Preferred-tenant field We recommend it does not ship. Your call, and we will build to whichever position your advisor sets.
- Event instrumentation Built in from the first sprint.
- Listing creation flow Rebuilt for mobile: save-draft, camera-first.
- Empty and no-coverage states Rewritten.
- Permission sequencing Requested in context, not at first open.
- Deep links and web parity Designed in.
- Store listing metadata Drafted by us, approved by you.
- Review prompt timing Built by us, timing to be agreed with you.
How rent moves through the platform is still yours to shape.
Rent can settle to RoomRR first and then out to owners, or split at the gateway and go straight to them. Going direct keeps the compliance load light and is the quicker route to launch. Routing it through RoomRR brings payment-aggregator obligations, and in return puts you in control of settlement, deposits and whatever you later want to build on top of money moving through the platform. The architecture, the gateway product and the compliance work all follow from that one answer, which is why it is worth choosing now while either road is still open to you.
The parts nobody asks about until something breaks.
Targets rather than aspirations. Each one is measurable, and each one is something you can hold us to at acceptance.
Targets at launch
| Property | Target | Note |
|---|---|---|
| Availability | 99.5% | Single region, no failover. Upgrade path priced under running cost |
| Backups | Daily · 7-day retention | RPO 24h · RTO 4h |
| Data residency | India only | Mumbai region |
| API response | < 400ms p95 | Excluding gateway round trips |
| App cold start | < 3s | Mid-range Android, real device, real network |
| Listing images | CDN-served | Delivery is the constraint, not storage |
No performance baseline exists for the current site. It has never been measured on an Indian mobile network. These are the targets we would build to, not improvements on a known figure.
Security and data protection
Three areas where this build carries more weight than the current product does.
- Identity documents Aadhaar, PAN and passport images are personal data under the Digital Personal Data Protection Act. Encrypted at rest, access restricted and logged, retention and deletion defined, purpose stated at the point of collection.
- Payment data Card and bank details never touch our servers. Collection happens inside the gateway's own checkout and we store references rather than instruments.
- Audit trail Every administrative action on a listing, document or payment is recorded with actor and timestamp. This matters more than usual given the verification promise the product makes.
This section needs a legal read, not an engineering one.
Three items sit outside what we can advise on: DPDP obligations around Aadhaar handling, the payment structure if funds pass through RoomRR, and the preferred-tenant filter. We will build to whatever position your advisor sets.
Two phases, seven roles, working software every week.
Starting 31 August. Phase 1 lands the platform; Phase 2 lands the app in both stores. Each phase is commissioned separately and stops cleanly.
Platform
- Access review and schema mapping
- Core backend and API
- Admin web application
- Documents and payments service
- Event instrumentation
- Infrastructure and deployment
Mobile
- Tenant experience, end to end
- Owner experience, end to end
- Listing creation with photographs
- Rent, invoices, receipts, documents
- Store submission, Android and iOS
- Production monitoring
Team
These are the people who will be working on the solution.
| Role | Responsibility |
|---|---|
| Backend developer, senior | Data model, core API, payments and documents service, and integration with the existing platform |
| Backend developer, mid | Endpoint and service work against that model, event instrumentation, environments and deployment |
| Frontend developer | Admin web application and the web surfaces the platform needs |
| Mobile developer | React Native application, both platforms, through store submission |
| Designer | Product design across mobile and admin, running ahead of build |
| QA engineer | Test plan, functional and payment testing, cross-platform, regression, store validation |
| Business analyst | Scope documentation, sprint planning, decision logging, weekly review and UAT coordination |
What we set up together, and when
The three in bold depend on approvals from outside either of us, so starting them early gives everyone room to work with.
| Item | What it unlocks | Best started |
|---|---|---|
| Repository and database access | Lets us scope precisely and build on what already exists rather than around it | Before start |
| Apple Developer account | Opens the iOS release path. The D-U-N-S number behind it comes from Dun and Bradstreet, usually in one to two weeks | Week 1 |
| SMS provider and DLT registration | Clears sender-ID and template approval, so logins and receipts can reach users | Week 1 |
| Brand assets | Lets design start from your identity rather than an interpretation of it | Week 1 |
| Decisions on scope | Settles masked numbers and the preferred-tenant field, which shape what gets built | Week 1 |
| Payment gateway account | Opens integration and testing against real transactions | Week 2 |
| Google Play account | Opens the Android release path | Phase 2 |
| A named reviewer | Gives the weekly demonstration a decision-maker in the room | Ongoing |
How we work
Working demonstrations every week from week two. Not status reports, but running software you can use. Scope decisions are made in that session, and it is the only recurring commitment we need from your side.
You have indicated end of October. That is nine weeks from a 31 August start, against a scope that has grown since the technical outline: full discovery in the app, photograph upload, identity verification, rent collection, and completion of a mobile skeleton we have not yet seen.
Our position is that Phase 1 lands inside that window and Phase 2 follows.
A fixed core, and everything else priced on its own.
The two phases below are what we would build regardless. After them sits a set of optional modules, each priced on its own so you can see what it costs before deciding on it. Every figure is built from an estimate of seventy-seven tasks costed against a role rate card; the full breakdown is available if you want it.
Phase 1 · Platform
| Item | INR |
|---|---|
| Access review and schema mappingRepository and database assessment, integration surface, scope confirmation | — |
| Core backend and APIUsers, owners, properties, listings, search, enquiry | — |
| Admin web applicationListing review, verification, users, payments, health, analytics | — |
| Documents and payments serviceRent collection, invoices, receipts, identity documents | — |
| Event instrumentationSearch, listing, contact and conversion events | — |
| Infrastructure and deploymentEnvironments, CI, monitoring, backups | — |
| Business analysisScope documentation, sprint planning, decision logging, weekly review and UAT coordination | — |
| Phase 1 total | — |
Phase 2 · Mobile
| Item | INR |
|---|---|
| DesignBoth roles, all screens, running ahead of build | — |
| Tenant experienceDiscovery, search, listing, contact, rental, payments | — |
| Owner experienceListing creation with photographs, enquiries, rentals, settlements | — |
| Documents and identityCapture, upload, invoices and receipts | — |
| ReleaseBuilds, store submission, production monitoring | — |
| Quality assuranceTest plan, functional and payment testing, cross-platform, regression, store validation | — |
| Phase 2 total | — |
Optional modules
None of these are assumed. Three are ticked because we think you should have them, not because they are included. Tick anything to see what it adds, and untick it to take it back out. The total moves with every change.
Schedule and terms
| Stage | Share | INR |
|---|---|---|
| On signatureReleases the team and starts the access review | 10% | — |
| Phase 1 acceptancePlatform, admin console and payments service accepted | 40% | — |
| Phase 2 acceptanceMobile application accepted on both platforms | 30% | — |
| UAT handoff and final sign-offUser acceptance testing complete, handover done | 20% | — |
| Total | 100% | — |
One month from release of each phase, with user acceptance testing running in parallel. Defects against the agreed specification are fixed at no charge. New requirements go through change control and are quoted before work starts.
Optional modules can be added later at the same price, with the exception of owner number masking and listing expiry, both of which get materially more expensive once real listings and real contact history exist.
Beyond the warranty we propose a monthly retainer at ₹45,000 covering maintenance, monitoring, store releases and an allowance for new work. Quoted separately and deliberately not added to the totals above, since it is ongoing rather than part of the build.
Two kinds of cost, and only one of them is predictable.
Infrastructure steps up in tiers as you grow. Messaging, email and verification scale directly with use. Move the volumes below and everything recalculates, including which tier you are on.
Your assumptions
Pick a stage to jump there, or move any slider yourself. Infrastructure steps up at defined thresholds rather than growing smoothly, so the tier follows your user count.
Fixed monthly
Set by the tier above. Does not move with day-to-day usage.
| Component | Specification | INR / month |
|---|---|---|
| Core backend and admin | — | — |
| Documents and payments | — | — |
| Managed PostgreSQLAutomated backups included | — | — |
| Object storage and CDN | — | — |
| Monitoring and error tracking | — | — |
| —Included from this tier upward | Managed | — |
| —Included from this tier upward | Managed | — |
| High-availability standbySelected under optional modules | Database standby node | — |
| Fixed subtotal | — | |
Scales with use
Quantities calculated from the volumes above. Rows marked + exist only because you selected an optional module under Investment. They are not part of what it costs to run the platform itself.
| Component | Monthly volume | INR / month |
|---|---|---|
| SMS / OTPLogins and new registrations | — | — |
| Transactional emailWelcome, receipts, statements, listing alerts | — | — |
| MapsFree below 15,000 monthly active users | — | — |
| Storage overageBeyond the 250 GB base tier | — | — |
| WhatsApp messages~5 per user monthly | — | — |
| WhatsApp platform feeCharged by the provider selected under Investment | — | — |
| Identity verificationNew users verifying each month | — | — |
| From optional modules | — | |
| Usage subtotal | — |
Fixed plus usage, at the volumes and vendors currently set: — · projected annual —
—
WhatsApp is the largest single line once it is switched on. At scale it can exceed all the infrastructure combined. That is worth knowing before selecting it, not afterwards.
Transaction costs
Deliberately kept out of the total above. This is not infrastructure you pay for. It is a percentage taken out of money passing through the platform.
| Component | Rent through platform | INR / month |
|---|---|---|
| Payment gateway2% plus GST on each successful transaction | — | — |
At scale it becomes the largest number on this page, and folding it into a monthly running cost would make the platform look far more expensive to operate than it is. Whether it is a cost to RoomRR at all depends on the revenue model. If the fee is passed to the tenant or absorbed into a commission, it is a pass-through rather than an expense.
Annual and one-off
| Item | INR |
|---|---|
| Apple Developer ProgramAnnual. Organisation account requires a D-U-N-S number | — |
| Google Play DeveloperOne-time | — |
| Domain and certificates | — |
Hold the cloud account in Prasanta Communications' name and give our team access. Your infrastructure, your billing, and no dependency on us if you ever change vendor. Converted throughout at ₹96 to the US dollar.
Everything this proposal rests on, in one place.
The discovery report opened by stating what it could not see. This section does the same job. A price that hides its dependencies is not a price. It is a guess with a currency symbol in front of it.
Assumptions
| We have assumed | If something changes |
|---|---|
| A working database exists behind roomr.in and we can integrate with it | Phase 1 grows substantially: we would be building the system of record, not extending it |
| The mobile skeleton is usable as a starting point | Phase 2 restarts from a clean project; scope re-quoted before work begins |
| Rent settles directly to owners through the gateway | Payment-aggregator obligations apply and the architecture changes |
| Verification means storing and reviewing documents | Third-party checks add a per-check cost and a compliance load |
| Hyderabad only at launch | Multi-city changes search, indexation and data volumes |
| Your team is available weekly for decisions | The timeline extends; this is the most common cause of slippage |
| Brand assets exist in usable form | Design adds a short identity workstream |
Risks we can see
- Nine weeks against the grown scope Discussed under delivery. Our position is Phase 1 inside the window, Phase 2 after.
- App store review Outside anyone's control, and first submissions are rejected more often than not. We build the buffer in rather than discovering it in week nine.
- External registrations D-U-N-S and DLT both run on other people's clocks and each can cost two weeks. Neither is technical. Both should start in week one.
- Completing another team's code We have not seen the mobile skeleton. Where inherited code cannot be built on safely, we will say so early and quote the alternative rather than absorbing it silently.
- The published Terms Your Terms currently state that RoomRR takes no part in payments or tenancy management. Collecting rent contradicts that. The document needs amending before the product ships.
Still open from the discovery work
Not part of this proposal and not priced here. Noted because they remain cheap now and expensive after launch.
Every page still returns the same title and description, and shared links still render as bare text. Hours of work.
Best designed before there is inventory to migrate.
Still no explanation of what a property code is, and one message still covers three different failures.
Still a broken link in your own footer, and still a support ticket to recover.
One decision, and four answers.
Everything below can happen in parallel, and two of the four do not depend on us at all.
To start on 31 August
This week
- Answer the four blocking questions. Whether a working database sits behind roomr.in, where rent money settles, how RoomRR earns, and what budget we are working within. These move the price more than everything else combined.
- Start the external registrations. Apple D-U-N-S and SMS DLT. Neither depends on anything else here, and both cost two weeks if they wait.
Before we start
- Repository access. For the web platform and the mobile skeleton. A day with the code turns a range into a number.
- Confirm Phase 1. Phase 2 can be decided later.
Terms
| Item | Position |
|---|---|
| Validity | 30 days from the date of issue |
| Intellectual property | Transfers to RoomRR on final payment for each phase |
| Warranty | One month from release of each phase, UAT in parallel |
| Change control | Quoted and agreed before work begins |
| Currency | INR, exclusive of GST |
The discovery work came first, before we met, and it ended by saying the findings were yours whoever did the work. That is still true, and it is the reason this document exists only because you asked for it.
You asked what it would cost to build, and this is our answer, written so you can interrogate it rather than take it on trust. Where we have assumed, we have said so. Where an answer from you would change the number, we have said which answer. That leaves us both working from the same picture, which is the part we care about most.
The ones that made you smile.
You liked a couple of the sites we pulled up in the meeting, so here is the fuller list you asked for — everything with an animation or an interaction worth stopping for. Best on a desktop, with a minute to spare.
Oryzo
An entirely fictional cork coaster, presented with the full apparatus of an AI product launch — benchmarks, an open-weight model, a research paper. Built by Lusion as a demonstration piece, and it says so at the end. The lesson is commitment: the joke works because every detail is executed as if it were real.
Inkwell
A fully interactive page for an intelligence layer product. Worth watching how the interaction carries the explanation rather than sitting alongside it.
ActiveHop
Sparkling hop water, sold through a single scroll-driven sequence end to end. A good example of a simple product carried entirely by pacing.
The Monolith Project
Entirely canvas-rendered — there is no readable page underneath it, which is itself the point of including it. Worth opening rather than describing.
Product and brand
Closer to what a real product site has to do, and still doing something unexpected.
Meter
Enterprise network infrastructure, which is about as dry as a category gets, presented with unusual restraint and confidence. Proof that a serious product does not need a serious template.
WorkOS Launch Week
A launch-week microsite sitting inside the main product site. Useful as a model for how a campaign page can have its own personality without breaking from the parent brand.
Forge
Design, build, ship, repeat. Note the loop after the “built with us” section — the page cycles rather than ending, which is either a deliberate device or a bug worth recognising before we borrow it.
More Nutrition
Matcha meets protein. A Webflow build that gets a long way on typography, colour and product photography alone — a useful reminder of how much is achievable without custom engineering.
Company sites that do not feel like company sites
The hardest category to make interesting, which is why these are worth seeing.
HUMAN MADE Inc.
The corporate site for NIGO®'s group — the fashion label, the Buffer brand and the CURRY UP shops under one roof. It carries an IR section and a careers section without ever looking like an annual report. Worth studying for how it handles many sub-brands in one structure.
Zero
Learn, build, get hired. Education positioning that leads with the outcome rather than the curriculum.
MindMarket
A qualitative research agency across sixty countries. The scrolling illustrated timeline down the middle of the homepage does the explaining — a services business made concrete through sequence rather than a list of capabilities.
Telkom OT
A Slovenian infrastructure company. Included as a counterweight to the studio work above — a reminder that most of this craft is achievable on an ordinary budget.
None of this is a proposal for what RoomRR should look like. A rental platform has different work to do than a launch page, and a tenant hunting a flat on a phone on a patchy connection is not the audience for a scroll sequence.
It is here because you enjoyed it — and because it is useful to have seen the top of the craft before deciding how much of it your own product wants. We will keep adding as things come up.
Two people worth an introduction.
Both came up when we were thinking about what RoomRR needs next — one for the market, one for the build. Everything below is drawn from what they have published themselves.
Sai Chaitanya Kokku
Proptech · HyderabadSai is building Konu, a proptech platform aimed at bringing trust, transparency and better data into Indian real estate. His stated diagnosis is close to yours — unreliable data, unclear pricing, and a trust problem — and Konu's answer is AI-driven price intelligence, verified property listings, and end-to-end support for buyers, sellers and NRIs.
Alongside that he has spent several years building the founder ecosystem in Hyderabad through Draper Startup House, now evolving into DraperU India. He describes it as a platform for creating founders and connecting Indian startups outward, and he works across both India and the US.
Mourya Kompelly
Consumer appsMourya co-founds Doffair, a pet socialisation platform and SaaS ecosystem — a consumer app for pet parents on one side, and tools for vets, groomers, trainers and NGOs on the other. Two-sided, consumer-facing, and built in India.
He describes his own work as sitting at the intersection of product thinking and customer experience, and is explicit that policy decisions — what the platform refuses to allow — are product decisions rather than afterthoughts. Doffair has a stated zero-tolerance position on illegal breeding, and he treats that as a design constraint rather than a line in the terms.
Say the word and we will make either introduction by setting up a meeting. We have not approached either of them yet — these are people we think are worth your time, not conversations already in motion.