A beverage app where Private didn't always mean private

How it came up

The owner was building an app where people log the drinks they try, rate them, and see what others in the area are drinking, with a map, a community feed, and a personal "passport." He asked me to take a look.

I spent some time clicking through it as a new user would: signing up, browsing the map and the feed, filling in both log forms, and changing settings. It was a favor, not a code review. Sixteen things stood out. Most were small. Two were worth fixing before anything else.

Private didn't always mean private

I created two test logs, with Private selected both times. One saved as private. The other saved as public, with no error and no warning.

That means a user could mark something private and have it appear on the public map and feed without ever knowing. For an app where people share where they go and what they buy, a setting like that has to work every time. Failing quietly is worse than failing loudly, because nobody knows to check.

"Failing quietly is worse than failing loudly, because nobody knows to check."

The form's rules only lived in the browser

The log form wouldn't let me save without a drink name. But that check, and every other rule the form enforced, ran only in the browser. A request sent straight to the backend skipped all of them and was accepted.

This is one of the most common gaps in apps built quickly with AI tools. The form looks careful, so it's easy to assume the data is protected. The browser is the one part of the system the user controls, so any rule that matters has to be checked again on the server.

A broken lookup that explained a data mess

Both log forms had a field meant to suggest matching businesses as you typed, so each entry linked to the real place instead of free text. It never suggested anything. The browser console showed why: every keystroke called a mapping service that answered "permission denied," a setup problem in the service account rather than a bug in the app's code.

It also explained something else. The same business showed up in the app under four different spellings, because without working suggestions, everyone typed it their own way. One configuration fix would clean up both.

Small things that read as bigger ones

Logs nobody had rated showed a "0/10" badge, identical to a real terrible score, so a page full of unrated logs looked like a page full of bad reviews. One very long drink name with no spaces broke out of its card and pushed the whole grid sideways. Search results from the community feed couldn't be opened. A purchase date years after the "opened" date saved without complaint. And a share-to-social prompt popped up right after saving a log as private.

The rest were visual polish: a few panels with no padding, some dark text on a dark background, and a date picker icon that nearly disappeared against the theme.

What this says about AI-built apps

None of this is unusual for a new app, and the owner had built something people were already using. The two serious findings follow the same pattern as most of what I see in apps built fast: the part you can see works, and the part that has to hold up when someone doesn't use the app the expected way was never built.

A privacy setting that works most of the time and a rule the server never enforces don't show up in a demo. They show up later, usually to a user, and usually at a bad time. Finding them first is the whole point of an outside review, and this was only a short look from the outside.