A relationship intelligence app that surfaces who to contact next

Contact lists are good at remembering who someone is. They are much less useful at helping someone maintain the relationship. As a network grows, the valuable question is no longer 'do I have this person's number?' It is 'who should I reach out to next, what happened the last time we spoke, and what should I remember before I do?'

The information needed to answer that question is naturally fragmented: contacts, communication activity, calendar events, follow-ups, notes, relationship context, and the user's own memory.

The product had to bring those signals together without asking users to maintain a heavyweight CRM. Mobile was central because relationship context is most valuable immediately before and after an interaction, not later at a desktop.

A relationship-centered domain model connects each person with contact details, relationship context, events, activities, scheduled follow-ups, and priority. Rather than treating those as separate productivity features, they form one picture of the relationship.

A suggestion service exposes contacts the system believes are worth surfacing based on interaction signals. The recommendation capability lives behind an API so the mobile experience can evolve independently from how suggestions are calculated, and users can act on or ignore those suggestions.

The cross-platform mobile application brings that layer to both Android and iOS, integrating with the device capabilities that make relationship management useful in practice: contacts, calendar, secure local storage, deep links, scanning, communication actions, and other native surfaces.

A focused AI service reduces the friction of capturing new context. Voice can be transcribed and then converted into schema-constrained structured data, so a quick spoken update can become usable relationship information rather than another transcript somebody has to organize later.

I lead the architecture across the relationship model, contact-suggestion experience, API boundary, mobile client, and supporting AI services. The central product decision is also the simplest way to explain the platform: it should help answer who you should contact next, not simply give you another place to store contacts.

1. Make contact prioritization a first-class product capability

   Why

   A searchable address book already exists on every phone. The product becomes valuable when it helps decide where attention should go next.

   Trade-off

   Interaction signals are imperfect. Suggestions have to be dismissible and the system must improve without pretending every recommendation is objectively correct.

2. Keep recommendation logic behind a service boundary

   Why

   Suggestion quality can evolve over time. Keeping that capability outside the UI lets the product change the inputs and ranking logic without rebuilding the mobile experience around a particular algorithm.

   Trade-off

   The recommendation experience now depends on a backend capability and on responsible handling of interaction data.

3. Capture structured relationship context, not only free-form notes

   Why

   Useful relationship intelligence depends on information the system can reason about later. Structured fields make future search, prioritization, follow-up, and automation possible.

   Trade-off

   Structure introduces schema design and validation work, and not every human interaction fits neatly into predefined fields.

4. Use voice as a low-friction capture path

   Why

   The best time to record context is often immediately after an interaction. Speaking a short update is faster than navigating and completing a form, while schema-constrained extraction can still produce structured data.

   Trade-off

   Speech introduces transcription quality, privacy, network, and external-service considerations.

The product changes the core interaction from searching a contact list to acting on a relationship queue. Users can see who is worth reconnecting with, keep follow-up context close to the person, and capture new information with much less friction. The architecture also leaves room to improve recommendation quality over time without rebuilding the mobile application around each new approach.

The public version omits recommendation and scoring details, communication-provider integrations, relationship data structures, private APIs, and organization-specific product information.

• Flutter
• Dart
• FastAPI
• Python
• Azure AI Speech
• OpenAI
• LangChain
• Pydantic