1. Work
  2. Web and product engineering

Map-based land listings site

A map-based listings site where buyers browse real lot boundaries on satellite imagery, compare and inquire, and a listing agent publishes lots with drawn boundaries, document checklists and hazard notes.

Problem

Land buyers, remote buyers most of all, struggle to judge a lot's location, shape, size and paperwork from text-only classifieds. The agents who list lots on sellers' behalf lack a simple way to show exact boundaries, say how reliable those boundaries are, and keep track of inquiries.

Goal

Buyers browse lots as real boundaries on a satellite map, filter, compare, save favourites and inquire. A listing agent publishes lots with drawn boundaries, a document checklist, hazard notes and a stated boundary confidence, then works each inquiry from new to closed.

My role

Sole product designer and full-stack developer of my own product.

Solution

A full-stack web application with a satellite browse view, a listing wizard with polygon drawing and automatic area, a comparison table, inquiries, favourites and an admin area, backed by a hosted Postgres database with managed sign-in.

How it works

Each listing stores a boundary polygon, a centre point and structured attributes: area, price, title type, zoning, road access, utilities, hazard flags, boundary confidence (approximate or survey-based), a document checklist and a status.

The browse page draws polygons coloured by status beside listing cards driven by the filters. Cascading filters (region, then locality) use a standard administrative-area code list and move the map with zoom rules for each level.

In the wizard, the listing agent draws the boundary on the map; the area is computed with geodesic geometry and shown in relatable units.

The detail page shows the polygon to scale, lot metrics, a currency converter for remote buyers, and sharing by link, QR code or the device's share sheet.

Sign-in offers email and password or a Google account, with the session exchanged into a server-side cookie.

Listing cards use static map thumbnails to keep the browse page light.

Technical challenges

Geocoding small localities where the mapping provider's coverage is weak, settled on autocomplete lookups with component restrictions and minimum zoom levels after trying several approaches.

Blank maps caused by nested providers and initialisation timing in drawing mode.

The sign-in cookie exchange in a server-rendered app.

A period of watermarked, blurred boundaries for anonymous visitors, later reversed by a product decision.

Several multi-model review rounds, each ending in a batch of fixes.

A map and a list sharing a small phone screen.

Capabilities

  • Satellite browsing with status-coloured lot boundaries
  • Cascading location filters
  • Lot comparison with best-value highlights
  • Boundary drawing with automatic area
  • Document checklist and hazard flags
  • Currency conversion for remote buyers
  • Sharing by link and QR code
  • Favourites
  • Inquiries with status tracking
  • Admin management
  • Responsive design

Technology

  • Next.js App Router with TypeScript
  • Tailwind CSS
  • Google Maps JavaScript API
  • Map drawing and geocoding
  • Places and static maps
  • Turf.js for geodesic geometry
  • Managed authentication with hosted Postgres
  • Vercel

Impact

A working product covering the full buyer and listing-agent journey on free-tier infrastructure.

Skills demonstrated

  • Full-stack product development
  • Map interfaces and geospatial geometry
  • Integration with a map API under weak data coverage
  • OAuth in server-rendered apps
  • Responsive user experience
  • Review-driven quality improvement

Demo

Planned

A fictional area (or randomised coordinates over open land) with six to eight invented listings, one fake listing agent and a few fake inquiries: browse by status colour, narrow with the cascading filters, draw a boundary and watch the area update live, compare three lots, and submit an inquiry that appears in the agent's inbox and moves from new to closed. No real place names, utilities or people.

Not built yet. A demo here uses only invented names and data.

All work