- Fast nearby-search is a database problem, not an application problem — push the geometry down to PostGIS.
- Crowd-sourced data is only as good as your ability to reject bad entries; a statistical outlier detector does that without manual moderation.
- Building the detector domain-agnostic means it works for prices today and anything else tomorrow.
- Not every modern app needs an LLM. This one is better without one — and knowing that is part of the engineering.
NearMe answers two deceptively simple questions: what's near me, and can I trust what other people reported about it? It combines location search with crowd-sourced price reporting. Both halves look easy and aren't — the first is a performance problem, the second is a data-quality problem — and neither needs the thing everyone reaches for in 2026, which is an LLM.
Here's how the pieces fit, and why the restraint matters.
Nearby search belongs in the database
The naive way to find places near a point is to pull rows into the application and compute distances in code. It works for a demo and falls over the moment you have real data — you're scanning everything and doing geometry in the wrong layer.
The right approach is to let the database do what it's built for. NearMe uses PostGIS, the spatial extension for PostgreSQL, so a "what's within this radius" query is a spatial index lookup, not a full scan. The geometry — distance, bounding, sorting by proximity — happens in the database, close to the data, using indexes designed exactly for this. The application asks a clean question and gets back an already-ordered answer.
Push work to the layer that's specialized for it. Spatial queries belong in a spatial database. Doing geometry in application code is slower, harder to scale, and reinvents what PostGIS already does well.
Crowd data is worthless without quality control
Let anyone report a price and you'll get good data, honest mistakes, and the occasional absurd entry — a typo that turns $4 into $400, or a deliberate bad submission. If those flow straight into what other users see, trust evaporates. But manually moderating every entry doesn't scale.
The answer is automated, statistical: a detector that looks at the distribution of reported values and flags the ones that don't belong. A price wildly out of line with everything else reported for the same thing is almost certainly wrong, and the math can say so without a human in the loop. Good data passes silently; outliers get caught.
Build it domain-agnostic
The detail that makes this reusable: the outlier detector doesn't know it's looking at prices. It operates on values and their distribution, not on "dollars." That means the same component that keeps price data clean today works unchanged for any other crowd-sourced metric tomorrow — ratings, wait times, quantities. Generic where it can be, specific only where it must be.
A modular core that grows without rework
The payoff of these choices is a platform where new capability drops in cleanly. Adding a new category of place doesn't touch the search internals. Adding a new kind of reported data reuses the same outlier detection. The Android client caches results locally for responsiveness, and an error pipeline keeps failures observable rather than silent. Each part has one job and a clean seam to the next.
There's no LLM in NearMe, and adding one wouldn't make it better. Geo-search is a solved database problem; data quality is a statistics problem. Reaching for a language model here would add cost, latency, and unpredictability to solve problems that exact, cheap methods already solve well.
Why restraint is an engineering skill
It's tempting, right now, to put an LLM in everything. But the mark of good engineering is matching the tool to the problem — and sometimes that means choosing the boring, exact, fast solution over the fashionable one. NearMe is fast because the database does the spatial work, trustworthy because statistics filter the noise, and extensible because every part is generic where it should be. None of that needed a model. Knowing when not to use the new hammer is as valuable as knowing how to use it.
The systems that hold up over time are the ones where each decision was made on the merits — the right tool, in the right layer, for the actual constraint.
Have a system like this to build?
This is the kind of work I take on. Tell me what you're building or rescuing.