The Day I Planned Everything

By day five I had an iPhone prototype, a fresh Swift + Metal engine, and a growing pile of ideas I couldn't remember from one coding session to the next. I knew I had to stop and think about what I was actually building. This post is about the day I did that, and ended up creating thirty-four Linear issues without typing a single word into Linear directly.

The trigger

I'd been working on the game for five days. Every session started with a mental reload: "where was I, what did I leave half-done, what was the next thing I was excited about?" I was holding the whole plan in my head. The head was getting full.

On day five I caught myself describing the same feature idea to Claude for the third time. Not because I'd forgotten I'd described it, but because I'd done something with it in the last session and I wasn't sure what. Had I implemented it? Partially? Rejected it? I scrolled through recent commits to reconstruct the state of that idea and gave up after a few minutes.

That's when I knew I had to stop coding and start planning. Not the next feature. The whole thing. Move everything out of my head and into a real work plan. Carve out a full day for it.

The timing wasn't arbitrary. On day three I'd gambled on the Swift + Metal rewrite (see the previous post) and it had paid off. The engine was solid. The architecture was stable. This was the first moment where I could afford to stop running forward and look sideways. If I'd tried to plan on day one, it would have been speculation. By day five I had real experience with the codebase, so the planning was grounded.

The tool question

I'd never used Linear before. At my day job (Smartbull, Israeli fintech, web dev) we use ClickUp. In a past role I used Trello. I've poked at Notion. I had opinions about all of them and none of the opinions were "this is the tool I reach for on a personal project."

So I researched the options. With Claude, naturally.

Notion was too big, too much setup before you can do anything useful, and I wanted to start planning today. I use ClickUp every day at work and I know exactly how much clicking it takes to do simple things. Monday is fine but "Trello but fancier" wasn't what I was after. Trello I know best, but it hits a ceiling fast.

Linear I'd never used. I'd heard people rave about it. But the thing that sold me wasn't features or UI quality. It was that Linear is agent-first.

Agent-first means it has a solid MCP integration, a good API, and Claude Code has a dedicated Linear plugin that can read, write, and update issues through natural language. That's not a nice-to-have when you're running an entire project as an AI pair. It's the difference between a tool your Claude can use and a tool your Claude can only describe.

I picked Linear for that one reason. Everything else was a tie.

Since then I apply this filter to everything: pick tools based on how well they integrate with the AI workflow, not just on feature lists. The best tool for a solo-plus-Claude workflow is often not the best tool for a human-plus-human team.

Thirty-four issues, zero words typed

This still feels slightly ridiculous. I created thirty-four Linear issues on day five, 2026-03-21. I did not open the Linear UI and type into a form once. Every issue was created by Claude Code through the Linear MCP plugin, based on me talking about the game in a chat.

The workflow: I'd say something like "I want to make the combo system feel better when you chain a lot of jumps together" and Claude would ask clarifying questions. How many jumps counts as a lot? What does "feel better" mean? Audio feedback, visual feedback, scoring? I'd answer. Claude would propose three or four issues that cover the concept, either a parent issue plus a couple of children or a single feature-scoped issue with a detailed description. I'd say "yes to the first two, skip the third, and the second one should be a bug report not a feature request." Claude would create them. Next concept.

No form-filling. No clicking. No "where does Linear put the Priority field, I can never find it." Just a conversation that turned into a project plan.

The issues fell into clusters naturally: backend infrastructure (run submission, leaderboards, identity), economy and monetization (coins, rewards, store), dopamine loops (celebration moments, effects, reward animations), virality (sharing, friend codes, referrals), retention (daily challenges, streaks, progression unlocks), launch impact (first-impression polish, onboarding), and future bets like PvP and remote config that I knew I wanted eventually but didn't need to start today.

By end of day I had eight milestones, six epics, thirty-four issues, and a set of labels that described work by what it does for the player (Dopamine, Retention, Virality, Launch Impact, Foundation) rather than by what it is technically.

The labels matter more than the issues

The labels are the thing I'm proudest of from that day. They're not engineering labels. "Bug," "Feature," and "Refactor" exist too, but they're secondary. The real organizing principle is product labels: Dopamine, Retention, Virality, Launch Impact, Foundation.

When I look at the board and ask "what should I work on next," this framing forces me to think about why each issue matters. An issue tagged "Dopamine" might touch Swift code, audio files, Metal rendering, and server catalog config, but its job is to make the player feel good at a specific moment. If I remember that, the implementation choices get clearer. If I treat it as just a coding task I lose the point.

This came naturally because it's how I think at work. Smartbull is a fintech. I evaluate features by business impact, not implementation complexity. But applying that to a game was different. Games sell on feel, and feel decomposes into exactly this kind of taxonomy: reward moments (Dopamine), return triggers (Retention), invitation moments (Virality), first impressions (Launch Impact).

If you're a developer starting a game side project, steal these labels. They'll serve you better than Bug/Feature/Chore.

The product-thinking leap I didn't expect

Something happened on day five that I didn't predict.

At Smartbull I'm Head of R&D. I design, architect, research, make technical decisions. I trust myself with company code because I have domain intuition. I know the fintech space, I know what our users need, I know what will break in production.

On Geo Climber I had none of that. I'd never shipped an iOS app, never built a game, never written Swift or Metal. And the work I was doing on day five wasn't even engineering work. It was product work. Product specs, not design docs. Feature tradeoffs, not technical tradeoffs.

At work I'd never delegate this to an AI. Product strategy feels like the thing you have to do yourself because it depends on context only you have: the company's market position, the team's capacity, the roadmap politics. Hand that to Claude and you'll get a confident plan that has nothing to do with your actual situation.

But on Geo Climber I was out of my depth on every axis, and the situation was simple enough that Claude could hold all the relevant context. So I did the thing I'd never do at work: I trusted Claude with the strategic thinking, verified its outputs, and let it help me write thirty-four issues that I couldn't have drafted by myself in a single day.

I took this lesson back to my day job. Not "delegate all strategy to Claude." Something more specific: Claude is safe to trust with more than you think, as long as you're actively verifying. The failure mode isn't that Claude is wrong about strategy. The failure mode is that Claude is confidently wrong and you don't notice because you stopped checking. If you verify, you're fine. Side projects are the right place to practice that habit because the stakes are low and the feedback loop is fast.

The long-term milestones I don't expect to hit

One more thing. The eight milestones ranged from "Core Integrated" (already done that day) to "Long-Range / Future Bets" (explicitly deferred). I don't believe most of them will land exactly as I drew them. I'm not even sure all of them will land at all.

That's fine. Long-term milestones in a side project aren't predictions. They define the theme of short-term work. "If this is where I'm heading, then this week's decision should point in that direction." They're a forcing function for coherence, not a commitment to a specific roadmap.

Set them early, even when they're speculative. They cost nothing, they create a sense of direction, and when reality diverges from the plan (it will) you get to see exactly how and why.