Work

MutuallyMe · Hobby Startup · 2016 – 2018

Shipping a Hobby Startup — and Knowing When to Walk Away

Three of us — engineering, product, design — built and shipped a contact-sync app after our kids went to bed. We were right about the problem and wrong about the channel.

Two years later, Apple shipped a version of it in iOS 13. The lesson wasn't about the idea. It was about where solutions belong.

Role
Co-founder · UX, Frontend & Strategy
Team
Arsen Ghulyan (Eng) · Jay Shelley (Product) · Britton Stanfill (Design)
Outcome
Shipped iOS + Android · ~100 users · Killed deliberately

The Moment Contact Info Is Shared, It's Already Fragile

A phone number, an email, a physical address — once it lives in someone else's contact app, every later change creates a small fracture. Multiply by every device that holds your card, and you have a quiet, persistent problem that nobody has the time to fix in any one moment.

Three of us thought we could fix that. We met after the kids were down, ideated in living rooms, and built a product that let you update your contact card once and propagate it to everyone you'd shared it with.

xkcd comic 'Phone Numbers': one person rattles off five different phone numbers and a tangle of rules for which forwards to which and when to use each. The caption reads, 'Another reason I never call people.'
The fragmentation tax, as only xkcd can draw it.
“Phone Numbers” · Randall Munroe, xkcd · CC BY-NC 2.5

The problem was real

Highly connected people — executives, politicians, investors — had tens of thousands of contacts and no system that worked across them.

The trust bar was high

People are protective of their contacts. Plaxo had burned the well a decade earlier by spamming users' networks to grow.

The network effect was brutal

Value scaled with the number of your contacts using the app. Without enough early adopters, no individual user saw enough lift to recommend it.

A dark vision slide titled 'Better Together — Accurate contacts make thousands of apps better,' showing a grid of iOS app icons that all depend on contact data: Phone, Mail, Maps, Safari, Venmo, Notes, Photos, Calendar, Contacts, FaceTime, Google Maps, Apple Pay, Camera, Messages, PayPal, and Google Duo.
But the upside was just as real. Accurate contacts aren't one app's feature — they're infrastructure that makes thousands of apps better. That was the bet. An early vision slide.

Discovery

We started where the pain was sharpest — people whose jobs are contacts.

We ran competitive research across every product we could find with any overlap in the space, and did contextual inquiries with highly connected people: politicians, investors, executives, and the assistants who keep their lives running.

Key findings

Executive Assistants do this work, badly, by hand

EAs were inputting hundreds of business cards into Outlook or Google Contacts every few months — often via OCR scanners that weren't 100% accurate. A wrong digit meant a missed window.

"Who touched this contact last" was the metadata that mattered most

With contacts spanning email, calls, Slack, text, and in-person meetings, the most valuable piece of metadata for a team wasn't the contact — it was knowing who reached out most recently.

Executives won't mix personal and professional

They want to use their personal phone for business communication, but they don't want the two contact lists to merge. A unified address book is a non-starter.

Sales reps walk out the door with customer data

Smaller-business reps were building customer information into their personal phones. When they left, the contacts went with them. That's a business risk hiding inside a UX problem.

The signal we missed

Users in our interviews found value in our app. But organically, almost nobody was searching for a solution to this problem. We had product–pain fit without product–channel fit, and a network-effect product can't survive that gap.

Ideation

We followed a "Design Studio" / "Crazy 8s" format and put a disproportionate amount of our energy into onboarding.

If onboarding wasn't dead simple, we'd never get a network started. And our discovery had taught us that trust was the gating concern — people in our problem space had been burned before. The product had to look serious from the first screen.

Most of our ideation rotated around two questions: how to get a stranger from "downloaded" to "first contact synced" in under a minute, and how to visibly demonstrate that we weren't going to do what Plaxo did.

Information Architecture & Hi-Fidelity

I created wireframes and designed user flows to cover every entry point, every state, every feedback message — and more importantly, to make sure the design actually helped users reach their goals. As a three-person team with relatively high opportunity cost on every hour, we carefully prioritized what would have the most impact.

