When I wrote why I was building Flow, I had a hypothesis and a rough prototype. What I didn’t have was any idea how much the path from “this makes sense to me” to “real people are using this every day” would teach me.

This post is the retro. What it actually took to ship, what fell apart, what surprised me, and where I’m going next.

The scope cuts that made shipping possible

The version that went out to beta users was not the version I originally designed. Not even close.

The original plan had energy check-ins, HRV integration via a Bluetooth sensor, a weekly report view, and a smart rescheduling engine that would move tasks around automatically when your energy dropped. It was ambitious in the way that solo projects get when no one is telling you to slow down.

At some point I had to be honest with myself: I was building a second app inside the first one. Every feature I added made the core harder to explain and harder to trust.

So I cut. First the HRV integration, because the hardware pairing flow alone was going to take weeks and I hadn’t validated that users even wanted it. Then the automatic rescheduler, because it required a level of trust from a new user that I hadn’t earned yet. Then the weekly reports, deferred to a later release.

What shipped was the core loop: you tell Flow roughly how you’re feeling energy-wise when you sit down, it suggests a work block that fits the depth of focus that mood supports, you work, you log how it went. That’s it. No Bluetooth. No automation. No reports.

Cutting those features felt like failure at the time. It turned out to be the most important decision I made. Users can explain the app to each other in one sentence, which means they actually do.

What broke once real people used it

The first round of beta feedback arrived and I learned something humbling: I had tested the app on myself, which meant I had tested it on someone who already understood the concept, already knew where everything was, and had a very high tolerance for rough edges.

Real users did not respond that way.

Onboarding was the biggest problem. I had written what felt like clear instructions for how energy levels worked in Flow. Low energy means admin and shallow tasks, high energy means the hard creative or analytical work. That distinction felt obvious to me because I’d been thinking about it for months. To someone opening the app for the first time, it was abstract. Several people set their energy level to high at 9am out of optimism rather than honest self-assessment, then found that the suggested blocks felt out of reach. A few gave up before completing their first session.

The fix was less explaining and more scaffolding. Instead of describing the energy model upfront, the first session now asks a simpler question: “Right now, does hard focused thinking feel easy, okay, or difficult?” The labels do the work that paragraphs couldn’t.

There were smaller breaks too. A sync issue that only appeared when users switched devices. A notification that fired at the wrong time and confused people who hadn’t set up that feature yet. The kind of bugs that only emerge at real usage volume, in real environments, on phones with real constraints.

The feedback that surprised me

I expected users to talk about the scheduling. That was the core idea, energy-aware scheduling, and I’d put a lot of thought into how Flow suggested work blocks.

Instead, the thing people kept mentioning was the log.

At the end of each work block, Flow asks you to rate how the session went and leave a short note. I’d built it as a data input mechanism. Users were using it as a journal. Several people told me the two-minute end-of-session reflection was the most valuable part of their day with the app. One person said it was the first time they’d consistently tracked how their energy actually moved across a week.

I hadn’t designed for that. I’d designed a data model and they’d found a ritual inside it.

That changed how I think about what Flow is. It’s not just a scheduler. It’s a way of paying attention to yourself while you work. The scheduling surfaces that attention, but the reflection is where a lot of the value actually lives.

The other surprise: people cared much less about the AI suggestions than I expected. The AI-powered block recommendations are the technically complex part of the app. Users appreciated them when they were accurate, but what made people stick was the simple act of being asked how they were feeling before they started working. That question alone, without any AI involved, reoriented a lot of people at the start of their day.

The signals that mattered vs. the ones that didn’t

Downloads were easy to track and mostly useless as a feedback signal in the early days. The number that actually told me something was how many users completed three sessions in their first week. That number was smaller than downloads and harder to improve, but it correlated with the people who stuck around.

Completion of the onboarding flow was another signal I underweighted early. I was watching for crashes and errors. I wasn’t watching for the silent drop-off where someone got through installation, opened the app once, and never came back. When I added exit-intent logging to the onboarding screens, that silent drop-off became visible and fixable.

The feedback form I put in the app collected long, thoughtful responses from about one in ten users. The other nine didn’t write anything. But those nine told me things too: through usage patterns, through which features they never touched, through where they stopped in flows I thought were intuitive.

Listening to the one in ten who write is easier. Listening to the nine who don’t is where most of the real information lives.

What’s next

The immediate work is making the core loop more reliable and the onboarding genuinely fast. If someone can’t feel the value of Flow within their first real session, I’ve already lost them.

After that: the reporting layer I cut before shipping. Users who’ve been logging sessions for several weeks now have data, and they want to see it. A simple weekly view showing when their energy tends to peak and what kinds of work they rated highest during those windows is a natural next step, and one I can build on real signal now instead of guesses.

The HRV integration is still on the list, but further out. I want to earn the trust before I ask users to add hardware to the equation.

If you’re curious about the idea behind how Flow thinks about scheduling energy rather than just time, this post on energy-aware scheduling goes deeper on the model.

Thank you

I started writing publicly about this project before I had anything to show. That first post was mostly a bet that building in the open would keep me honest. It did. More than that, it brought people into the process: readers who asked sharp questions, sent encouragement at the right moments, and eventually became the beta users who gave me the feedback that made Flow better.

If you’ve read any of this series, thank you. You are a real part of how this app got here.

If you haven’t tried Flow yet and you do deep work and want to stop fighting your energy instead of working with it, you can sign up at /#leadMagnet. The beta is open and I’m still in the phase where early user feedback shapes everything. That phase won’t last forever, so if you’ve been on the fence, now is a good time.