HopUp

An app for spontaneous meetups works against a narrow window of time. Someone deciding to meet up tonight decides it within minutes, not days. The familiar sequence of proposing a date, collecting replies and confirming it does not apply. The app has to show what is true right now instead.

That places an unusual demand on the interface. The path from opening the app to being listed has to be short enough to finish while walking. In HopUp that means: open the app, pick a place, done. Every extra step here is expensive, because it sits exactly at the moment where the decision to use the app is made.

The second difficulty is mutual. An application of this kind is only useful when several people use it at the same time. Map and feed therefore have to show something understandable even when little is happening, and they have to react without delay when something changes. Open a map once and see stale entries, and the information loses its credibility for good.

HopUp is built as a React Native app with Expo, so iOS and Android run from one shared codebase. For a product whose value depends on how many people take part, that is the obvious call: both platforms have to be served from day one, otherwise an invitation fails on the recipient's choice of phone.

Supabase sits behind it, and geospatial queries run through PostGIS. Location is not an add-on in this kind of app, it is the actual computation: which check-ins are nearby, within what radius, in what order. Queries like that belong where they can be answered efficiently, not on the handset.

Real-time updates and push notifications complete the picture. Both serve the same property: the app should reflect the current state without anyone having to keep opening it. Both also have to stay measured, because an app that notifies too often gets muted, and after that the best live state is worth nothing. Google Sign-In lowers the barrier on first launch, which matters for an app that is often opened for the first time in a casual moment.

Publishing an app in two stores means dealing with two review processes, two sets of rules and two release rhythms. If every version is built and uploaded by hand, shipping becomes the bottleneck and fixes arrive late. HopUp therefore automates its store releases with Fastlane. The gain is reliability rather than convenience: the route from a finished change to a published version is always the same one.

The second point concerns location data. Where people share where they currently are, the question of who sees what is not a setting at the edge of the app, it is part of the product. It belongs in the early drafts, not in a later update.

As an in-house product, HopUp never reaches the handover point a client project has. Design, development and operation sit with the same team, decisions stay open to revision, and what shows up in daily use feeds back into the next version. That loop between running a product and building it is the real value of having one.