Skip to content
Lunaris

Build notes

A marketplace built for land, not houses.

Every property portal is built around bedrooms and bathrooms. Land has neither. We're building the one where the most important field is a boundary on a map, and the most important question is what you're allowed to build on it.

Written while building. Updated when there's something worth adding.

Parcel boundary · schematicVertices are pegged corners · heavy edge is road frontage
Type
Product · Internal Lunaris build
Stack
Next.js 15 · Prisma · PostgreSQL + PostGIS · MapLibre

Context

Generic property portals handle land badly. A plot gets a single pin, a price and three photos of a field, and the buyer is left to establish the zoning, the utilities and the legal status by phone. Every serious enquiry starts from zero, which makes the listing close to worthless to both sides.

The problem

Land buyers ask a different set of questions from house buyers, and they ask them in a fixed order.

  • 01What am I allowed to build here?
  • 02What's the legal status of the title?
  • 03Is there power, water and road access?
  • 04What's the price per square metre compared to the plot next door?
  • 05Where exactly does the boundary run?

Not one of those is a field in a standard property portal.

What we're building

  • Boundaries, not pins

    Every listing carries a real polygon, stored in PostGIS and drawn on the map. You see the shape, the orientation and the frontage — not a dot on a map.

  • Zoning and legal status as primary filters

    Agricultural, residential, commercial, industrial and recreational are first-class fields, alongside cadastral number and title status. They are the first filters a buyer reaches for, so they are indexed, not buried in a description.

  • Utilities that decide the price

    Electricity, water, gas, sewage and road access, each with distance to the nearest connection point.

  • Price per square metre everywhere

    Always shown beside the total. It is the only figure that makes two plots comparable.

  • Map as the search interface

    Draw an area, filter within it, and the results update — rather than choosing a region from a dropdown.

Architecture

  1. 01Next.js App Router
  2. 02Server-side query layer
  3. 03Prisma
  4. 04PostgreSQL + PostGIS on Supabase

The binding constraint was geospatial. Prisma doesn't model geometry types, so spatial queries — bounding box, radius, polygon containment — are hand-written SQL, confined to one query module and indexed with GiST. Every database call goes through that layer, which means the data tier can be replaced with a Spring Boot service later without the application noticing.

Why Next.js and not Spring Boot

Our default stack for client work is Java and Spring Boot. We deliberately didn't use it here. This is a product MVP where time to a working marketplace mattered more than architectural purity, and a single codebase on Vercel gets there sooner. The trade-off was made deliberately, the seams were kept clean, and the migration path is still open. Choosing the right tool includes choosing against your favourite one.

Results

Nothing here yet. This section is for measured numbers — search response time under load, listing volume, indexed pages, Lighthouse scores — and it stays empty until there are some. We'd rather leave a gap than fill it with projections.

Stack

  • Next.js 15
  • TypeScript
  • Tailwind CSS v4
  • Prisma
  • PostgreSQL 16 + PostGIS
  • Supabase
  • MapLibre GL
  • Auth.js
  • Vercel

Got something that doesn't fit off-the-shelf software?

That's the work we're best at, and the work we want more of.

Start a projectAll work