Building a voice-based personal memory app (capture life via voice, ask questions later, get answers from your own past entries). Early messaging leaned hard on "everything stays on your device" — because most of the data does.

Then I actually mapped the pipeline honestly: to answer a natural-language question, the relevant entries have to go somewhere that can reason about them. Right now that's an external AI API, briefly, per query. Not stored there long-term, not used for training, but it's not the fully on-device story I wanted to tell.

Two options I keep going back and forth on:

1. Keep the honest, slightly-less-clean privacy pitch ("local storage, temporary processing for queries") and trust that transparency builds more trust than a marketing claim that doesn't survive a technical question.
2. Invest in cutting the API out entirely for the core query loop, at a real cost to answer quality, just to be able to say "100% on-device."

Went with option 1 for now, mostly because I noticed I only wanted to reframe the phrasing to make it sound cleaner — which felt like the actual signal to just be upfront about it instead.

Curious how others here have handled this exact tension — the version of your product that's easiest to market vs. the version that's fully accurate. Where do you land on "good enough to be honest about" vs. "not ready to ship"?

Launched an open beta a few days ago for a voice-based personal memory app. Nothing crazy, just wanted real usage data before committing to the pricing model.

20 testers in, and a few things stood out that I didn't expect:

- The onboarding drop-off isn't where I thought it would be. I was worried about the voice recording step feeling awkward — turns out that's fine. People stall at the "what do I even say" moment on their very first entry, before they've recorded anything.
- Retention after day 2 correlates way more with whether someone got a useful answer back from a question than with how many entries they logged. Makes sense in hindsight, but I was optimizing for capture volume, not retrieval quality, early on.
- Almost nobody has asked about pricing yet, which I'm treating as neutral, not positive — probably means they haven't hit a moment where they'd feel the value enough to think about paying.

Planning to run this for another week or two before deciding what changes based on this round vs. what needs a bigger test group to validate.

Curious if others running early betas have seen similar gaps between what you think will be the friction point vs. what actually is.

Running an open beta for an app I built (voice-first personal memory / AI retrieval). To get real usage and feedback, I unlocked full premium features for every beta tester, no restrictions.

Made sense for getting testers in the door. But now I'm thinking ahead to the actual pricing rollout ($6.99/mo or $49.99/yr planned) and wondering if I've made my own launch harder — beta users who got everything free are exactly the people I'll eventually ask to pay, and "it used to be free" is a hard frame to walk back from.

Options I'm weighing:
- Grandfather beta testers into a discounted rate forever, treat it as an acquisition cost
- Set a hard cutoff date, communicate it clearly from day one of the beta, no surprises
- Give beta testers full access only during the beta window, then drop to free tier like everyone else, with an early-bird discount as a thank you

Anyone been through this transition — full access beta to freemium — and have a read on which approach actually converts best without torching goodwill from your earliest, most engaged users?

Looking for iOS testers for a 2-week beta — full Premium access (AI questions, weekly insights) free during the beta.