Hackathon Project

PropertyAgent

Search Singapore property in plain English, get an instant fair-value verdict, and book the viewing — no agent required. Built in 9 days for the Google Cloud Rapid Agent Hackathon, Elastic partner track.

Product Manager · built with Wai Lun, full-stack engineer Next.js · Google ADK · Gemini 2.5 Flash · Elasticsearch Live demo → GitHub →

The Idea

Going DIY on a Singapore property transaction is meant to save the commission — 1–2% for buyers, 2% for sellers, half a month to a full month's rent for tenants and landlords. In practice, most people hit an information and compliance wall instead: search, valuation data, and legal timelines all live on separate platforms with nothing synthesizing them. Existing chatbots don't close that gap either — they answer questions, but they don't act. PropertyAgent started as our answer to that gap for the Google Cloud Rapid Agent Hackathon: an agent that searches, evaluates a price, and books the viewing, instead of a search bar with a chat widget bolted on.

My role: I was the PM on this one, not the engineer. I framed the problem, wrote the personas and the PRD, and made the scope calls against a hackathon deadline. Wai Lun built the full stack. This case study covers what I owned — the problem framing, the requirements, and what got cut and why — not the code.

The Pain Points

These map straight to what we actually shipped in 9 days, not the full platform vision in the PRD — see Scoping It for what didn't make the cut.

"An agent's commission is 1–2% of a sale, or a month's rent — just to have someone tell me information that's mostly already public."

"Pre-set filters exclude places that don't fit rigid criteria — and I don't even know what I'm missing."

"I have no idea if a price is fair. Bid too high and I overpay on COV, bid too low and I lose the flat."

"Coordinating a viewing means messaging multiple owners across different platforms and juggling everyone's calendar by hand."

Customer Journey

We mapped this against Josh, a first-time buyer persona from the pitch deck, to keep the pain points tied to something concrete — and to be honest about where the hackathon build stops short of the full PRD vision.

Persona

Josh — first-time HDB buyer, going DIY to avoid the agent commission, has never done a resale transaction before

Scenario

Josh needs to find a flat that fits his lifestyle, book viewings without the usual back-and-forth, and know whether an asking price is worth bidding on — all without a buyer's agent.

Discovery & Search Viewing & Shortlisting Offer & Bidding Admin Completion
Touchpoint Conversational search bar Property modal → agent chat Valuation verdict panel HDB resale process (off-platform)
User Actions Describes the flat he wants in plain language; agent returns matches on the map Opens a shortlisted listing, asks the agent about the deal, requests a viewing slot Reads the Overpriced / Fair / Good deal verdict and comparable price range before deciding to bid Continues the OTP, valuation request, and HFE process manually, outside the platform
Emotion 🤔Curious 🙂Relieved 😎Confident 😕On his own again
Pain Point Rigid filters miss what he's actually looking for Manual coordination across owners and platforms eats time No anchor for what to bid — fear of overpaying or losing the unit No single source of truth for statutory deadlines
PropertyAgent Response Extracts structured filters from open-ended text, searches a live Elasticsearch index instead of dropdowns Agent checks calendar free/busy and books the viewing directly via the Google Calendar API Compares listing PSF against percentile benchmarks from comparable listings, returns a verdict plus fair-price range — out of hackathon scope
The bet: if Discovery-to-Viewing already feels faster than switching between five listing sites, the agent earns the right to go deeper into the transaction next — starting with valuation, then scheduling, and eventually the statutory workflow the full PRD envisions.

Scoping It

The PRD I wrote covers a full platform — Singpass verification, statutory milestone tracking, contract generation, monetization. Nine days with one engineer meant almost none of that could ship. Every cut needed an actual reason.

Cut, and why

  • Singpass verification & MyInfo pull — needs real government API access and legal review, not a hackathon sandbox
  • Statutory milestone tracker (OTP, Request for Value, Resale Application) — high compliance surface area; needed real HDB data plumbing we didn't have time to build safely
  • Multi-language translation layer — nice to have, not core to proving the agent loop
  • Legal document generation (CEA tenancy agreement, OTP auto-fill) — regulatory risk, not something to prototype under deadline
  • Monetization (premium pass, legal closure kit, affiliate fees) — not needed to prove the concept

Kept, and why

  • Conversational search over Elasticsearch — the core "beyond rigid filters" bet, and the reason for the Elastic partner track
  • Auto-scheduled viewings via Google Calendar — the clearest "no manual coordination" win, small enough to ship in days
  • Instant valuation verdict — a percentile-based read on price, without needing a licensed financial advice product
  • A synthetic ~700-listing dataset instead of live HDB/URA feeds — sidesteps data-access and licensing lead time while still proving the search-and-valuation loop end to end
