samuelalake / product designer + engineer

Rem · iOS · 2026

Turning everyday intent into work an assistant can actually do

Rem captures what you mean to do, turns it into a task, and helps move the work forward.

Rem thinking state resolving into the Rem mark
Role
Product design
and engineering
Timeline
2026–present
Platform
iOS
Focus
Product design
Design engineering

Project context

Work gets scattered across too many apps

Tasks, messages, notes, and calendar commitments live in different places. Keeping up means switching between them, rebuilding the plan in your head, and still doing the work yourself. Rem brings those priorities into one assistant that can help decide what matters and move the work forward.

Solution

One loop: capture, orient, work, brief, repeat

Rem brings capture, planning, and action into one assistant. A task persists after the conversation moves on, giving the person and the assistant one place to clarify the work, agree on what happens next, and follow the result.

01 · Onboarding

Onboarding explains Rem’s privacy model, connects the tools it can use, and introduces daily briefs, suggestions, and the assistant itself.

Rem turns a loose request into a smart poll of concrete next steps

02 · Capture

Get intent in before it disappears

People can start with a thought in their own words. Rem clarifies what they mean, offers a few useful ways to act on it, and turns the chosen direction into structured work.

03 · Orient

See tasks, time, and suggested next steps together

The agenda brings calendar commitments and tasks into one view, while Rem suggests useful work it can add from the surrounding context. Moving between days makes it easier to see what slipped, what matters now, and what comes next.

04 · Work

See what Rem worked on, then pick up where it left off

Each task keeps Rem’s activity and result easy to follow, so people can see what was done and continue the work without rebuilding the context.

05 · Brief

Communicate what needs attention

The daily brief brings important changes, overdue work, and upcoming commitments into one spoken update. When nothing needs attention, Rem can stay quiet.

Design explorations

Exploring the interaction model and modality

Voice can remove the friction of stopping to structure a request before asking AI for help. I studied Gemini, HUXE, Todoist, Claude, and Codex to understand who should lead, how much context an assistant should package, and how voice can sit alongside typing.

References

HUXE. An assistant-led daily brief packages context and leads the conversation.

Todoist Ramble. Loose user input becomes structured task context.

Product positioning

A vision for private AI that stays under your control

I started with two assumptions:

For Rem to do work beyond a chat, it needs somewhere to run and a device it can control. That made two choices foundational: where personal data should live, and whether longer-running work belongs on a desktop or the phone.

Where should your data live?

Cloud-onlyUser-owned
Rem
ClaudeOpenAI
ClovyHermesOpenClaw

The vision borrows a privacy model people already understand from messaging: encrypt conversations, keep durable data on a machine they control, and use the cloud only for backup.

Where should Rem run the work?

Desktop runtimeMobile runtime
Rem
ClaudeOpenAI
AGI, Inc.

Phone as remote. People can start, approve, and monitor work on the phone while a desktop or gateway handles longer-running tasks.

Future product direction

Exploring a Mac home and wearable capture

I explored two ways Rem could move beyond the iPhone: a Mac home for ongoing work and wearable capture.

Bring the mobile model to the Mac

A Mac experience could combine what Rem achieves on mobile with heyclicky’s cursor-style interaction, making active work, status, and recovery easier to follow.

Capture intent without reaching for the phone

Wearables could make quick capture and lightweight updates available in motion.

Where it stands

Shipped on iPhone, then opened at the core

Rem is live on the App Store for iPhone, and I released it as Apache-2.0 open source. Shipping forced the simplification the concept had been avoiding: the product got smaller and clearer as real use showed what didn’t earn its place. Opening it moved the work from adding features to making the core reliable, and the edge from the code to the product experience.

Reflection

I learned to get clear before I build

Understand the problem before choosing a direction

Rem sits in a product space with few settled patterns. I explored too many directions at once, then learned to form a clearer picture of the problem before committing to a solution. The product became simpler as my understanding improved.

Invite people in, then make ownership explicit

Building in the open helped me bring friends into the project. I owned product and they focused on the mechanics, but that boundary blurred and momentum faded. Next time I would involve more design builders and agree on ownership earlier.