← Selected work

01 / INDEPENDENT PRODUCT · IN DEVELOPMENT

Preserve the reason behind the screenshot.

Recall is an iOS-first screenshot assistant. The product question is whether a saved image can help someone resume a task, rather than become another item to organize.

The problem I’m working on

Screenshots make capture effortless, but the image alone may not explain why it mattered. A purchase comparison, travel plan or warranty can disappear into a camera roll before the next action happens. This is the problem hypothesis; its frequency and value still need user validation.

My contribution

I’m defining the product scope, user journeys and reliability requirements, and building toward an iOS experience. The current direction organizes the experience around Today, Library and Capture, with individual Saves connected into Threads.

The portfolio demo illustrates the intended interactions. It is a conceptual exhibit, not a recording of a released app.

Try the portfolio exhibit →

Notes from building Recall →

The decision: separate reminders from uncertain checks

Returns

A user chooses when to revisit a save. The reminder is deterministic: the product should honor that request without asking a model to reinterpret it.

Watches

A check depends on outside information. The experience needs a next-check window, visible failures and an honest distinction between “nothing changed” and “could not check.”

This adds two concepts to explain, but makes the promise behind each action clearer. The scope decision is to keep that distinction visible rather than imply every action has the same certainty.

Where AI belongs

Contextual questions are scoped to a screenshot or thread. That boundary is intended to keep assistance tied to the thing someone saved. It also limits scope: Recall is not being designed as an unrestricted general-purpose chat assistant.

Evaluation needs to check whether answers stay grounded in the saved material, acknowledge missing information and help the user take the next step. Those are evaluation requirements, not measured results.

What could fail

  • A save joins the wrong thread: correction should be easy and visible.
  • A Watch cannot complete: surface the failure instead of presenting silence as success.
  • Notifications are denied: the Today view should still let people recover their pending actions.
  • An answer exceeds the screenshot evidence: make the information gap explicit.

How I plan to test value

The proposed pilot starts with 30 frequent screenshot users. The gates are at least 15 returning across three weeks and at least six willing to pay, followed by renewal observation over 60–90 days. These are planned thresholds, not achieved outcomes.

I also want to compare Recall with the participant’s existing Photos and reminders workflow, measuring successful resurfacing, grouping corrections and failure recovery. Repeat use matters more than the number of screenshots imported.

Next milestone

Prepare a pilot-ready capture-to-return flow and test whether people prefer it for a real recurring task. The decision after that evidence is whether to deepen the core loop, change it or narrow the product further.

Read the product note: when a reminder should stay deterministic →