Liat Rumah
Liat Rumah is the public face of BrokerID. It takes the listings agents already keep inside the agent app and puts them in front of the people actually buying and renting, with a WhatsApp message as the only step between a buyer and the agent.
- Next.js
- React 19
- shadcn/ui
- Supabase
- Tailwind CSS
The Missing Half
BrokerID solved a problem agents had with each other. Thousands of listings went into it, agents co-broked with each other, managed their clients, and ran their day out of it. But every one of those listings sat behind a login that only another agent could pass.
So agents kept doing what they had always done to reach actual buyers. Screenshot the listing, post it to WhatsApp status, drop it in a Facebook group, hope somebody scrolls past it that day. The listing data was already clean and structured inside BrokerID, and it was being retyped into a chat app to reach the one audience that matters most.
That is the gap Liat Rumah was built to close. BrokerID is the B2B side. Liat Rumah is the B2C side. Same listings, same database, a completely different audience.
One Database, Two Audiences
The rule I set on day one was that Liat Rumah adds nothing to the database. It only reads.
It is a third codebase on the same Supabase project, holding the anonymous key and nothing else. The service role key is not allowed anywhere near it. Everything a buyer sees comes through a single view, public_listings, and one file in the whole project is permitted to touch Supabase at all.
That constraint is what makes the two products safe to run side by side. An agent's private client records, their documents, their CRM notes, none of it is reachable from the public site, because the public site has no key that could reach it. Only listings marked for sale or for rent ever render, and everything else an agent might post stays where it was posted.
Built for Buyers, Not Agents
The hardest part was resisting the urge to make it a second agent app.
There is no sign up. No account, no saved searches, no favourites, no messaging inbox, no social features. A buyer lands on the site and can immediately do the only three things a buyer actually wants to do: search by keyword, area, or agent name, narrow it down by price, land size, building size, and rooms, and then contact the agent directly on WhatsApp.
Every screen is in Indonesian, because that is the language of the people buying houses here. Buttons are verbs, never labels. Tampilkan hasil, not OK. A buyer should never have to guess what a button will do.
A Feed, Not a Search Form
Every property site in Indonesia opens the same way. A hero image, a big search box, and a form asking you to pick a city, a property type, and a price range before you are allowed to see a single house.
I did not want that. Someone opening Liat Rumah on their phone during a lunch break is not ready to fill in a form. They just want to look at houses.
So the site opens the way Threads and Instagram open. You land straight on a feed of real listings and you scroll. The agent's name and office sit at the top, their own words underneath, then the price and specs, then the photos. It reads like a post because it is a post, written by the agent, not squeezed into a property card template.
The whole shell follows from that. A slim icon rail down the left holds home, search, and filter, the feed sits centred beside it, and on mobile the rail becomes a bottom bar exactly where a thumb already rests. Filtering is something you reach for once you know what you want, not a toll gate you pay on arrival.
The palette is deliberately monotone, with no hue in any token anywhere. Property photos are loud, mismatched, and covered in watermarks. The interface stays out of their way so the houses are the only colour on the screen.
Screenshots
The feed, a filtered feed with its active chips, the filter sheet, an SEO category page, a listing detail with its WhatsApp handoff, and the full screen photo lightbox.
Making Google the Front Door
A B2C property site lives or dies on search. Nobody wakes up and types in a brand new property site's name, they type "rumah dijual di tangerang" into Google.
So the site generates a category page for every combination worth having. /rumah-dijual-tangerang, /apartemen-dijual, /dijual-jakarta, each one statically generated, revalidated hourly, and carrying its own title, description, breadcrumbs, and structured data.
Which pages exist is decided by the listings themselves, not by a keyword list I guessed at. One pass over the catalogue counts how many listings fall into every possible slug, and anything too thin to be useful is left out of the prebuild, out of the sitemap, and marked noindex. That way a page is never in the sitemap while telling Google to ignore it.
Individual listings sit at /properti/<kata-kata>-<id>, so the words in front of the id can change as a listing gets edited without ever breaking a link somebody already shared.
The Messy Parts
Real data is never as tidy as the schema suggests.
Agents have been typing city and area names by hand for years, so roughly sixty spellings reach the database for about a dozen cities. Jakarta, jakarta, DKI Jakarta, Jkt. Every query folds those variants together in one place, so a lowercase city is not treated as a different city, and Jakarta as a page is the union of its five kota.
Filters live in the URL in Indonesian, cari, tipe, properti, harga_min, because a buyer sees that URL in the address bar and shares it with their spouse. Changing a filter is a navigation, not local state, so the link a buyer sends is always the exact result set they were looking at, and it is the indexable version of that link whenever one exists.
Nothing on the site snaps. Changing a filter fades the old results out and animates the new ones in, filter chips animate away as you remove them, and the return to the top of the feed is animated by hand because a feed resetting under a native smooth scroll cancels it halfway.
Tech Stack
- Next.js App Router - server rendered feed with an infinite scroll client fetcher for page two onward
- React 19 + Tailwind v4 - shadcn components built on Base UI, dark mode through next-themes
- Supabase - the same PostgreSQL project BrokerID writes to, read here through the anonymous key only
Looking Ahead
Liat Rumah exists so an agent's work does not stop at the edge of the agent app. Every listing they enter into BrokerID now reaches buyers on its own, gets indexed, and can be shared as a link that survives.
The next stretch is about reach. More category pages as the catalogue grows, better structured data, and eventually giving agents a public profile that a buyer can browse the way they would browse a listing.
Want to talk about this work? Email me.