Over the past month, I’ve been building CompanionSquared.com. It is meant to be a tool that helps me maintain, deepen, and broaden my friendships, and was supposed to be a personal self-hosted project that I used for myself.
Then, a bunch of friends started saying “that’s something I might use too - let me know once you build it, would love to try it out”. And there I went down the rabbit hole.
I’ve spent the month iterating, talking to people around me, deeply reflecting about whether I’m bringing an overkill level of effort to friendships (while there is external indications of interest, I can also imagine an equal or greater level of shock, disgust, or discomfort). My gut feel continues to be “no”, and I feel that it’s worthwhile to deconstruct why I feel this way.
Teasing Out a Friendship Operating System (friendshipOS)
Key Components of a friendshipOS
At the heart of any friendshipOS, is 3 core components:
- A space to input information (to me, a suitable input is reflections in prose form)
- A way to review the inputs (in this case, how the reflection has been parsed by an LLM)
- Individual friend pages that house the parsed data
The actual parsing process is a technical question more than a philosophical question, and will be informed by what ultimately gets parsed and stored anyway. So it’s more important to interrogate that latter bit.
It is my strongly held belief that journaling about ones’ friendships is the core of being able to be a better friend and beyond. Honestly, journaling as a whole is incredibly beneficial, and this belief has spawned a whole host of journaling apps.
I’m proposing that taking care of your interpersonal relationships and reflecting on your interactions with others (and how you provide mutual support to one another) would contribute massively to your own wellbeing, and that this is a factor that is absent from a lot of existing products right now.
(also, I didn’t abbreviate it to friendOS because that is a thing that exists)
Parsed Data (or “What Is a Friend”)
…maybe the question should be “what is a person” - are we just a set of attributes, experiences, dates, places, desires, views, and contact information?
What Exists Right Now?
The closest reference I could get is Facebook, both current and present.
There are main things that FB has allowed people to display:
- Occupation
- Educational history
- Where they live and where they’re from
- Significant other and family members
- Life events
- Other contact/social details
On top of that, you can post things that may appear on other friends’ news feeds.
This general setup of having all this information, a stream of thoughts, and a social graph has enabled companies like Meta to build advertising products (which is the cynical way to look at it) as well as ways to have people stay connected and exchange information with one another (which on the surface is less cynical, until you realise that this approach left unchecked resulted in a bunch of atrocities). To me, this presented an opportunity to build a tool that enhances your ability to take ownership to maintain and nurture your own social network in real life (or through deliberate online correspondence, which to be fair would still involve companies like Meta).
What’s My Approach?
The balance to consider when building what could sorta be boiled down to “a CRM but for friends” (which feels quite gross to say to be honest, but work with me here) is what is important to include as things-that-one-may-want-to-remember-about-people-around-them, while also minimizing the “ick” or creepy feeling that you’re storing a whole bunch of sensitive information about people around you (which is the biggest reason why friends either love or hate that I’m doing this at all).
I hope where I’ve landed strikes a good balance - with the caveat that there is no compulsion to collecting every single last bit of information about everyone - the breadth of attributes to be collected is there to fit as broad a use-case to help people with one of two things:
- Deepen their existing friendships
- Broaden the range of people they can interact with on a meaningful level
(after all, the product is called CompanionSquared or C^2 because we’re trying to help folks exponentially strengthen/broaden friendships)
These are the things I’ve chosen to extract:
- Profile Overview
- Friend Summary: An overarching summary that provides insight into the friend’s love languages (how they prefer to give and receive affection), attachment style (how they approach and resolve disagreements), communication style (how they prefer to connect and share things), and energy type (introversion/extroversion + social battery, optimal times) [V2 FUTURE FEATURE]
- Key Details: How we met, where they are, phone number, personal email, and work email
- Socials: Any social media/web presence they have (the fields are customizable!)
- Notes: Personal observations, free-form thoughts, and a space for current reminders
- Energy & Dynamics
- Roses: Aspects about the friend that energizes you
- Thorns: Aspects about the friend that drain your energy
- Relationships & Care
- Loved Ones & Pets: Taking note of people (and pets) that matter to the friend, as well as major facts about them (e.g. in primary school, likes to collect garbage trucks etc.)
- Mutual Support: Specific ways each of you are supporting each other (e.g. emotional support, professional network, parenting advice, career guidance)
- Special Care Instructions: Longer-form “instructions” for ways to give special care to the person (e.g. if they have severe allergies, dietary restrictions, mental health needs, defined ways that they gain comfort)
- Important Dates: Significant anniversaries, birthdays, milestones (split into recurring and milestones)
- Goals & Projects
- Personal Goals: Goals to improve personal wellbeing
- Professional Goals: Goals to enhance career outcomes
- Projects: Specific things that the person is working on - either alone, or with other people in your web of friends (or with you!)
- Interests & Preferences
- Activities They Love: Things the friend likes doing, and some details on the activity
- Activities They Avoid: Things that the friend does not like (because they’ve tried it, or they have a good sense that they won’t like it. Like diving if they’re deathly afraid of drowning)
- Gift Preferences: Things the friend would like - either because they have said so, or because of the sense you have based on what you know about them
- Circles & Communities: Groups that are defined by activities/beliefs/philosophies/careers/life stages that your friend actively identifies with, or is active within.
- Memories & Gratitude
- Memorable Moments: Special shared experiences and specific things-that-have-happened that you may want to recollect one day
- Things I’m Grateful For: Gratitude statements that came up (May overlap with mutual support or memorable moments, and that’s ok)
- Shared Things: Media, locations, activities, people to meet etc. that are recommended by the friend
- Past Events: Events that said friend has attended in the past that you may have attended/organized [V2 FUTURE FEATURE]
(yes, I recognize that this is a LOT of information to compile on someone. yes, this is what I’m personally paying attention to when I interact with people. no, I don’t have every bit of these on every single person I meet)
You would notice that there are a few kinds of things we collect, and they appear in different tables)
- Key Details (in friends table): Core information tagged to the friend
- Projects (projects and project_participants tables) : Includes Title, Date Range, Description, and Collaborators (other people in your friends table)
- Circles/Communities (in circles and circle_members): Contains Title, Type of Community, Role within Community, and Description
- Loved Ones (in loved_ones)
- Socials (in friend_socials): Platform Name and URL/Handle
- Events (in events and event_participants) (FOR V2): Includes Title, Date, Description, and Participants
- Summary (in friend_summaries) (FOR V2): Single block of text that is generated to provide a “snapshot” of who the person is. Past summaries are kept.
- Activities (in friend_activities): Stores Title, Description, Tag, and Sentiment.
- All other things (in friend_items and friend_item_types): Everything else appears in a single table, because each of them has a Title, Category/Categories, and a Description (and nothing else)
- There are also friend_connections and relationship_insights tables that will find use in future features
I could have folded all these things into a single table - conventional wisdom is to ensure that DB structure is created in such a way that doesn’t dictate business logic. Maybe I’ll restructure it in the future, but as a whole, it seems like everything I would want to know about a friend has been included!
A Note On Journal Inputs and Data Extraction
Some quick (and more unstructured) thoughts about the different formats of inputs that a user will be able to provide:
- I’ve got feedback that it should be “easier” for people to provide inputs to the system, in a fashion similar to journaling apps like Finch or habit tracker apps like Habitica or Streaks. It’s a direction I may consider, but I hold a strong belief that it is important to set aside time to deeply reflect on friends, and I would rather build features to allow for different formats of long-form reflections (voice, OCR from a journal page) than to build gamified features that allow for quick inputs.
- I also feel strongly against alerts and notifications - someone subscribing to CompanionSquared in the early days should find a strong enough use-case to fold it into their daily/weekly practice, rather than having the product provide nudges. This is more likely to change in the future, but this is where I stand now.
- Both the above points point towards a clear philosophy that the user should be internally motivated to engage in long-form writing and reflecting for CompanionSquared, for
Building Applications On Top Of the friendshipOS
Everything described in the previous section is what I call “Layer 1”, because it is the foundational layer upon which other aspects of deepening or broadening friendships will be build on top of. It was important to be deliberate about Layer 1 because it would be hard to change the foundation once it is set. That, and I’m but a solo product builder, and I want this to ship right so that I can focus on building features rather than refactoring 🫠🫠
So all of these will come in beyond V2, but it’s worth giving you a sneak peek behind how I think about building on top of the friendshipOS!
(note that I’ll be using friendshipOS and CompanionSquared/C^2 interchangeably throughout the post)
Connection Cultivation: Deepening Your Relationships (via a chat interface of some sort)
Connection Cultivation is the act of deepening your friendship/relationship with another individual. I broadly consider this Layer 2 - because this layer provides you with space to
Navigating Social Dynamics, Culture, and Preferences
Coaching for Difficult Conversations
The other use-case that came to mind when asked the question of “why collect and synthesise reflections” is that I feel that we don’t have a lot of good solutions to navigating difficult conversations - either because we’re beefing with someone, or because there are complex issues happening between friends over a period of time. With enough input, it will be possible for the system to be able to
Network Nurturing: Building Strong Connections and Collectives (through building specific functionality)
Circles/Communities
People around you would generally find themselves either doing things or needing to deal with things. Not that the two are mutually exclusive, but
Projects
Events
Meaningful Introductions
The last type of utility that I believe would be great to build is an engine to help network nurturers to introduce friends to one another. There is evidence that shows that a triad is effective for deep connections to be formed, and has exponential effects if people pay it forward. There are apparently a whole bunch of benefits to triads beyond deep connections - it’s apparently good for problem solving too! However, the challenge of building a recommendation engine that suggests who could be introduced to who represents a large challenge that may not result in a large amount of usage, which is why I’ve kept it for last.
Who Could This Be Useful For
Claude was very helpful in providing me a description of different personas that can benefit from what I’m building (you can see it here). I’ll use this space to expand on each type of user
Category 1: Friendship-Focused Folks
This is something I’ve spent most of this essay expounding upon already, but it’s always useful to synthesise again!
Category 2: Managers and Mentors
Category 3: Networkers and Sales Folk
Category 4: Care Professionals
Category 5: Community Leaders
Safeguards Built (or that will be built) Into CompanionSquared
At this point, you’re either excited or extremely horrified at this little contraption that I’ve build.
If you’re a proponent of the utility that it could bring, you may have read the previous section and went “huh, it’s true that this can be beneficial to me”. In which case, I’m glad and I hope you give it a try!
On the flipside, you might find yourself thinking “and I thought people who make an excel sheet of their friends are weird - why in God’s good name would you even DO SOMETHING LIKE THIS”.
I’ll try to ease some concerns about the fundamental nature of the product, as well as some design decisions that have been made to provide a level of security to the information collected.