Executive Summary & Quick Answers
Key Takeaway: We built a Flutter SDK that lets nearby phones exchange identity tokens over inaudible sound, and a networking app on top of it. Two people at an event open the app and their professional cards are exchanged, with no QR code to scan and nothing to type. Because the SDK was built separately, with its own example app, other Flutter apps can embed the same exchange.
- Client Profile: A startup building contactless profile exchange for professionals at networking events, hiring fairs and meetups.
- Problem: Swapping details in person still meant typing names, scanning QR codes or searching for someone later. The startup wanted the exchange to happen just because two people were near each other, while keeping each person’s identity under their control.
- Solution: A Flutter SDK that encodes each device’s token in ultrasonic signals and detects the tokens of nearby devices, plus a cross-platform app with LinkedIn and Apple sign-in, professional cards, local token storage and real-time events over Socket.IO.
- Result: The SDK and the app were delivered, and the SDK was released with a documented example app as a reference for other Flutter developers.
The Challenge & Business Context
At an event, the moment to exchange details is short. Typing a name into a search box or lining up a camera with a QR code is slow and awkward, and it often does not happen at all. The startup’s idea was to make the exchange ambient: if two people both have the app open and stand near each other, their profiles are swapped.
That idea needed a way for phones to find each other that works on both iOS and Android, without pairing, and a privacy model where a person’s identity is never broadcast openly.
What the build had to solve:
- A transport that needs no pairing: The exchange had to work between two phones that have never met, quickly, with nothing to tap or scan.
- Identity that stays under the user’s control: What travels between phones must not be the profile itself, and a person must only share their token while they choose to.
- Live awareness of exchanges: When someone nearby shares their token, the app has to know straight away, even while the user is not looking at the screen.
- Reuse beyond one app: The sound-based exchange was the startup’s core technology, so it had to be packaged for other Flutter apps, not buried inside one codebase.
Solution & Technical Architecture Strategy
The design separates the transport from the product. The SDK knows how to send and hear tokens; the app knows about people, profiles and sign-in. Each decision below follows from keeping that line clean.
Decision 1: Build the sound transport as its own SDK
- The default: Write the audio code inside the app and extract it later if anyone else needs it.
- Why it fails here: The sound-based exchange is the startup’s product, not one feature of one app. Code that grows inside an app picks up app assumptions and is hard to lift out.
- What we did: We built the transport as a separate, modular Flutter SDK. Devices emit and detect encoded ultrasonic signals that carry each user’s token, and the SDK caches the device’s current token and metadata in local storage.
- What it bought: The main app is the SDK’s first consumer rather than its owner, and other Flutter apps can embed the same exchange.
Decision 2: Send a token over sound, never the profile
- The default: Put the person’s details, or a link to them, into the signal.
- Why it fails here: Anything sent over sound can be heard by any device nearby. Broadcasting profile data would expose it to everyone in the room.
- What we did: Each device generates its own unique token, stored locally and shared only during an active session. The sound carries the token; the app then shows the matching professional card.
- What it bought: The token is sent only during an active session, and profile data is not included in the sound signal.
Decision 3: Real-time events over Socket.IO
- The default: Poll the server for new exchanges.
- Why it fails here: An exchange at an event is a moment. A polling interval long enough to save battery is too slow to feel instant.
- What we did: The app keeps a Socket.IO connection and listens for token changes and sharing events in the background.
- What it bought: Exchanges appear as they happen, without the app repeatedly asking the server.
Decision 4: Fast resume and familiar sign-in
The token and user preferences are stored locally, so the app can resume quickly and keep broadcasting its identity without a round trip first. Users sign in with LinkedIn (OAuth in a web view) or with Apple, and can import their LinkedIn details or write their own card. Provider and GetIt manage state and services, and Dio interceptors with a logger keep every API request tracked and debuggable.
Tech Stack Matrix
| Category | Technology Chosen | Rationale & Advantage |
|---|---|---|
| Frontend UI | Flutter | One codebase for iOS and Android, matching the SDK’s language |
| Proximity Transport | Custom Flutter SDK, ultrasonic signalling | Pairing-free exchange between nearby phones, reusable by other apps |
| Real-Time Events | Socket.IO | Token changes and sharing events delivered as they happen |
| Networking | Dio with interceptors + logger | Consistent API calls with request tracking and in-app debugging |
| State & Services | Provider + GetIt | Scalable state management and service location |
| Authentication | LinkedIn OAuth (web view), Sign in with Apple | Sign-in with the identity people already use for work, plus Apple on iOS |
| Local Storage | Secure local storage | Device token, metadata and preferences for fast resume |
Architectural Flowchart
Figure 1: The SDK owns the transport: it encodes this device’s token into an inaudible signal and detects the tokens of nearby devices, caching the token locally. The app owns people and profiles: sign-in, professional cards, the Socket.IO connection for live exchange events and API calls through Dio. The example app uses the same SDK, which shows other developers how to embed it.
What We Built
- The sound-based SDK: A modular, lightweight Flutter SDK that emits and detects encoded ultrasonic signals carrying identity tokens, caches the device’s token and metadata locally, and listens for nearby users ready to exchange.
- Proximity profile exchange: Users near each other exchange professional profiles with no QR code, no scanning and no typing.
- Token-based privacy: Every device generates its own token, stored locally and shared only during active sessions.
- Sign-in and professional cards: LinkedIn sign-in (OAuth in a web view) and Sign in with Apple, with a professional card users can fill in themselves or import from LinkedIn.
- Real-time token events: A Socket.IO connection keeps the app aware of token changes and sharing events in the background.
- A documented example app: A complete reference app released with the SDK, showing other Flutter developers how to integrate it.
Frequently Asked Questions
How can two phones exchange data using sound?
One phone plays a short signal above the range people hear, with data encoded in it, and nearby phones listen through their microphones and decode it. In this build the signal carries a token rather than personal data, and the app uses that token to show the sender’s professional card.
Is it safe to exchange identities over sound?
It can be, if what travels is not the identity itself. Here each device generates its own token, stores it locally and shares it only during an active session, so profile details are not included in the sound signal.
Why build an SDK instead of putting the feature inside the app?
Because the exchange was the startup’s core technology. As a separate SDK it has one clear job, the main app uses it like any other customer would, and the example app documents how another Flutter app can embed it.
Can this work on both iOS and Android?
Yes. The SDK and the app are written in Flutter, so both platforms share the same exchange logic, with Sign in with Apple added for iOS users alongside LinkedIn sign-in.