Almost: FlutterFlow travel connections app

An airport is full of interesting people with two hours to kill and no reason to talk to any of them. Almost was built to change that.

You set your airport and the window you are free, and the app matches you with others whose time and place overlap, for dating, friendship, or business. The brief was a complete cross-platform product with a genuinely premium feel, safety controls built into the core, and a mutual-consent model so a connection only opens when both people choose it. This was never going to be another dating grid, and it could not look like one.

Travel throws the right people into the same place at the same time and gives them no way to meet. The information needed to fix that, who is around, when, and what they are open to, exists, but no product resolves it into a safe introduction.

That safety piece is the hard part. A product that introduces strangers has to earn trust before anything else, so consent and safety could not be settings bolted on at the end. They had to be the mechanic. And it all had to feel premium and travel-native, not borrowed from a dating app.

Aumadi delivered the full build, from UX and UI design through to the iOS and Android apps and the web admin console.

Design mattered as much as engineering on this one. We designed the product end to end around a premium aviation aesthetic, calm and considered, so it felt native to travel rather than borrowed from a dating app. FlutterFlow then carried that design to both stores from a single codebase, with Supabase behind it for data and auth, and the premium tier wired through the app stores.

The product logic sits on three ideas. Matching works on time, location, and intent together, so you only ever see people actually around during your window. A chat request opens only on mutual acceptance, which makes consent the mechanic rather than a setting. And safety tools were part of the build from the start, because a product that introduces strangers has to earn trust before anything else.

Discovery and planning. We scoped the matching logic and the safety model as the core of the work, not add-ons. The key questions were how time, location, and intent would resolve into a good match, and how consent and safety would run through every interaction in the app.

Design. This is where a lot of the product was won. The interface had to feel premium and travel-native, and the journey from setting a travel window to requesting a chat had to feel effortless. We designed the full UI and prototyped the core flow before a line of the build began.

Development. FlutterFlow carried the apps across iOS and Android on a Supabase backend. Core features:

• Travel window setup by airport, date, and connection intent
• An overlap matching engine on time, location, and intent together
• A mutual-consent chat flow that opens only when both sides agree
• Safety controls built into the core
• A premium tier running through the app stores

The web admin console was built in parallel for oversight and moderation.

Testing. We tested what the product depends on: travel windows being set cleanly, matches landing correctly on overlap, and the consent gate opening a chat only when both sides agreed.

Launch. Almost shipped to the App Store and Google Play at the same time, with the full feature set live.

The outcome. Almost is live on both stores. The matching engine, the consent model, and the safety layer all run together, on a product that looks and feels like it belongs in the world of travel.

Most connections happen by chance. Almost just gives chance a little help.