Prepared by NextSky Advisors · Phase 1 (MVP)
First and most importantly: there's real product thinking in what you've put together. This isn't a set of screens for the sake of screens — you've clearly felt the problem you're solving (genuine professional connection without the cold-sales noise), and a lot of the ideas in here are differentiated and ownable. The notes below are written in that spirit: acknowledge what's strong, then sharpen the structure so the concept survives contact with a designer and a developer — and so we keep the build cash-light by deciding what not to build yet as deliberately as what we do.
Read this alongside the wireframe. The wireframe is greyscale on purpose: at this stage the job is to lock the structure and the flow before anyone spends money on colour and polish.
A few things you designed should carry straight into the build, untouched:
Most of these recur across screens rather than living on one page, so they're grouped by theme.
1. One navigation model, everywhere. You're right that a bottom bar is essential — but across the deck there are three different versions of it (a 3-icon bar, a 5-item bar with a central "+", and a different 5-item bar). In a shipped app the bar has to be identical on every screen or users never build muscle memory. The wireframe settles on one: Discover · Network · Messages · Notifications · Profile. (Worth deciding together what that central "+" was meant to do — on a discovery screen its job is ambiguous, so the wireframe drops it.)
2. The "is this a dating app?" question is structural, not cosmetic. You spotted it yourself (wanting to swap the heart and the love icon), and your instinct toward blue/trust tones is correct. The thing to know is that it's bigger than two icons: the swipe-to-reject mechanic, the X/heart buttons, the pink-magenta palette, and the "matches/chemistry" language all pull toward Tinder at once. The wireframe changes the mechanic itself — Skip / Save / Connect instead of X / heart — so the fix is at the behaviour level, not just the surface.
3. The trust system has sprawled — pick one signal. Trust currently shows up in five-plus forms: a 92% Character Score and an 89% Introduction Score, vouch counts, per-trait tallies, an impact score, a "Highly Trusted" badge, milestones, and "verified on blockchain." Two honest observations: competing scores dilute each other and start to feel like a social-credit rating (which can read as judgmental); and you only need one primary signal on the surface ("Trusted by N verified connections"), with the depth tucked into a drill-in screen. The wireframe does exactly that.
4. Blockchain — park it for v1. Gently: "verified on blockchain" adds real engineering cost and complexity for unclear user benefit, and to a professional audience it can read as gimmicky rather than reassuring. Nothing about the trust model needs it to work. Revisit later if there's a clear reason.
5. A few screens try to say everything at once. You flagged the busy profile yourself — it is. The onboarding is also a single long form, which is where users drop off. The fix is progressive disclosure: break onboarding into a few stepped screens (one decision at a time measurably lifts completion), and use the drill-in for profile depth so nothing is dumped on screen at once.
6. Three "profile" screens, one clear rule needed. There were effectively three overlapping profile pages. The wireframe splits them cleanly into: viewing someone else, my own profile (editable), and trust detail (drilled into). Same data, no overlap, no confusion about which is which.
7. One strategic fork to choose on purpose — vouch-only. Your decision to allow only positive vouches, no reviews or negative feedback, is smart for safety and keeps moderation light. The trade-off worth naming: a system where everyone looks great can be gamed, and may not actually separate the time-wasters you're targeting. A good middle ground: a vouch only counts once there's been a logged interaction or meeting — so it means something without ever introducing negativity. Worth a conversation.
Keeping the first build lean is the single biggest lever on cost. Recommended MVP, organised around one core loop — Discover → Connect → Spark/Chat → Vouch:
In scope now - Welcome / sign-in (clean wordmark, LinkedIn-led social sign-in, a one-line value prop) - Stepped onboarding (basics → interests → industries → hustle) - Discover (single canonical card; Skip / Save / Connect) - Profile view (one trust signal on the surface) - Connect → Spark chat (journey timeline, coffee-invite, conversation starters, in-context vouch) - Network, Messages, Notifications (tabbed), My Profile (editable), Trust detail, Settings - Freemium hook: proximity free, moveable location premium
Parked for later (good ideas, not MVP-critical) - Warm introductions (Phase 2 — high priority, the standout differentiator) - AI matching (needs user volume before it works; rules-based matching on shared interests/industry/proximity is enough to start, and far cheaper) - Mentor discovery, profile-view tracking, milestones/gamification, blockchain verification
This is a strong foundation. The work from here is mostly subtraction and sequencing — which is exactly the cheap, high-leverage stage to be in.
— NextSky Advisors