grilling

### 3. What does “friends” actually mean? Following someone doesn’t necessarily make them a friend. - Is friendship mutual and approved? - Can someone share a recipe with specific people, or only all friends? - What happens when a friendship ends? - Can someone who loses access still read a previously downloaded recipe? That last question has no magic technical solution: **you can prevent future downloads, but you cannot reliably retract information someone already has offline.** Your product needs an honest policy. Also: private recipes require authorization on **recipe data and photos**, not just hidden UI. With Supabase, that means tested database RLS and storage access policies. ### 4. What does “offline” promise? Pick one: 1. Previously viewed recipes may be available. 2. Users explicitly download recipes for reliable offline reading. 3. Users can create, edit, comment, and like offline, then sync later. The third is a major scope increase. Even the second needs answers: - Are photos downloaded too? - Can users tell whether a download completed? - What happens after the author edits or deletes the recipe? - Will it still work after closing and reopening the app in airplane mode? **My launch choice: explicit downloads, read-only offline, no offline writes.** ### 5. Are comments and likes solving a real problem? - What launch hypothesis requires either? - If strangers can comment, how will users report abuse or block people? - Who handles moderation and deletion requests? Likes are relatively small. Comments create an ongoing operational responsibility. Neither fixes an empty feed. ### 6. What does “launch in four weeks” mean? - TestFlight or closed beta with 10 people? - Public release on one store? - Public release on both stores? Have you accounted for signing, store setup, privacy disclosures, account deletion, review requirements, and testing on actual devices? And what’s your real budget? At two hours per evening, five evenings a week, you have **40 hours total**—including debugging, deployment, and release work. ## What I would actually ship For a **cooking-first beta**: - One platform, small invited group. - Minimal sign-in. - Create and edit a recipe with one photo. - Private or public visibility only. - Browse a small seeded collection. - Explicitly download a recipe for offline reading. - Basic account and content deletion. **Cut:** friends-only sharing, follows, comments, likes, notifications, offline editing, and a personalized feed. If social sharing is the core hypothesis instead, keep basic sharing and cut offline. Don’t preserve your favorite features at the expense of a coherent test. ## Your pre-build test Before committing to the stack, get five target users to: 1. Show you how they currently save and share recipes. 2. Walk through a clickable prototype. 3. Contribute a real recipe. 4. Agree to use the beta for an actual meal. **The three answers I’d want from you first:** 1. Who exactly is this for? 2. What single behavior would prove the beta is useful? 3. Which features will you explicitly refuse to build before launch?