Building a product in isolation is dangerous. You can easily spend months perfecting a feature that no one actually wants or a UI that no one understands.

With JupiterGoals, I wanted to get the design in front of users as early as possible. This post details how the initial concept evolved through feedback, mocked data, and confronting hard limitations.

The Initial Design & The Reality Check

The very first iteration of JupiterGoals was essentially a highly opinionated calendar. You inputted a goal, the AI broke it down, and it plotted it on a timeline.

However, early user feedback revealed a massive flaw: There were no stakes.

Users told me they liked the idea of the roadmap, but without a reason to actually do the tasks, it was just another to-do list they would eventually ignore. I realized I needed an accountability mechanism.

The Limitation: The “Money” Problem

My immediate thought for “Stakes” was financial: users would pledge $50, and if they missed a habit, they lost the money. It’s a proven psychological motivator.

Unfortunately, handling user funds in this manner introduces a labyrinth of legal and regulatory limitations (essentially acting as an escrow or betting platform). I realized that, as a solo developer, the compliance overhead would kill the project before it even launched.

I had to pivot the concept of “Stakes” away from hard currency and towards social or systemic accountability. This led to the concept of the “Shadow Partner” (an AI that challenges your excuses) and “Habit Graduation” (unlocking features as you prove consistency).

Refining the Design: The Radar Chart

As I moved away from just a “calendar view,” I realized users needed a way to visualize their overall life balance. If you are crushing your career goals but your health is failing, the system should reflect that imbalance.

This led to the introduction of the Identity Nodes (Vitality, Wealth, Career, Connection, Growth, Zen) and the central UI piece: the Radar Chart.

By mocking up data for these nodes, I was able to test two different UI approaches:

1. A deeply analytical “Dashboard” view (data-heavy).
2. A clean “Today’s Focus” view (minimalist).

Feedback heavily favored the minimalist “Today’s Focus” view, with the Radar Chart providing the high-level context only when requested.

The Next Pivot: Event-Based Habits

While testing the daily timelines, I hit another roadblock. Traditional time-blocking assumes a perfect day. If I schedule “Read for 20 mins” at 8:00 AM, but my kid wakes up sick at 7:45 AM, the schedule is broken, and guilt sets in.

Recognizing this limitation led to a potential pivot in how we handle triggers. Instead of purely time-based tasks, we are heavily exploring event-based approaches (Habit Stacking).

Instead of scheduling:

• 8:00 AM - Meditate

The system will encourage:

• When I finish brushing my teeth -> I will meditate for 2 minutes.

This subtle pivot changes JupiterGoals from a rigid calendar into a truly flexible, adaptive system that fits into real human lives.