PlanR is a goal-oriented planning app with integrated progress tracking. I built it to solve a practical problem I kept running into: goals are easy to write down, but hard to keep connected to the work that has to happen this week.
Today
Launch portfolio refresh
68 percent complete
Write final case intro
45 min
Review mobile layout
Today
Log progress and blockers
Evening
Live
Firebase product build
5
Core workflow stages
Fast
Release and feedback loop
PlanR came from the space between ambition and follow-through. I did not want another place to store tasks. I wanted a product that could help turn a goal into a small set of decisions I could act on, review, and adjust without losing the thread.
I kept seeing the same gap in my own workflow. I could define the goal, but the plan would get messy once real life interrupted it. The missing piece was not another task list. It was a system that could keep the goal, the next action, and the review loop connected.
Calendar apps handled time. Task apps handled lists. Notes apps held thinking. None of them gave me a clean way to move from a long-term goal to a weekly execution plan, then back into review without rebuilding context.
PlanR started as a practical tool for myself. The bar was simple: if I would not open it on a busy day, the design was too heavy. That pushed the product toward short loops, clear states, and fast capture.
The product is built around a weekly loop. The user starts with a goal, breaks it into clear work, schedules the next set of actions, then reviews what moved and what got stuck.
Capture the goal
Break it into milestones
Plan the week
Track execution
Review and adjust
The early versions were useful but not sharp enough. Each iteration forced one question: does this make it easier to act, or is it only making the planning system look more complete?
The first version was too close to a normal checklist. It helped capture work, but it did not explain why the work mattered or how it connected to the larger goal.
The next version moved goals to the center. That made the product clearer, but it still needed a stronger weekly rhythm so users could decide what to do next.
The current direction connects goals, milestones, tasks, progress, and review. The product became less about storing plans and more about helping people keep promises to themselves.
After releasing early builds, I used feedback to simplify flows, tighten the mobile experience, and remove anything that made planning feel like extra work.
This is not a productivity toy. The interface needs to feel quiet, structured, and fast to scan because the user comes back when they are already trying to make decisions.
Most planning tools store intent. PlanR turns the intent into milestones, tasks, and a weekly operating plan.
The system keeps the next action, current streak, and blocked work close to the goal instead of hiding them in separate views.
Missed tasks roll forward cleanly. The plan adapts without making the user rebuild the whole week.
PlanR became a good test for how I use AI in product work. I was not asking tools to invent the product. I used them to move through complex implementation work faster, then made the product decisions myself.
Firebase let me move quickly without spending weeks on backend setup. I used it to handle the product foundation, including persistence, deployment, and the data model behind goals, tasks, progress, and reviews.
Claude Code helped me work through complex backend flows, especially where planning logic touched data structure. Rolling tasks forward, syncing progress, and keeping goal state predictable needed careful implementation.
I used Codex to tighten React components, debug edge cases, refactor repeated UI patterns, and keep the product moving without getting stuck in small implementation loops.
Instead of waiting for a polished launch, I shipped early versions and watched where users hesitated. The feedback helped me decide what to simplify, what to rename, and which flows needed stronger defaults.
This is the deployed product, not a recreated mockup. The frame uses the iPhone 16 viewport size so the mobile-first decisions can be reviewed in the shape they were designed for.
The live build establishes the product shell, visual language, portrait-first behavior, theme support, and the core planning direction.
Designed as a portrait-first product, not a generic desktop dashboard.
Uses a neutral interface so planning data stays readable for daily use.
Connects goals, tasks, blockers, and review in one loop.
Keeps the interaction model simple enough for repeated weekly use.