The Easy Part I Skipped

Two months ago I wrote a post called The Work After the Work. The thesis was that shipping MapleDays in seven days had a clear finish line, but everything that came after didn’t. I called it operating mode and said it was harder than the sprint that produced the app.

The thesis was right. I just didn’t really do it.

I opened App Store Connect recently and the dashboard made that clear. Two months in, MapleDays has around 250 first-time downloads, almost all from launch day. The chart is one cliff and then a flat line. A couple of paid users. A few meaningful updates shipped since launch. That is the whole shape.

The shape isn’t really about the product. It is about what I did with the two months between then and now.

I kept building. I stopped telling.

The product genuinely got better in those two months. Users wrote in with feedback. I made meaningful changes — not polish for its own sake, but real improvements that came from watching how people actually used the app. I was working on MapleDays. The code knows. The release notes know. App Store Connect knows.

What App Store Connect also knows is that nobody else knew. I shipped each of those updates without telling anyone they had shipped. The first version had a launch post. After that, silence. The product kept moving and the announcements didn’t.

So the framing I started with — that I had failed to do marketing — turned out to be wrong, or at least misleading. I had done the expensive half of marketing every time I shipped. Building something worth announcing is the costly part. The hours, the thinking, the willingness to cut scope and try again — all of that was real work, and all of it was already done. The part I kept skipping was telling anyone the work existed. That is the cheap half. A few sentences. A screenshot. A post in a few places. Twenty minutes at most.

This isn’t really a story about marketing being hard. It is a story about consistently throwing away the part that was easy.

The skip isn’t effort. It’s the mode switch.

Once I noticed the pattern, the obvious question was why. Why would I do the harder part repeatedly and skip the easier part repeatedly? Effort can’t be the answer; the math is backwards.

The honest answer is that announcing lives in a different mental mode than building. By the time a release was out, I was already inside the next one. The next bug, the next feature, the next branch. Whatever space in my head had been holding “tell people about this” had already been overwritten by “what should I build next.”

Builders don’t avoid distribution because it’s hard work. They avoid it because the context switch lands you in a medium you’re less fluent in. The IDE is right there. Writing a post about what you shipped requires opening a different app, choosing different words, thinking about a different audience. Each release ends in a small fork — go announce, or go build — and the path of least resistance is always back to the editor.

That isn’t a moral failure. It is a workflow problem. And I had not been thinking of it as a workflow problem, which is why it kept happening.

The warmest audience is already in the app.

The other thing I underweighted was who the announcements were even for.

When I think about “marketing,” I default to imagining new users — people who don’t know the app exists yet, somewhere out there, who need to be reached. That framing is mostly wrong for a product at this stage. The most valuable audience right now is the roughly 250 people who already downloaded MapleDays. They know what the app does. They have it on their phone. They have already decided I was worth one tap of attention.

Each meaningful update I shipped was a conversion moment for that group — a feature they had been waiting for, a reason to reopen the app, a reason to consider upgrading to premium. Silence on shipping isn’t only silence to the market. It is silence to the users I already had — and an existing user who upgrades is closer than a stranger who installs. The only way one of them finds out the app got better is if I tell them.

I had been thinking about marketing as reaching new people. It was also about telling the ones I already had, and I was ignoring the easier side of that too.

One platform, one moment.

The launch itself only happened on one platform. There were obvious next steps — repost over the following week in a few more places, find the communities where people already talk about Canadian residency and citizenship paperwork, show up in two or three places where the target audience actually gathers. None of those moves were individually hard. I did none of them.

The reason is the same as the reason I stopped announcing updates. Any of those moves would have meant treating distribution as a sustained activity, repeated across days and platforms, instead of a one-shot event tied to launch day. I treated it like a launch — one push, then done. The model in my head for distribution was the same model I have for shipping: do it once, do it well, move on. That model fits building. It does not fit telling people.

So “I didn’t market after day one” undersells what actually happened. I made one attempt, on one platform, on one day, and then defaulted back to building because building is the mode I know how to operate in.

Operating mode is two kinds of work, not one.

This is where the earlier post needs a small correction, not a retraction.

The Work After the Work said operating mode is a different kind of work from building, runs on a different clock, and demands a different skill set. All of that was true. What I missed is that operating mode has internal structure — some of its tasks still feel like building, and some don’t.

Shipping updates, fixing bugs, polishing edges, replying to user emails about specific bugs — these still feel like building. They live in the IDE, in TestFlight, in the submission flow. The mental mode is the same one I was already in. So I did them, and felt like I was operating.

Writing about what shipped, learning how to reach new audiences, showing up consistently in places that aren’t your own product — these don’t feel like building. They live in a different medium. So I skipped them, and the absence didn’t register as absence because the building-shaped operating tasks kept me busy enough to feel like work.

The earlier post named operating mode as a single thing. It is two things. I did the half that overlaps with what I already know how to do, and I skipped the half that doesn’t.

What I’m changing.

The temptation, looking at all of this, is to read the dashboard as a verdict on the product. Two paid users out of 250 downloads. It would be easy to conclude that MapleDays just isn’t compelling enough. But I don’t actually have the data for that conclusion. One launch, one platform, one moment. No second cohort to compare against. No sustained funnel to measure. The dashboard is thin not because the product failed but because I never gave it enough trials to be measured.

I don’t really know what MapleDays is yet. The reason I don’t is that I never let it be tested.

So the smallest credible change I can make is structural, not motivational. The diagnosis above was that announcing gets skipped because it requires a mode switch after the release is out, by which point I’m already inside the next build. The fix is to stop treating announcing as a separate task.

From here, announcing is part of shipping — written before I let myself open the next branch, posted in more than one place, treated as part of the same release as the code itself.

That isn’t a marketing campaign. It is a change to what shipping means in my own checklist. Not a promise to do more. A refusal to let the cheap half stay optional.