Map the real workflow
Identify the messy handoffs in a normal group chat: suggestion, reaction, availability, venue, confirmation, and follow-through.
Case study · Native iOS planning app
Lets turns plans into certainty.
A group-planning product built around a simple behavioral truth: people do not want another coordination thread. They want a plan that feels easy to create, easy to share, and safe to say yes to.
STATUSLive on TestFlight · in beta
ROLEProduct, UX, data model, and app build
STACKSwiftUI · Supabase · Auth · MapKit
9:41Lets
🍜
Ramen + arcade
Friday night · Downtown · 6 friends invited
KMJA+2
PICK A TIME
Fri 6:302
Fri 8:005
Sat 9:001
VENUE SIGNAL
Ramen House4
Lock the plan →
Problem
Group planning dies in the gap between interest and commitment.
Most friend plans do not fail because people dislike each other. They fail because every decision becomes a tiny negotiation: who is in, when works, where to go, whether the plan is real, and who is responsible for moving it forward.
Lets treats that coordination mess as the product surface. The goal is not to replace friendship with software. The goal is to remove the parts of planning that create drag, ambiguity, and quiet drop-off.
PRODUCT LOOP
One job per moment.
The core loop is intentionally narrow: create a plan, invite people, collect signal, lock the decision, and give everyone a shareable source of truth.
01
Create
Start with an activity, loose time window, and optional venue. The creator should not need a perfect plan to start.
02
Invite
Share a code or deep link that works before every friend has an account. Distribution matters more than purity.
03
Vote
Friends give quick signal on time and venue. The interface makes the leading option obvious without making it feel forced.
04
Lock
Once there is enough signal, the plan becomes a single card everyone can trust, save, and reference.
Process
Built with the same operating discipline as my BA work.
Define the acceptance bar
A plan is not successful when it is created. It is successful when invited people understand what to do next.
Make the loop tangible
Build the smallest native surface that can test the plan-card, voting, and share-code behavior without extra ceremony.
Current Build
- SwiftUI app shell with plan creation, plan detail, and voting surfaces.
- Supabase-backed direction for auth, plans, invite codes, RSVPs, and votes.
- Share-code model for inviting people before the network effect exists.
- Native motion and micro-states that make a plan feel alive, not administrative.
Next Bets
- Deep links that route directly into a plan from Messages.
- Calendar and Maps handoff once a plan is locked.
- Smarter time suggestions from group availability patterns.
- Recurring plans and group memory for friend groups that plan often.
What I learned
The psychology is the product.
The biggest product question is not whether users can vote on a plan. It is whether the interface creates enough confidence that someone is willing to move the group forward.
That shifts the design focus toward commitment cues, visible momentum, lightweight participation, and a clear final state. The plan card has to reduce social uncertainty as much as logistical uncertainty.
Now live on TestFlight.
Lets is in TestFlight with real invite links, real groups, and enough instrumentation to see where plans lose momentum. Next: tighten the first-plan moment from beta feedback, then push toward the App Store.