The Work After the Work

A few weeks ago I wrote about shipping MapleDays in seven days. That post ended with a line I believed at the time: “my part is done.”

That turned out to be only partially true. My part was done the way a rough draft is done. The shape existed. The core worked. But the product had not met a single real user yet, and real users have a way of rearranging what you thought you understood.

Building MapleDays was a focused sprint with a clear finish line. Everything after it — user feedback, monetization, marketing, App Store review cycles — runs on a completely different clock and demands a different skill set. The first week was about control. Everything since has been about listening.

Building mode has a finish line. Operating mode does not.

When I was building v1, the work had a natural structure. Scope the product, cut aggressively, ship. Every decision moved toward one goal: get this thing submitted. The constraints were tight, but that made them useful. I always knew what to do next.

After the app went live, that structure disappeared. There was no single goal anymore. There were users writing in with feedback. There were feature ideas that sounded reasonable. There were marketing questions I had no framework for. There were review cycles I could not speed up.

Building felt like steering. Operating feels more like a conversation that does not end. You are still making decisions, but they arrive on someone else’s schedule, and the feedback loop is slower and less predictable.

I think that shift caught me off guard because I had been optimizing for velocity. Ship fast, ship clean, move on. But “move on” is not really an option once the product is live and people are relying on it.

Users find the problems you did not build for

The most useful thing that happened after launch was that users started telling me things I could not have figured out on my own.

One early example: MapleDays originally required a “first entered Canada” date for permanent residents, and I made the PR date depend on it. You could not set a PR date earlier than your first entry date. That seemed logical to me, but it confused users who wanted to set their PR date first and fill in the entry date later. The constraint blocked them with no clear explanation.

So I removed the field entirely for PRs and citizens. Problem solved, I thought.

Then a user told me about Old Age Security. OAS applications require travel history even for citizens and permanent residents, and the form asks when you first entered Canada — if you were born outside the country. I looked up the actual OAS form and confirmed it. The field I had just removed was still needed, just not in the way I had originally built it.

So I added it back, but differently. It became an optional field, shared across all statuses, decoupled from the PR date constraint. That version is better than either of the previous two, and it only exists because of three rounds of feedback from people who actually use the app for things I had not anticipated.

That OAS discovery also changed how I think about the product’s audience. The core of MapleDays was always travel history — a clean record of trips in and out of Canada, managed in one place instead of scattered across spreadsheets, note apps, email confirmations, and half-remembered boarding passes. PR renewal and citizenship eligibility are results derived from that history, not the other way around. But I had been thinking about the audience narrowly: people actively navigating immigration. OAS showed me that older Canadians — people well past their immigration journey — still need the same ledger for entirely different paperwork. The travel history is the product. The use cases are broader than I expected.

The biggest surprise was about a design assumption I did not even realize I had made. Multiple users asked to manage travel records for their whole family in one place. I had designed the app around one person, one device, one ledger. Privacy felt like the obvious default — why would you put someone else’s immigration data on your phone?

But that is not how families work. A lot of households have one person who handles the paperwork for everyone. They are already tracking trips for their spouse, their parents, their kids. They do not want to juggle four phones. They want one place to manage it all.

That feedback did not just suggest a new feature. It revealed a whole usage pattern I had not considered, and it ended up reshaping how I think about the product’s premium tier — which I had not planned that way at all.

The premium split came from users, not a spreadsheet

Before launch, I had a vague idea that iCloud sync would be the premium upgrade. That was it. I had not thought much harder about monetization because it felt like a problem for later.

Then users handed me a much clearer answer. The family management pattern — one person tracking trips for a household — was not just a feature request. It was a natural dividing line between two kinds of users. Most people need MapleDays for themselves. Some need it for everyone they are responsible for. That second group is doing meaningfully more with the product, and paying for that feels fair.

What surprised me about that process is that I did not sit down and design a monetization strategy. It emerged. Users showed me how they use the app differently from each other, and the premium boundary followed from that difference. I want MapleDays to stay free for the majority of its users — the core product should never cost anything. Premium is for the heavier use case, and the revenue is mostly about keeping the app maintained and developed over time.

I think that is probably how monetization should work for a small app. Not as a pricing exercise you do before launch, but as a decision that gets clearer once you see how real people actually use the product.

Marketing with no audience

This is the part I am least qualified to write about, which is probably why it matters.

MapleDays solves a real problem for a specific group of people. But those people do not know the app exists, and I do not have an audience to announce it to. There is no mailing list, no social following large enough to matter, no existing distribution channel.

I have tried a few things: posting in relevant communities, reaching out to people who write about Canadian immigration topics, making the marketing site clearer, improving App Store keywords. Some of it has generated a trickle of installs. None of it has felt like a repeatable engine.

I do not think I have cracked this yet. What I have learned is that marketing a solo app is a fundamentally different skill from building one, and it rewards consistency more than cleverness. The temptation is to treat it like a launch — one big push, then back to building. But it is really more like maintenance. You have to keep showing up, keep finding the right people, keep explaining why the product matters.

That is still a work in progress for me.

Patience is a product skill

One thing I underestimated is how much of post-launch work is just waiting.

Waiting for App Store review. Waiting for the IAP review on top of that. Waiting for user feedback to accumulate enough to see patterns. Waiting for installs to grow. There is always a gap between submitting something and seeing the result, and during that gap the temptation is strong to start something new instead of finishing what is in front of you.

I think patience is a product skill in the same way that cutting scope is a product skill. It does not feel productive, but it is often the right move. The product needs time to meet its users, and you need time to learn from what they tell you.

What I know now that I did not know at the end of that first week

The shipping post was about learning to cut a product down to its center. That lesson held up. But the post-launch phase taught me something the build sprint could not: what happens when the product meets people who did not help design it.

Building MapleDays was a conversation with myself. I decided what mattered, I cut what did not, and I shipped something I believed in. Operating MapleDays is a conversation with users. That is a harder mode to be good at, because you cannot plan your way through it. You have to stay open to being wrong about things you were confident about, and willing to change the product in directions you did not anticipate.

I think the hardest part of this phase is accepting that the product is no longer entirely yours. You built the center, but users are shaping the edges. The version of MapleDays that exists today is better than the one I submitted at the end of that first week, and most of that improvement came from people who use it telling me things I could not have figured out alone.

That is probably the real work after the work. Not just fixing bugs and adding features, but learning to hold the product loosely enough that it can become what it needs to be.