Rem
Rem is a personal AI assistant that captures intent, clarifies it into work, and runs approved actions through a cloud or Mac gateway the user controls.
Background
Rem started with a problem from my own workflow: I could capture plenty of things I intended to do, but turning those intentions into protected time was harder. I would remember something important, lose it inside competing priorities, then spend more time managing tools than doing the work. The early question was simple: what would it look like if an assistant could help someone capture what matters, clarify what should happen, and turn that into time they could commit to?
The first direction was time blocking. I had been looking at products like Motion and wondering whether Rem could do something similar with the tools I already used: read tasks, look at calendar availability, and suggest a realistic plan for the day. I built an early Notion Time Block script to feel that idea working. When I brought it to collaborators, the idea resonated, but the stronger push was that planning alone was not enough. A useful product should help people make progress, not just arrange their intentions. That shifted Rem into a broader loop: capture what is in someone's head, clarify it into structured tasks and events, and eventually act once the product has enough context and permission.
Problem and opportunity
Most productivity systems split the work across surfaces. A task app captures intent, a calendar protects time, a notes app holds context. Today's AI chat apps, like ChatGPT or Claude, can summarize or rewrite, but they rarely move work forward in a way the user can trust. The result is that people manage more tools instead of finishing more work.
Productivity and task management is a multi-billion-dollar category, and the breakout adoption of AI chat apps shows people now expect to get things done by talking to software. But that adoption has mostly produced better conversation, not better follow-through. The opportunity Rem set out to claim sits in that gap: connect the surfaces people already use into a single loop, with voice as the entry point so capture feels closer to thinking out loud than to filing into an app.
Role
Rem is a three-person founding team. As Lead Product Designer & Engineer, I work across product direction, interface design, and implementation of the core app experience, while my co-founders own growth and real-time infrastructure. I initiated the product direction, brought collaborators into the idea, and worked across product strategy, interaction design, prototyping, and implementation. My role moved with the product: from early time-blocking and assistant flows into the interaction design of how AI serves multiple jobs and communicates its status.
Building the product
Capture and clarify
The first version of Rem was a voice-first planning assistant. We prioritized voice-first input because capture should feel closer to thinking out loud than filing something into an app. To reduce the friction of capture, we studied voice and AI products, including HUXE and Todoist, to understand who leads the interaction and how much structure the interface should show.
Those references pulled in different directions. In HUXE, the assistant leads the conversation and packages context into a brief. In Todoist Ramble, the user leads with loose input and the AI turns it into something structured. We tried to find the balance between those modes. Exposing separate states for composing, listening, and responding made the product feel heavy, so the first real version moved toward something simpler: the user talks, Rem responds turn by turn, and the product creates or updates the right task or event when it has enough information.
HUXE
TodoistChat view evolutionWe started by exploring a less familiar assistant surface, then moved back toward the familiarity of chat with a voice-call-like control at the bottom.
The execution opportunity
Acting on a user’s intent was always the goal, but for a long time it was the most ambiguous part of the broader loop. As the AI landscape shifted, it became easier to name what we were building toward. OpenClaw showed a useful model for remote control. Claude Dispatch made approved computer actions feel like a broader pattern. Codex made the control surface concrete on mobile. That sequence made the act part of Rem feel less speculative: not only planning work, but running approved actions through the right tools and services.
OpenClaw works like a remote control. There is the remote, the part that issues commands, and the runtime, the thing being controlled, which has to live somewhere on a connected device. That raised the central question of the execution layer: what device runs the actions, and where does it live? Connecting Rem to a user’s own Mac was the obvious answer, but building on the Mac for a product that is iOS-first carried its own challenges. However, we made a deliberate strategic choice to start with a cloud gateway, a controlled cloud environment Rem could run actions through, which let us derisk the harder problems before committing to native Mac work.
This made Rem’s wedge concrete: the product is not another place to talk to AI, but a controlled runtime where AI can act with scoped permission. Actions happen through a gateway the user owns, and what the assistant did can be reviewed or revoked.
Communicating status
OpenClaw is powerful, but it is infrastructure, not a product an everyday user could make sense of. The design challenge was direct: how do we simplify the runtime into something a normal person could trust? Two things mattered most. Installation and pairing involve a lot of steps, so the work was reducing that to as few as possible. And the product had to transparently communicate status, showing clearly when a connection was healthy, loading, or failing, and giving a path to recovery. Recovery mattered more than it might sound: building with AI introduces bugs, and we were not always on the happy path. Settings became a more elevated part of the experience, because it needed to communicate status, permissions, and capabilities.
Where it is now
Rem has been live on the App Store, and the first release did its job as an experiment. It validated the planning-assistant surface, but it also showed where the product fell short: reliability gaps and a missing new-user experience kept people from understanding why to return. That clarified the real product question. Rem only becomes sticky when it can reliably move someone from intent to visible progress.
The relaunch is focused on exactly that: a clearer new-user experience, more reliable gateway connection, and a simpler explanation of what Rem can do. We still have a waitlist to re-engage, and the relaunch is designed to test whether a clearer, more reliable version makes the loop hold.
In parallel, we are building the Mac app as the user-owned runtime surface: a place where Rem connects to a user’s actual computer, runs approved actions, and makes execution feel local, inspectable, and under their control. It is the clearest next expression of the strategy, and the natural complement to the cloud gateway.
Reflection
Rem sharpened the way I think about AI products. The model is only one part of the work. The product has to decide what the user is trying to do, what context the assistant can use, what action it is allowed to take, and how the user stays in control.
It also changed how I build. I learned to move between product thinking, interface design, and engineering constraints with more confidence, because the product kept asking for all three. The same lesson showed up in the process: useful AI work needs structure around it. The work has to be scoped, reviewed, tested, and tied to a real outcome, or it becomes another source of ambiguity.