Coordinates stored as lat/lng pair, not derived from address at render time

Deriving coordinates from address text at render time introduces three concrete failure modes: geocoding API quota exhaustion that breaks your map entirely, incorrect marker placement when the geocoder returns an ambiguous result (CWE-20), and latency added to every page load. ISO 25010:2011 functional-suitability requires that data used for core functionality — map marker placement — is accurate and available. A listing that maps to the wrong location due to geocoding ambiguity can send users to the wrong address, which is a direct trust and safety issue for a directory product.

Geocode once at listing creation time, persist the result, and retrieve coordinates directly during rendering. The schema must enforce at least 6 decimal places to avoid precision loss.

CREATE TABLE listings (
  id UUID PRIMARY KEY,
  name VARCHAR(255),
  address TEXT,
  latitude DECIMAL(10, 8),
  longitude DECIMAL(11, 8),
  created_at TIMESTAMP
);

Call your geocoding API in the listing creation handler (src/app/api/listings/route.ts), store the result immediately, and never call a geocoding API in map rendering code. If coordinates are missing for existing rows, run a one-time backfill migration rather than deferring geocoding to page load.