Local Discovery Platform

Local information is more useful when you can see where it belongs. I’m building a shared map where people and businesses can publish, discover and discuss the places around them.

The idea

A map gives information geographic context; a synchronized list makes it easier to compare and explore. Both should tell the same story as someone moves around, changes a filter or opens a result.

Individuals and businesses are distinct publishers. Someone can share location-linked material without creating a business, while a business can maintain its presence and publish through authorized team members.

The experience

The connected workflows cover discovering visible content, publishing and managing your own material, maintaining business information and saving useful items. Business-linked questions and recommendations give discussions a place and a subject, with replies kept close to that context.

Visibility is part of the product, not just a display filter. Ownership, publication state, expiry and independent moderation determine what can be found. Businesses can optionally organize publications into time-bounded campaigns; that does not imply payments or an advertising marketplace.

The architecture

The accepted application uses React and TypeScript with Leaflet for the map. One modular Go application serves the interface and its operations, backed by PostgreSQL/PostGIS and private media persistence. The modules separate responsibilities without turning each workflow into another service.

A publication passes through permission and input checks, validated image storage and a database transaction that records the publication and its result. Geographic discovery reads committed, eligible records. Change notifications prompt the interface to fetch authoritative results again rather than treating a notification as a replacement for stored state.

One result set, two views

A map pin that disappears from the list—or an expired item that occupies a page of results—makes discovery hard to trust. Geographic bounds, text and category filters, visibility and ordering are applied before pagination, so the map and list use the same eligible set.

Paging cursors are scoped to the query, with stable ordering for ties. When committed content changes, the interface refreshes from the shared discovery source and guards against stale responses replacing a newer view. This keeps moving the map and reading the results part of one workflow.

Authority follows the operation

A team member might open an editor and then lose a business role before saving. Hiding a button would not protect that operation. The application checks current authority inside the write path, including when a caller retries an earlier request.

Personal ownership and business roles remain distinct, and business membership does not grant moderation authority over other people. Independent moderation has its own checks and recorded decisions. A restore also respects other visibility rules: it cannot make a withdrawn or expired publication discoverable.

An interrupted request is not a verdict

A database can commit successfully even when its reply never reaches the browser. Conversely, storing image bytes does not mean a publication was committed. The application treats those boundaries separately, recording operation receipts with database changes and tracking staged media so incomplete work can be cleaned up.

When an acknowledgement is lost, the interface does not manufacture success or blindly repeat a write. An explicit retry with the same operation key and request can recover the recorded result, subject to current permission checks. A stale edit requires review. Controlled local tests exercised lost commit acknowledgements, interrupted responses and restarts; they do not establish completed hosted recovery.

Reconstruction and evolution

The recorded history has two separate windows: 2019–2022 and a return in 2025–2026. Earlier implementations became evidence for a deliberate reconstruction around the selected architecture, rather than a claim of uninterrupted development.

The reconstruction connected publishing, discovery, business and community workflows and validated them with browser journeys, database checks and controlled failures. The subsequent work moves into containerized delivery and restricted infrastructure qualification.

My contribution

This is owner-led, AI-assisted engineering. I set the product direction, architecture and policy decisions, write specifications, coordinate implementation, review technical evidence and accept the results. The work includes deciding what the product should promise—and what the implementation has actually demonstrated.

Current progress

The core application has been accepted through controlled local workflows, with containerized delivery and restricted AWS infrastructure qualification in progress. Public production deployment is not established; local acceptance and cloud delivery remain separate milestones.