A property marketplace app built to be rebranded
One codebase, resold under different brands — where the app's name, tagline, colours and logo are controlled from an admin panel rather than hardcoded and rebuilt.
The context
A property marketplace covering rent, buy and sell across several Indian metro markets. The commercial requirement was unusual: the same product needed to be resellable under different brand identities, so that partners could operate it as their own app without a separate development cycle each time.
That constraint shaped the architecture from the start. Branding couldn't be compiled into the app — it had to be data.
What we built
White-label control panel. App name, tagline, colour scheme and logo are set from the admin side and applied to the consumer app. Relabelling becomes a configuration change rather than a development project.
Buyer and owner modes. The app serves both sides — people searching for property and people listing it — across rent, buy and sell, with different flows for each rather than one generic listing screen.
Video-first discovery. A swipeable, Reels-style video feed for property listings. Property search is conventionally a filter-and- grid experience; presenting listings as a vertical video feed is a genuinely different discovery model for this category, and it suits how people actually browse on a phone.
Property admin. Listings managed with type, mode, price, location, approval state and publication status, plus featured and verified flags, and per-listing view counts.
Lead capture and analytics. Enquiries against listings tracked centrally, with analytics on listing performance — so owners and operators can see what's actually getting attention.
Content management. Catalogue, content and page management built in, so the operator can update the app's supporting content without a release.
The architecturally interesting part
Most "white-label" products are forked per client — which means every bug fix and feature has to be applied several times over, and the variants drift apart within a year. Driving identity from configuration instead of forks keeps one codebase maintained, which is the difference between a white-label product that stays viable and one that quietly becomes several half-maintained apps.
What we can and can't claim
We're describing what was built and how it was architected. We haven't published user numbers, transaction volumes or revenue outcomes, because those belong to the client and we don't have permission to share them.
Related
If you're in property, see real estate software and sales CRM. For app development generally, see mobile app development.
