April 2026 · GoCodeLab · Dev Mindset

0→1 Is Fun, 1→100 Stalls

If you have coded until 3 a.m. building an app and then put off the update for three months after launch, this is about you. And about me.

Last year I built a side project in 17 days. The first 9 days I barely slept. I went to bed at 4 a.m., woke up at 8, and coded again. I took my laptop to a cafe, skipped lunch, and kept coding. Because it was fun. No one asked me to. No money was coming in. But I still remember those 17 days as the most alive stretch of that whole year.

I shipped the app two weeks later. A month after that, I stopped updating it. A user feedback email arrived and I let it sit unanswered for six days. A bug report on GitHub Issues has been open for half a year. I am neglecting that app. It feels hard to believe I'm the same person who was so fired up while building it.

Realizing this cycle isn't only mine made me feel a little better. Then I got curious about why it happens. The conclusion that I'm just lazy didn't quite cover it. Across those 17 days, I was as diligent as anyone.

Flow — The Narrow Band Where Challenge and Skill Meet

In 1990, Hungarian-American psychologist Mihaly Csikszentmihalyi published Flow: The Psychology of Optimal Experience. He's the one who named the state of being so absorbed in a task that your sense of time disappears flow. The already? moment I had at 3 a.m. when I glanced at the clock — that's flow.

Csikszentmihalyi drew a now-famous diagram. The horizontal axis is skill level, the vertical axis is challenge level. Skill too high and challenge too low produces boredom. Challenge too high and skill too low produces anxiety. Flow only happens inside the narrow diagonal band where the two axes rise together. That band is called the flow channel.

The important point is that the flow channel is not a fixed spot. As I get better at coding, the same task moves from challenge into boredom. To stay in flow, challenge has to climb in step with skill. Without that, the same work suddenly stops being fun. The reason I was able to spend those 17 days so energized is that building my first app was the exact challenge level for the skill level I had at the time.

Why the 1→100 Stretch Sits Outside the Flow Channel

The trouble starts after launch. Post-launch work is a sudden drop in challenge difficulty.

You're not building new features anymore. You're fixing bugs in features you already shipped. You're not designing new screens. You're moving a button five pixels because a user said I can't see the left button. You're not designing new flows. You're patching for iOS 18 compatibility. From your current skill level, this work is too easy. So it falls out of the flow channel and into the boredom region. Boredom is not something willpower can muscle through. No matter how hard I tell myself I have to do this, my brain just doesn't latch on.

The reward structure changes too in the 1→100 stretch. While building, what you made today was immediately tangible. A screen that didn't exist yesterday existed today. That alone was dopamine. After launch, what you do today is keeping yesterday's thing running. From the user's side, working software is the default, and the labor that keeps it working is invisible. Invisible labor doesn't get feedback. No feedback means one core condition of flow is missing. Csikszentmihalyi listed eight conditions for flow, and one of them is immediate feedback. Post-launch work fails that condition almost completely.

Self-Determination Theory — When Intrinsic Motivation Is Replaced by Extrinsic Reward

This is where the second theory enters. In 2000, two psychologists named Edward Deci and Richard Ryan formalized Self-Determination Theory (SDT). It splits motivation into intrinsic and extrinsic, and asks which conditions make a person keep doing something.

Intrinsic motivation is doing something because the activity itself is enjoyable. That's the reason I coded for 17 days. Extrinsic motivation is doing it because something follows from it. After launch, downloads, revenue, ratings, and Twitter reactions take over the motivation slot.

One of SDT's most interesting findings is the overjustification effect. When you attach an external reward to something you originally enjoyed, your interest in it drops below its original level once that reward goes away. While the reward is flowing in, your brain re-classifies the activity as something you do for the reward. After that, when the reward stops, the activity stops too.

The way I clung to download counts right after launch was exactly this trap. I went from coding because building was fun to coding only if downloads went up. When downloads didn't go up, I lost my reason to code. The motivation that kept me up till 3 a.m. for 17 days got replaced, within two weeks of launch, by an external metric called 100 downloads. When that metric didn't climb the way I'd hoped, the whole engine cut out.

SDT also names three conditions for sustaining intrinsic motivation: autonomy, competence, and relatedness. Autonomy is the sense that you're doing it your way. Competence is the sense that you're getting better at it. Relatedness is the sense that you're connected to someone. While building, all three are satisfied. You set your own schedule, build the features you picked, feel competent as you write new code every day, and feel connected through build-in-public. After launch, all three weaken. User feedback shakes your schedule (autonomy↓), repeating the same kind of work blunts the competence signal (competence↓), and even when users grow, they recognize the app rather than you, so relatedness stays thin.

My Pattern — Hyped at Launch, Bored at Two Weeks, Neglecting at One Month

Here's my pattern, written honestly.

On launch day I post a launch thread on Twitter. Likes show up. Downloads hit around 80 on day one. That night I'm hyped enough to start planning the next feature. I write weekly update on my calendar for every Wednesday.

I do the first week's update. Hyped. I push the second week's update. Once you start pushing, what you didn't do last week and what you have to do this week merge, and the challenge level doubles in one go. Looking at a doubled challenge, I just don't start. Three weeks in, the gap between what I originally wanted to build and what I haven't done yet grows so large that I close the lid on the app. Then I start a new project. The new project is back in the 0→1 zone, where my challenge and skill engage again. I code until 3 a.m. for another 17 days. I ship again. I neglect again. That's my cycle.

Can Maintenance Have Flow Too — Redesigning Small Challenges

I can't propose a grand fix. I haven't broken this cycle myself. But after understanding Csikszentmihalyi and SDT, there are two light redesigns I'm trying.

First, add artificial challenge to maintenance work. Even if I'm fixing the same bug, I put a time constraint on it: under 30 minutes. I bundle a simple patch PR with a side challenge like also do this small refactor. Once the challenge level drifts back near my skill level, the work shifts from boredom toward the flow channel. It's not perfect, but it works better than scolding myself with I have to do this.

Second, stop checking external reward metrics. I look at downloads, revenue, and ratings only during the first month after launch, then I turn the dashboard off. The point is to keep external metrics from eating my intrinsic motivation. Instead, I write down what code I wrote today in a personal note. The aim is to recover motivation through the act of building itself.

I can't claim these two moves untangled the whole cycle. But once I understood it as the structure of the flow channel and the replacement of intrinsic motivation rather than my laziness, I beat myself up less. Failing at 1→100 isn't a flaw in me. The 1→100 stretch simply isn't designed to be as fun as the 0→1 stretch. Closing that gap is a different kind of work — closer to redesigning the environment than to grinding through it on willpower.

An open issue is still sitting in GitHub Issues today. I'm planning to set a 30-minute timer and open it. That's the lightest start I've found, the one that doesn't require self-blame.

This article reflects information as of April 2026. The cited studies don't change with time, but my interpretation of them might shift with better data.