One App, Two Sides: Structuring Sphere of Six's MVP Around Trust

The founders brought me in before there was a single screen, just a whiteboard and a trust problem with two sides: people ask their network before they open a directory, and service providers were burned out from resold leads pitting them against each other for the same job. I joined to turn “digitize word of mouth” into a product both sides would actually use.

For people looking for a service provider, the real behavior is to ask someone they trust first, an electrician a friend already uses, a cleaner a family member recommends. Review sites only enter the picture once that network is exhausted, and ratings there are anonymous and sometimes fake.

For service providers, the problem was just as concrete, and it came from inside the founding team. One partner is a service provider himself, and his best clients had always come through referrals, never paid leads. The lead-generation platforms he'd paid into resold the same lead to multiple providers at once, so a homeowner got bombarded with competing messages, and providers got no organic growth out of it.

My starting hypothesis was that people wanted fast, digital access to trusted referrals, with a way to contact a provider and book directly inside the app. Research confirmed the trust behavior on both sides, but it overturned my assumption about which journey mattered first for the MVP. The critical path wasn't contacting a new provider, it was bringing in the providers someone already trusted. Without that, there was no sphere to grow, and the whole value proposition collapsed. That reprioritization reshaped everything that came after.

I also pushed the team away from the original plan of two separate apps, one for consumers and one for providers, toward a single app with two account types. A consumer and a provider are often the same person, a homeowner today, someone's cleaner tomorrow, and a unified app made that overlap trivial instead of requiring account linking across two products. We took it further during build: every user creates a consumer account first and can add a provider account inside it afterward, rather than choosing a type upfront.

Two dedicated apps would have let each experience be purpose-built without compromise on either side. Unifying them meant giving that specificity up. What we got back was time to market and lower build cost, the right trade for a small team building from zero and racing to prove the sphere concept, not necessarily the right call at every stage after this one.

The same logic drove the MVP cut. Once we validated an early prototype with real users, it was clear the entire post-connection experience, contacting a provider, evaluating them, everything after the match, wasn't essential for proving core value. That single insight cut roughly half of the planned feature set. In-app messaging, reviews, and post-service flows moved to later versions and currently run manually outside the app while we watch for demand signals.

Before

Inviting someone new to the app takes about 8 screens and roughly 20 taps in the current release.

After

Prototyped down to 3 screens and 6 to 8 taps. Not yet shipped, but ready to replace the current flow.

Because we validated heavily before shipping, launch had few last-minute changes, mostly icon tweaks, input field adjustments, and label copy. Both app stores approved the submission on the first try. I also designed and shipped the company website solo, alongside the app.

The design process itself compressed hard. Using AI to jump straight to high-fidelity, clickable prototypes instead of static wireframes, I took the process for the first MVP version from a typical ~10-week hypothesis-validation cycle down to 4 weeks. For a founding team funding development out of pocket, six fewer weeks of design time is six fewer weeks of runway spent before revenue.

I should have pushed harder to get the founders comfortable validating ideas with outside users earlier. They were hesitant to expose the raw concept beyond the founding four, understandably protective of it, but that hesitation cost time. I ended up designing tools and features that later testing showed weren't essential for the MVP, useful for the roadmap eventually, but a less efficient use of early design hours than it could have been.

I also argued for launching as a web app first instead of going straight to native iOS and Android, on the logic that we could prove demand with fewer resources, then invest in native once we had real signal. The founders opted for native from day one. In hindsight, I still believe web-first would have gotten us to market faster and cheaper, though I understand their reasoning for wanting the native experience locked in from the start.