Nemuhunian, AI Property Marketplace

Role: Founder + sole engineer. December 2025-present. Site: nemuhunian.com · Instagram · Threads · 700+ properties listed · 25K+ followers

TL;DR

Problem: Property sellers pay 2-3% agent commission, and buyers lack direct access to owners.
Solution: A zero-commission property marketplace connecting owners directly with buyers.
Tech Stack: Next.js (SSR), Laravel (Admin), Go (API), Cloudflare R2 (Storage), AI (Semantic Search & Generation).
Traction: 700+ properties listed and 25K+ Instagram followers within 7 months.

Why I Built This

The premise is simple: property sellers in Indonesia typically pay 2-3% commission to agents, and buyers have no direct line to owners. Nemuhunian changes that. Owners pay a flat listing fee to advertise their property directly across the platform (Instagram, Threads, Facebook, and the web), and buyers reach them without going through a broker.

The pricing is intentionally accessible: around IDR 100K to list on the web platform, or IDR 200K for the full package (web listing plus a boosted post on the Instagram account). Inquiries from buyers go straight to the owner via WhatsApp, handled by two CS admins who manage conversations manually. It’s a deliberately simple operation. The admins earn commission per listing, the workload is light, and replacing them with AI isn’t something I’m planning. This approach works and keeps humans in the loop for a trust-sensitive transaction.

I started with Meta Ads to validate demand, targeting property owners who wanted to sell independently. The core stack at that point was Laravel + Filament for the backend and Next.js CSR for the frontend. It worked well enough to learn from, but “well enough” quickly surfaced a series of problems worth solving properly.

How It Evolved

The SEO problem, and why we switched to SSR. The first real growth blocker was search. A CSR Next.js app is essentially invisible to Google. The crawler sees an empty shell, not property listings. I had to learn this the hard way. Switching to SSR was the fix, but I paired it with everything else that actually moves the needle for a listing site: proper URL structure (nemuhunian.com/properti/bogor), a generated sitemap, compressed WebP images, and AI-generated listing descriptions and Instagram hashtags to make content more indexable without manual copywriting for every listing.

The frontend is simpler than I thought. Early on the site had a fancy hero banner. I removed it. Nobody searching for a property in Bogor cares about a banner, they want the listings fast. The redesign went minimal: search front and center, listings immediately visible, no decorative friction. Conversion improved. The lesson wasn’t about design taste, it was about knowing who your user is and what they’re actually trying to do in the first 5 seconds.

The CDN and storage problem. Property listings are image-heavy. Once listings grew, the server started filling up. Images living alongside the application was never going to scale. I separated media into a CDN, then migrated to Cloudflare R2 (S3-compatible object storage) when self-managing the CDN became its own maintenance burden. R2 solved both the storage problem and egress costs, since Cloudflare doesn’t charge for bandwidth out.

The API performance problem, and why I’m learning Go. PHP/Laravel is fast enough for most things. But when I profiled the property search API under load, the headroom wasn’t there. I started exploring Go for the API layer and found a ~60× throughput improvement over the equivalent Laravel endpoint for the same workload. That was enough to commit to a split architecture: Laravel handles data input and admin (where developer ergonomics matter), Go handles the read-heavy search API (where performance matters), Next.js on Vercel serves the frontend, and Cloudflare R2 holds all media.

AI Search and Generative Descriptions. I integrated AI to streamline content creation and enhance discovery. First, I built an AI-powered description generator to automatically draft detailed, SEO-friendly property descriptions and optimized Instagram hashtags based on the property details provided by owners. Second, I introduced a user-facing AI Search. Instead of forcing buyers to manually adjust filters and dropdowns, they can search using natural language (e.g., “3-bedroom house under 1 billion rupiah in Jabodetabek with a garden”). The Go API parses the query’s semantic intent via an LLM, generating structured database filters that serve matching listings instantly.

Current Architecture

Frontend  → Next.js (SSR, deployed on Vercel)
Backend   → Laravel + Filament (data input, admin, CMS)
API layer → Go (search and read endpoints)
Storage   → Cloudflare R2 (property images, CDN)
Marketing → Meta Ads + Instagram (25K+ followers) + Threads + Facebook
AI        → Content generation + natural language property search

What I’ve Learned

Distribution is as hard as the product. Building the platform was the easy part. Getting property owners to trust a new platform over established ones, and getting buyers to know we exist, is a different kind of problem entirely. In 7 months we’ve grown to 700+ listed properties and counting, with Meta Ads and a 25K+ Instagram following as the main acquisition channels.

The most counterintuitive thing I’ve learned about ads so far: scaling spend up did increase revenue, but when I pulled back on spending, revenue dropped while profit margin went up. My working hypothesis is that a larger ad budget pushes reach into audiences that are too broad, where conversion rates are lower and cost per acquisition climbs. A tighter, more targeted spend seems to hit a more qualified audience even if the total volume is smaller. I haven’t fully validated this yet, it’s more of an observed pattern than a researched conclusion, but it’s changed how I think about growth. More spend isn’t always better, and the right audience matters more than the biggest audience.

Performance decisions should come from data, not intuition. I nearly over-engineered the backend early on because fast APIs felt important. The actual bottleneck was images, specifically uncompressed images served from the same server as the application. The Go API decision came later, and only after I had real profiling data to justify the split. I’d have wasted weeks chasing the wrong thing if I hadn’t measured first.

SEO is infrastructure, not an afterthought. The CSR-to-SSR migration was painful and took longer than it should have. If I’d understood how Google indexes dynamic apps before starting, I would have built SSR from day one. For any content-driven product where organic search matters, this is a foundational decision, not a later optimization.

The most important question is still open. We have 700+ listings and a working platform. What I don’t have yet is enough closed transactions to say with confidence that listing on Nemuhunian actually helps owners sell. The platform is young, the seller base is still small, and I haven’t been able to collect meaningful testimonials. That’s the real thing I’m still figuring out. Not the tech, not the ops, but whether the core promise actually holds. Everything else is detail until that question is answered.