Draft Theory: Goal to Action Planner

I have always tried to run my life on systems. Two of them worked.

I went from 83 kg to 73 kg in three months by logging what I ate every day and watching the trend line. And I ran my first 5 km having never run before, stepping up from 200 m to 400, 800, 1 km, 2, 2.5, 5. Both worked for the same reason: there was a progression, I could see where I was on it, and there was enough flex that a bad day did not end the plan. If I took a sidestep, I knew about it.

Notion held both, and it is remarkable for it. It has one cost: every page has to be built before it is useful.

Then I set a third goal — design and ship an application — and failed badly. I did not know which metrics to track, because I did not know what the work involved. I was jumping into something I was not sure how to do, while also going to the gym, running, learning and working. Too many things at once, none of them sequenced, and no way to see what any one was costing the others.

What I wanted to build

That failure is where the app came from. Something that could weigh goals against each other — a real cost–benefit view of what to pursue and what to leave alone. Something that scoped a goal to the life I actually had and said honestly whether the target was reachable or needed more time. Something that scheduled the work and joined it up, so I could see what today was contributing to. And because everyone runs their life differently, I wanted it neutral: highly customisable, a structure anyone could bend to anything.

I had been keeping a journal of frictions — in my own life and in the lives of people around me. Across 15-plus conversations it gave me an overarching view of what actually makes people deviate from what they said they wanted. Secondary research on Reddit and X surfaced the same problems in other people's words, and I looked at the goals people commonly set, to see what structure could be built around them.

Atomic Habits and the books near it all said the same thing, and it matched what I had lived: the system is what people can actually follow. I had material. I prototyped quickly with AI tools, and built.

A reflection and journaling app for iOS. You voice-record moments through the day, AI generates interpretations and emotional insight, and the app surfaces emotional patterns over time.

Underneath ran a Goals–Plans–Systems framework, hidden from the user. What you saw was a five-phase journey: See, Understand, Shift, Build, Own. Home held AI mirror insights and your current phase; Notebooks held per-goal overviews; Journey held emotional patterns. A floating gold record button sat over everything as the primary action. Warm, premium, calm, dark — intentionally a growth companion rather than a productivity tool.

I killed it.

Terrible name. Better instinct.

I took it back to the same people with more utility and less ceremony. They were happier with it. The design started to clarify, and watching them use it I finally saw what I had been building the whole time without naming it: a task-breakdown application. Not a mirror, not a journal. Something that takes a goal too big to start and makes it small enough to begin.

That was the first time the product had a shape I could describe in a sentence.

With two builds behind me I could look at Structured, Habitica, Streaks and Notion as material rather than as evidence I was late. That difference matters more than it sounds. Before, the landscape was demoralising. Now it was comparison.

Across the 15 conversations and the threads I pulled from Reddit and X, one person kept showing up. They already have a goal, sometimes two. They have written it down — in Notes, or on a sticky note above the desk. They know what they want. What they cannot do is look at "run a marathon" and see Tuesday.

They have tried Notion and spent two weekends building a dashboard before starting the actual thing. They have downloaded a habit tracker, used it for nine days, and felt worse when the streak broke than they did before they had the app. They do not need motivation. They do not need a system that asks them to define their identity before they can log a rep. They need the gap between "I want this" and "here is the first small thing" closed, without ceremony.

That is the user. Not a productivity enthusiast. Not someone who wants to build a second brain. Someone with a goal, a life that already has four things in it, and no bridge between the two.

After looking at the landscape I built Atlas: take the strongest patterns from the existing tools and weave them into one experience aligned with the original thesis. Instead, it inherited exactly the issue I was trying to avoid.

When people opened Atlas, the feedback mirrored HabitFlow's: "What is this actually for?" A smart to-do list? A goal tracker? A calendar overlay? Because it tried to cover every step of task management, it had no dominant identity — and by giving people total flexibility, I forced them to invent their own workflow before they could get any value from the first session. Atlas is the build that became Draft Theory. It was not killed; it was cut.

Four ways to fix it

Pain points are not a problem statement

Cutting features was not a UI clean-up. It forced me to stop confusing pain points with a problem statement. Collecting pain points gives you a long feature wishlist; a problem statement defines the boundary of the solution. Atlas failed because it tried to cure every symptom. To build something people use, I had to narrow to one thesis: sequencing a goal into a startable path.

Alongside the conversations I kept notes from behavioural-science research and the podcasts I already listen to. Read together, they suggest that standard productivity mechanics actively undermine long-term adherence.

Having narrowed the product, I immediately started growing the part that was left.

Every step made sense at the time. Atomic Habits argues identity comes before target, so setup should ask who you are trying to become. Obstacles should be named up front rather than discovered halfway, so: what will get in the way, and what will you do about it? Goals are not one shape, either — reading ten minutes a day to finish fifteen books is a consistency goal, while a marathon has to get progressively harder — so the app should ask which kind this is and structure the path to match. My own two successes had been one of each, so this felt important.

Then I kept going. Cap how many goals you can hold, unlocking slots only by finishing one, so restraint becomes an achievement. A mood tracker, so a skipped day still produces signal. I got the setup questionnaire down to ten questions and thought I had been disciplined.

Cutting the questionnaire left me with no goal-creation flow at all. Rebuilding it, I asked a different question. Not what do I need to know about this goal, but what does a finished goal actually look like?

It looks like a calendar. A sequence of sessions, in order, across time. So let the user build that directly — no interrogation, no questionnaire producing a plan they have never seen. You make the thing itself, and my job is to make the making easy.

That is also where AI found its right place, which is late. Across all three builds I had treated AI as the answer to every hard problem. Know Yourself was AI-generated insight end to end, and after it every gap got filled with "AI will handle that." It is a seductive way to design, because AI can do anything you can describe, so you stop having to specify. Unspecified is exactly what both failed builds were.

AI is liquid. It flows wherever you point it and slips through your hands while you are holding it. Build the container first, in plain terms, as though AI did not exist. Then pour.

Information architecture first, before a single screen.

You write a goal. You sequence it. When a step is too big to start, you break it down — which is also what makes it easy to pick up again the next day. Everything is manual, on purpose.

Everything cut, written down in order

It does one thing. That is the finding, not the compromise.

What I would do differently with a team

Solo was a constraint, not a preference. Two things would have changed with even one other person. I would have instrumented HabitFlow instead of rebuilding from conversation — I showed each build to the same advisory group rather than running a real test, so I got opinions where I needed behaviour. And I would have written the problem statement before the first build, not after the second. The pain-point journal was good research. It just was not a brief, and nobody was there to tell me the difference.

1. 01

   Pain points are not a problem statement

   I had a year of good research and still built the wrong thing twice, because I never converted findings into one sentence a user could act on.
2. 02

   Scope grows through good decisions, not bad ones

   Every feature I added to goal creation was defensible. The sum was a wall.
3. 03

   Design the container before the liquid

   Treating AI as the answer let me stop specifying, and unspecified is what both failures had in common.

Next: goal types · AI-assisted sequencing · the priority stack.