AddThisFeature

Google Places Address Lookup

Turn a half-typed address into a structured location the app can rely on.

involved Integrations

What it adds

An address autocomplete that fills structured location fields from real places and stays editable by hand.

What your agent is told to do

5
  1. 1

    Replace free-text address entry on the forms that need a real location with a lookup returning structured components, and keep every component field editable after the lookup returns.

  2. 2

    Group the keystrokes of one lookup into a single billable session and close it when a place is chosen or the field is abandoned. Debounce input and set a minimum query length, because every keystroke that reaches the provider costs money.

  3. 3

    Store the provider's place identifier in its own field, separate from the human-readable address the user sees. The two serve different purposes, and the display text must never be parsed back into structure.

  4. 4

    Route requests through the server, or restrict the client credential by referrer and to the single capability it needs. An unrestricted key in a public page will be scraped and spent by someone else.

  5. 5

    Mapbox Geocoding covers coordinate conversion and reverse lookup. Where both exist, assign one provider per field and say which — do not send the same query to two providers and try to reconcile the answers.

Edge cases it handles

8
  • Suggestions are frequently incomplete for apartments, units, floors, and rural addresses. Always allow manual correction, and never block a save because the provider did not recognise the address.
  • Address structure differs by country: postcode position, the presence of a state or province, and street ordering are not universal. Map components generically rather than assuming one national format.
  • A business result and an address result are different things. Decide which the field accepts and filter accordingly, or a user picking a shop name saves a location with no street.
  • Address queries are personal data. Keep raw lookup queries out of general application logs and put a retention limit on anything that is kept.
  • Place identifiers can be retired or replaced over time. Keep the resolved components as well, so a stale identifier does not leave a record with no usable address.
  • The provider's terms restrict how long results may be cached and what may be stored. Cache only what is permitted and re-resolve rather than warehousing full responses.
  • Quota exhaustion or an outage must leave the plain text field usable so the user can still finish the form.
  • Keyboard users must be able to move through suggestions and choose one without a mouse, and the suggestion list must be announced to screen readers.

Definition of done

9
  • Structured address components are captured and every one remains editable by hand.
  • Lookups are debounced, grouped into a session, and the session is closed when the field resolves.
  • The provider identifier is stored separately from the displayed address text.
  • No unrestricted credential is exposed to the browser.
  • A user can save a valid address the provider never suggested.
  • Raw location queries do not appear in general application logs.
  • Provider unavailability leaves manual entry fully working.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.