skip to content

shotgun devlog 002: walmart vs walmrt

August 20, 2026 · 2 min read

spent today actually building instead of just talking about it, and a lot landed: sign-in, posting a trip, the feed, clustering, joining, dark mode. more on some of that later, but the thing i want to write about is smaller and kept bugging me the whole day.

destinations in this app have to match exactly, because the entire point is grouping people going to the same place. and the second i started actually posting test trips i realized how often the same place gets typed two different ways. someone posts "walmart," someone else posts "walmrt" because they were typing fast on their phone, and now there are two destinations in the database that are obviously the same store and the app has no idea.

i asked about doing fuzzy matching, or maybe running it through some ai model in the background. what we landed on instead is simpler and doesn't need an api call.

postgres has a trigram extension, and you can score how similar two strings are without either of them being spelled right. "walmrt" and "wal-mart" both land close enough to "walmart" that the app just treats them as the same place.

the annoying part turned out to be real place names, not typos. "aldi" vs "aldi (libertyville)" scores badly with plain string similarity, because of that parenthetical qualifier, even though they're obviously the same store to a human.

switching to something called word similarity instead of whole-string similarity fixed it. it scores against the best-matching chunk of the name rather than the whole thing, so the qualifier stops mattering.

there's also a real difference between "close enough, just use it" and "close enough to suggest, but let a human confirm." if someone types "amc," that's going to score perfectly against every amc theater in the database, so auto-matching would just pick one at random, which is worse than asking. so there's a gap i check for — if the top match isn't clearly ahead of the next one, it shows as a suggestion instead of getting picked automatically.

destinations are a table in the database rather than some fixed list, on purpose — the whole set of places has to be able to grow without me redeploying the app every time someone wants to add a new grocery store. the fuzzy matching is really just there to keep that table from filling up with duplicates of the same five places.

still feels a little fragile, mostly because it's tuned by eyeballing which scores look right rather than anything more rigorous. but it caught every typo i threw at it today, so it's staying in for now.

...

Comments (0)

Chris Zimbizi