Short answer: GharKhoj is a live, map-first rental listing platform built for the Kathmandu housing market, and the biggest lessons from building it were about product decisions (map before list, real messy data before clean data, scope discipline), not about any particular technology.
GharKhoj started from a specific, ordinary frustration: finding a room or flat to rent in Kathmandu mostly still happens through word of mouth, scattered Facebook posts, and paper notices, not through any single searchable place. Building a platform to fix that taught me more about product decisions than about any particular technology. It's one of the full-stack development projects I'm most often asked about, so here's the actual breakdown.
Why does the map have to come first, not last?
The first version of the plan had a fairly conventional structure: a list of listings, with filters, and a map as a secondary view. That was wrong, and it took actually watching how people search for housing in Kathmandu to see why. Nobody searches by formal address, they search by neighborhood, by proximity to a workplace or a landmark, by "somewhere near Baneshwor." A text-first list doesn't match that mental model at all. The map had to be the primary interface, not a feature added to a list view, and that meant rethinking the whole frontend architecture before writing much code.
That's the kind of mistake that's invisible in a spec document and obvious the moment you watch someone actually try to use the thing.
How does real-world data break clean UI assumptions?
Early development used a handful of clean, well-formed listing entries for testing. The moment real-feeling data came in, incomplete addresses, listings without exact coordinates, price ranges instead of fixed prices, several UI assumptions broke immediately. What does a map pin look like when the location is approximate, not exact? What happens to a filter when a listing's price is "negotiable" rather than a number? These aren't edge cases in this domain, they're the median case, and building the interface around the tidy version of the data first meant a real rework once messier data was actually plugged in.
The lesson that generalizes: test with the ugliest realistic data as early as possible, not the cleanest.
Why did scope discipline matter more than any single technical decision?
It would have been easy to keep adding features: user accounts with saved searches, a messaging system between renters and landlords, a review system. Every one of them is individually reasonable. Shipping a focused version, search, filter, map, contact the landlord directly, that actually works end to end mattered more than a longer feature list that was half-finished. A platform that does one thing reliably is more useful than one that does five things partially, especially for a first version meant to prove the idea holds up with real usage.
What's next for GharKhoj?
GharKhoj is live and working at its core job. The obvious next steps, user accounts, saved searches, a more structured way to handle listings without exact coordinates, are real, but they're deliberately not in the first version. Better to learn from how the current version actually gets used before building on top of assumptions about what people want next. If you're building something similar, the same full-stack development and UI/UX process applies regardless of the domain.