Metrics Snapshot
This case study focuses on the product thesis + execution realities: what worked, what broke, and how I’d rebuild it now.
Problem
A lot of people want to journal, but the habit breaks because writing is high-friction: you need the notebook, the right moment, the right mood, and you often end the day tired. Miss a few days and it fades.
Who felt it most
The end user (and buyer) is the same person: someone who has tried journaling before, but friction consistently wins. My early target skewed younger, but the problem is broad.
Insight
This started as a personal pain. I tried journaling through different mediums and repeatedly stopped when I didn’t have the book, was outside, forgot, or couldn’t bring myself to write.
Early validation was lightweight (friends/peers agreed it’d be useful), but it surfaced two themes fast: privacy/security anxiety and willingness-to-pay relative to costs.
The Bet
Hypothesis: Users are more likely to journal daily if their journal calls them at a chosen time and lets them “leave a voicemail” entry after a tone.
Riskiest unknown: whether I could implement the call workflow end-to-end at the quality bar I wanted (technical risk).
Solution
Yappr was built around two journaling journeys:
- Call check-in: user receives a scheduled call → hears a tone → records a journal entry (voicemail-style).
- Manual journal: open the app anytime → tap record → speak your entry.
Key product decision
Anything meant to reduce friction should not add friction itself. The experience had to be “one tap” simple.
What was built
- Audio-based journaling: working before the call feature.
- Speech-to-text: planned as part of the core experience.
- Journal timeline: journaling by days + ability to revisit/edit old entries (UI needed work).
Design
- Figma prototype for UI exploration.
- Used Cursor to ideate on design directions.
Technical Build (high-level)
- iOS: Swift
- Backend: JavaScript + Python scripts
- Database: MongoDB
- Calling: Twilio API
- Speech-to-text: OpenWispr
Hardest technical challenge
- Implementing the Twilio call workflow reliably for a multi-user product.
- Deciding between direct speech-to-text vs storing audio then transcribing.
Costs & Pricing (early thinking)
This was bootstrapped and costs became real because the calling workflow depends on paid APIs. As costs started to feel tangible, it created a practical constraint.
- Planned price: $5.99/month (no strong research; based on estimated infra + API costs).
- Estimated marginal cost: just over ~$3 CAD/user/month (approx) due to Twilio + database + processing.
Go-to-Market (planned)
Yappr didn’t reach the App Store, but I started a social media page and posted some early content. The intended GTM was consumer distribution:
- UGC + short-form content (habit + journaling angle)
- Paid Meta ads once conversion funnel is proven
This stayed conceptual because the product didn’t reach launch readiness.
What went well
- Built my first iOS app (or at least ~80% of it).
- Learned Xcode + local testing basics.
- Proved to myself it’s possible to build consumer iOS products end-to-end.
What didn’t
- No users onboarded (stopped pre-launch).
- Reading/editing old journals UI wasn’t good enough.
- Hit a motivation cliff once the Twilio + backend complexity increased.
Diagnosis (why it stalled)
The product stalled due to a combination of technical complexity and motivation decay. It became clear the remaining work was beyond “basic vibecoding,” and my tooling + experience at the time wasn’t enough to push through quickly. Other opportunities appeared, and I deprioritized the project.
Key user concerns surfaced early
- Privacy/security: who can see my journals? how is it protected?
- Cost: how much would I pay, and is it worth it?
If I restarted today
- Use Claude Code to accelerate implementation + debugging of the calling workflow.
- Use Supabase for auth and database (reduce backend surface area).
- Do real pricing research and validate willingness-to-pay before building the full experience.
Learnings (so far)
- “Reduce friction” products require an extremely smooth core experience, any setup complexity breaks the promise.
- Technical risk can become the real bottleneck even if the product idea is strong.
- Security/privacy isn’t a later problem in journaling, it is the product.
- Tooling matters: better tooling could have changed the outcome (or at least the speed of learning).
- I learned where my own motivation/ability boundary was at the time, and how to design around it next time.