Caught myself: the PRD called for a "walk-away price ceiling" from a full bidding simulator. What we could actually ship in a week was a directional verdict, not a hard number — and framing it as a verdict rather than a guarantee turned out to be the more honest claim anyway.

Requirements

The PRD turned scope into criteria specific enough that Wai Lun could check a build against them without asking me what I meant. A few examples:

  • Filter extraction returns typed values through a function-tool call the frontend merges directly — no text-parsing fallback in production
  • A valuation verdict always states Overpriced / Fair value / Good deal plus the % deviation from median comparable PSF — never a bare label with no number behind it
  • The agent auto-detects whether a message is a search request or a market question, and only calls the filter tool for the former, so analytics questions never corrupt the active filters
  • Viewing requests check the host's live Google Calendar free/busy before offering a slot — never book blind

Technical Approach

One call shaped the rest: routing search and valuation through Elastic's own Kibana Agent Builder MCP server, rather than querying Elasticsearch directly from application code — a requirement of the hackathon's Elastic partner track, and the reason filter search and valuation numbers reflect a live index instead of hardcoded logic.

Google Cloud Run (Next.js App)
Next.js Frontend
  • Agent chat panel
  • Property list & map
  • User calendar view
Next.js Backend
  • Calls agent to build property filters, returns to frontend
  • Executes ES queries
  • Books viewings for user
Google OAuth 2.0 accounts.google.com
Google ADK Agent
  • FunctionTools — extract_property_filters, get_free_slots, create_viewing_event
  • MCP Toolset — generate_esql, execute_esql, get_index_mapping, search, get_document
Vertex AI gemini-2.5-flash · asia-southeast1
MCP over HTTP (ES|QL) — search & valuation queries
Calendar API calls — free/busy & create event
Elastic Cloud
  • Kibana Agent Builder MCP — /api/agent_builder/mcp
  • Elasticsearch — property index, ~700 SG listings
Google Calendar API
  • Free/busy queries
  • Create viewing events
Why: putting search, aggregations, and even ES|QL generation behind Elastic's MCP tools — instead of writing our own query layer — meant the agent could reason about the index directly, and it's what qualified the build for the Elastic partner track.

Building It

Nine days, one engineer, each stage sitting on top of something that already worked before the next layer went on.

Data foundation
Synthetic ~700-listing Singapore property dataset generated and bulk-ingested into Elasticsearch with a geo_point mapping.
Search MVP
Next.js scaffold, chat panel, and a first working search-and-chat loop against the index.
Renamed to PropertyAgent, valuation logic added
Property valuation feature and multi-select filters (town, furnishing) shipped alongside the rename.
Switched to Gemini 2.5 Flash
Agent moved onto Gemini 2.5 Flash via Vertex AI mid-build, replacing the earlier model.
Valuation panel & listing images
Valuation moved into the property modal directly; listing photos added for realism.
Deploy to Cloud Run
First deployment to Google Cloud Run, with image accessibility fixes to follow.
Viewing booking
Google Calendar free/busy and event-creation tools wired into the agent; map legend and filter fixes.
Submission prep
Auth removed so hackathon judges could reach the live demo without credentials; README, license, and architecture diagram finalized.

Acceptance criteria

  • Filter-extraction tool call returns typed values the UI merges directly, with no text-parsing fallback in production
  • Valuation verdict always pairs a classification with the fair-price range behind it
  • Calendar booking checks free/busy before offering a slot to the requester

Risks encountered

  • The model swap to Gemini 2.5 Flash landed mid-week, which meant re-validating agent behaviour late in the build
  • Map pins failed to render on initial load in one build — caught and fixed before demo day
  • Auth was pulled entirely just before submission so judges could reach the demo without credentials — a reasonable call for a judged demo, not how this would ship to real users
Trade-off: a 9-day team hackathon means the PM's job is deciding what doesn't get built, not just what does — see Scoping It for the calls that mattered most.

What's Next

Straight from the pitch deck's closing slide — the gaps we know about:

  • Buyer & seller verification logic, to eliminate ghosting, lowballing, and false signals in self-directed deals
  • A structured, data-backed bidding flow that goes beyond a directional verdict to lower emotional friction at offer stage
  • A step-by-step statutory milestone tracker — the Administrative Completion stage flagged as unbuilt in the Customer Journey above

Reflection

The real difference between this and a solo project: my job wasn't writing code, it was making sure Wai Lun never had to guess what "done" meant, and being decisive about what didn't survive contact with a 9-day deadline.

Next time: scope the language of a feature as carefully as its logic. Calling the valuation output a "verdict" instead of a "prediction" wasn't just wording — it set the right expectation for what a percentile comparison can and can't promise.
Next time: write requirements as things checkable against a running agent, not just user stories. The PRD lines that held up best under a hackathon deadline were the ones specific enough to verify without asking me what I meant.