Shipping MapleDays in 7 Days

On March 5, 2026, I started MapleDays. Six days later, I submitted version 1.0 for App Review.

MapleDays is a local-first iPhone app for tracking trips outside Canada and turning them into a usable physical-presence ledger. For permanent residents, that means PR renewal planning and citizenship timing. For temporary residents, it means a cleaner renewal-oriented travel record. For citizens, it means a simple travel archive for personal history, future paperwork, and official-history cross-checks, without pretending to be a full immigration platform.

The interesting part is not that it happened fast. It is that it only happened once I cut the product down to one clear job.

The week itself was pretty compressed: first a prototype and rules engine, then a product reset that cut the app back to three screens, then the less glamorous back half of the week spent on tests, screenshots, support pages, App Store copy, and submission. That arc matters more than the calendar.

The problem was real enough to matter

Physical-presence tracking in Canada is one of those problems that is both important and annoying.

If you are trying to stay on top of PR residency, think ahead about citizenship timing, manage temporary-resident renewal planning, or just keep a reliable travel record, the raw information you need is pretty simple: when you left Canada, when you came back, and how that affects your days.

But the actual experience of tracking it is messy. People end up with notes app entries, spreadsheets, calendar hacks, screenshots, or half-remembered trip histories spread across email and airline apps. The stakes are high enough that you do not want to be sloppy, but the tooling is often either too manual, too broad, or not very trustworthy.

I wanted something I would actually trust myself: not another spreadsheet, not a bloated case tracker, just a clean trip ledger that stays on-device, recalculates automatically, and helps answer the question people actually care about. Am I on track?

That framing mattered. MapleDays was never supposed to be an official Government of Canada tool or a replacement for IRCC guidance. It was supposed to be a clean personal system.

My first instinct was to build too much

The funny part is that I knew this, and still started by drifting broader.

Very early on, MapleDays had more moving parts than the final product needed. There was onboarding. There were reminder flows. There was a forecast simulator. There was a timeline tracker. There were extra product branches that made sense individually, but together started pushing the app toward a general immigration manager.

That is a pattern I fall into pretty easily. When a problem has a lot of adjacent pain points, it is tempting to treat every adjacent pain point as part of v1. It feels ambitious. It also feels productive because there is always one more useful thing to add.

But that kind of ambition usually makes the product worse before it makes it better.

The more features I added, the harder the app became to explain. The data model got fuzzier. The UI had more competing priorities. The question stopped being “what is MapleDays?” and started becoming “what else should MapleDays do?”

That is usually a sign that the center of the product is weak.

The cut that made the app work

The turning point was a product reset:

MapleDays is a Canada physical-presence ledger.

That one sentence cleared up almost everything.

Trips outside Canada became the core user input. Days in Canada became derived output. PR readiness became the primary value, but the same ledger still had to stay useful for temporary residents and citizens too. Citizenship timing stayed in the app as a secondary layer built on top of that ledger. Everything else had to justify itself against that loop.

That also meant being explicit about what did not make v1. No document vault. No case tracker. No milestone timeline. No broad reminder system. Not because those are bad ideas, but because they weaken the center of the product.

Once I accepted that, a lot of decisions got easier.

The app shrank to three screens: Dashboard, Trips, and Settings.

The dashboard became PR-first for permanent residents instead of trying to be a generic home for every possible workflow. Temporary residents got a narrower renewal-oriented view. Citizens got a ledger-only travel archive instead of a dashboard that implied more certainty than the product could safely support.

The settings flow got smaller too. It stopped trying to feel like a whole setup wizard and became a compact place for the few inputs that actually matter. The trips screen became the center of gravity, which is where it should have been from the start.

This is the part I want to carry into every future app I build. Most products do not need more features. They need a sharper center. If you can define one core loop clearly enough, the right features become obvious and the wrong ones start looking expensive.

The engineering got easier once the product got smaller

Once the product stopped trying to be everything, the technical choices got cleaner too.

I kept the rules logic in a separate domain package instead of burying it in SwiftUI views. That made it easier to test the parts that actually carry trust: rolling windows, trip boundaries, same-day trips, future trips affecting projections but not today’s totals, and pre-PR credit edge cases.

I stored user-entered dates as normalized day values instead of treating them like arbitrary timestamps. That sounds minor until you remember how many date bugs come from timezone assumptions. For a product built around calendar days, “close enough” is not good enough.

I treated the trip records and profile data as the source of truth, then cached dashboard snapshots as derived data. That kept the app fast without making the cache itself authoritative. It also made migration and cleanup logic much easier to reason about.

I ended up spending a meaningful amount of time on things that are not flashy at all: integrity cleanup, migration from older prototype data, validation around trip overlaps, keeping projections current without blocking the UI, and writing tests for policy-shaped edge cases.

That is probably the bigger lesson. A lot of the hard engineering in small apps is not about cleverness. It is about removing ambiguity. Once the product had a sharper center, the code had fewer opportunities to lie.

Shipping was not the coding part

By the end of the week, I had a working app: trip CRUD, status-aware dashboards for permanent residents, temporary residents, and citizens, export, PR card expiry planning, a calmer visual system, tests, and the rest of the product core.

But that still was not “shipped.”

Shipping also meant doing all the work around the app:

• App Store copy
• privacy policy
• support page
• screenshot sets for iPhone and iPad
• app icon iterations
• review notes
• metadata and release checklist
• the marketing site and legal pages for mapledays.app

That work is easy to postpone because it does not feel like building. It feels administrative. But it is actually where a project crosses the line from “code that works on my machine” to “something another person can install and trust.”

I am trying to get better at respecting that part of the process. A product is not half-built just because the code is good. If the store page, support surface, privacy posture, and release details are missing, it is not done.

What building MapleDays in a week taught me

The big lesson is that speed came from constraint. The app fit into a week because I stopped asking it to be many things at once. It also reinforced something I want to keep applying to future projects: “source of truth” is a product decision before it is an engineering decision. For MapleDays, the trip ledger shaped everything else, from the interface to the calculations to the export story. Local-first helped too. Without accounts, analytics, or a backend in the way, the app was easier to explain, easier to trust, and easier to ship. And because the core stayed small, version 1.0 could feel complete without pretending to be final.

How I want to build apps now

I do not think the main takeaway from MapleDays is “try to build everything in seven days.” It is this playbook:

• start with one core job
• define a clear source of truth
• separate trust-heavy logic from UI
• cut adjacent features aggressively
• finish the unglamorous shipping work too

MapleDays is not live yet. Apple still has to approve it. But my part is done, and I am happy with what “done” included: not just code, but a product shape, a technical foundation, and a real submission.

There is still a lot I want to build on top of this v1. But I wanted the first version to be a complete core product before I earned the right to expand it.

MapleDays taught me that the goal is not to build apps faster. It is to build them small enough, clear enough, and complete enough that they can actually ship.