LAUNCH ONBOARDING VERIFY SYNC REVIEW UPDATES PROFILE EDIT PROFILE BRANCH Splash Stay Connected You're In Control Secure Phone number SMS code Verified Syncing Update queue Approve or skip Your card per-contact loop Edit fields Photo sheet Camera / library Crop & save 20 SCREENS MAPPED Every entry point, every state, every feedback message — shipped on iOS and Android Multiple profiles: never reached — left for platforms with big networks Apple shipped similar contact sharing in iOS 13, years later
20
Screens mapped Every entry point, every state, every feedback message — shipped on iOS and Android.
Launch
Splash
Onboarding
Stay Connected
You're In Control
Secure
Verify
Phone number
SMS code
Verified
Sync
Syncing
Review updates
Update queue
Approve or skip

per-contact loop

Multiple profiles: never reached — left for platforms with big existing networks

Profile
Your card
↳ Edit profile branch
Edit fields
Photo sheet
Camera / library
Crop & save

Apple shipped similar contact sharing in iOS 13, years later

The end-to-end flow, recreated from the original 20-screen flow map: onboarding, phone verification, contact sync, the per-contact update review loop, and the profile editing branch with its photo sub-flow.

View the original 20-screen flow map PDF

The screens

The flow above is the map; these are the destination — the same onboarding, audience-aware profile, and sync moments, rendered at fidelity.

Three hi-fidelity MutuallyMe screens over the brand's mint network pattern: a 'Let's Get Started' phone-number entry with a numeric keypad; a contact card for Britton Stanfill, Senior Product Designer, with Personal and Professional tabs, phone, location, email, website and LinkedIn plus an edit button; and a 'Syncing — your contacts are syncing, 8 updates downloading' screen.
Sub-minute onboarding, an audience-aware contact card that shows different information to different people (personal vs. professional), and live contact sync.

Usability Testing

Once we had a working prototype on both stores, we tested fast and iterated faster.

My product partner and I observed users in person, recorded sessions for review, and reached out to our installed base using Intercom for follow-up feedback. We found everything from small copy tweaks (giving users a way to explicitly skip updating specific contacts) to deeper structural changes (automatic number formatting; tools to surface and remove duplicates).

Key findings

Security wasn't a feature — it was the foundation

People felt passionately about keeping their contact information secure. Trust had to be communicated visually, in copy, and in actual behavior — not just claimed.

Onboarding had to be the keystone

Initial value was narrow by definition — your contacts haven't joined yet. Any onboarding friction would compound an already-uncertain decision and tip users away.

Audience-aware contact profiles resonated

The idea of sharing different contact info with different people — a "work" profile, a "personal" profile, a "high-trust" profile — landed instantly with the people we talked to.

The network-effect math worked against us

Value to a user was directly proportional to the number of their contacts already on the app. Early adopters bore the cost of low value to unlock future value — and they could feel it.

Development

I contributed a meaningful chunk of the frontend — primarily styles and markup for our PhoneGap app — and designed and developed the marketing site we needed in order to get our apps approved on the stores. I don't write production code every day, but I'm comfortable picking it up when a project needs it. (Earlier in my career I was a casual member of the CSS working draft group.)

The most valuable engineering lesson from a "failed" project was learning what app stores actually require — terms & conditions, a real marketing site, working privacy policies, edge-case handling for review. None of that is in any design course.

What Got Built

iOS + Android

Shipped to both app stores using a shared PhoneGap codebase

~100

Real users onboarded — enough to validate the product and the ceiling

YC App

Applied to Y-Combinator. Didn't get in (typical for first-time applicants). Kept building.

Why We Stopped

We ultimately walked away because we became convinced that the natural home for "fix your contact card across everyone who has it" wasn't a third-party app. It was either inside LinkedIn — where a strong network already existed — or inside the OS itself.

Two years later, Apple proved that read. iOS 13 added the ability to push updates to your name and photo to other iOS users with your contact info built right into iMessage. Same problem. Solved at the right layer.

The principle

The right idea in the wrong place can't win, even with good execution. Network-effect products belong where the network already is. Recognizing that quickly — and walking away — is a separate skill from building well.

What I Took With Me

We didn't build a beautifully architected, scalable codebase — and we didn't try to. The point was to learn fast, iterate fast, and find out whether the problem was real and whether the channel could carry it.

What I carried into every product role since: how a three-person team actually distributes work, what genuine end-to-end ownership feels like (research, design, frontend, copy, ops), what app-store reality looks like from the inside, and — maybe most usefully — how to read the data and stop when the data says stop.

Plus the small, durable pleasure of having been right about a thing two years before Apple was.

Let's build the right thing

I'm exploring roles where range — design, research, and shipping — matters more than a single discipline.