Pocket Ledger v2.0 Launch Sync

Pocket Ledger v2.0 is being prepared for a coordinated mobile launch with Priya (PM), Marco (engineering lead), Dana (design), Sam (support), and Lee (marketing) aligned on the plan. The release date moved from Mar 3 to Mar 17 to create a buffer after the team saw that the last iOS review took 6 days. Unlike the previous launch, Android will go out the same day as iOS, not in a staggered rollout, because the staggered approach last time led to 2x support tickets and user confusion. This launch also includes pricing changes, support preparation, and marketing assets that need to be ready before the press embargo lifts on Mar 17 at 9am ET. The detailed dates and ownership are split across Release Timeline and Freeze, Support Readiness, and Marketing and Comms.

The release calendar is anchored by a feature freeze and a launch-day review window. The team wants enough time to stabilize the build after freeze, verify the remaining crash fixes, and avoid another iOS review delay. Marco owns the branch cut, which is a key control point because no feature work should land after freeze except approved bug fixes. The plan also includes a go/no-go meeting on Mar 14, giving the team three days to resolve anything blocking ship. That meeting depends on the quality and readiness thresholds described in Beta Quality and Launch Criteria and the operational checklist in Decisions and Action Items.

The feature freeze is Feb 28. After that point, only P0/P1 bug fixes are allowed, so the release branch should remain stable and focused on issue closure rather than feature work. Marco owns the branch cut, which makes him responsible for creating the release line and keeping it clean for launch. A practical implication is that any unfinished feature work must either be deferred or treated as post-launch scope, not quietly slipped in after freeze. This matters because the team is already carrying known issues, including a CSV import crash and a dark-mode label problem, and needs a narrow lane for fixes before the launch review in Beta Quality and Launch Criteria.

The target launch moved from Mar 3 to Mar 17 to add buffer after the previous iOS review consumed 6 days. The team decided to launch both platforms on the same day, rather than stagger iOS and Android. The reason for changing the rollout shape is explicit: the staggered launch last time caused confusion and produced twice as many support tickets. The new approach increases coordination pressure, especially for support and marketing, but it should reduce user confusion when the app becomes available. If iOS review rejects the app again, the team has already identified a fallback risk of slipping by a week, which is tracked in Risks and Mitigations.

The current beta is the main signal for whether the app is ready to ship. There are 400 testers on TestFlight and 250 on the Play internal track, and the current crash-free rate is 99.1%. The team’s target is at least 99.5% crash-free before launch, which is also part of the formal go/no-go criteria. The highest-priority crash is in CSV import for files larger than 5 MB, and the second major issue is unreadable dark-mode chart labels on small Android devices. These issues are directly tied to the work in Release Timeline and Freeze and the launch gate in Decisions and Action Items.

The beta program spans two channels: 400 TestFlight testers for iOS and 250 Play internal-track testers for Android. The current crash-free rate is 99.1%, so the build is close but still below the desired threshold of 99.5%. That 0.4-point gap is important because the team has tied launch readiness to a measurable target rather than a subjective feel. In practice, that means a few crash-producing sessions can still block the release if they pull the rate under target. The metric is also part of the go/no-go meeting on Mar 14, so it should be watched closely before that date.

The top crash is CSV import on files larger than 5 MB. Marco said the fix is already in progress and gave an ETA of Friday. The second issue is that dark mode chart labels are unreadable on small Android phones; Dana will address this by introducing new color tokens. Both defects matter because they affect core flows: importing data and reading budgets or charts. The team should verify the fixes on the same devices and file sizes that exposed the bugs, rather than assuming a code-only fix is enough. A regression here would directly affect launch criteria in Decisions and Action Items and could trigger a slip under Risks and Mitigations.

Pocket Ledger’s pricing update keeps the free tier intact while changing the Plus plan and delaying family-plan work. The free tier remains limited to 3 accounts and 6 months of history, so existing free users do not lose access to their current baseline. The Plus plan increases from $3.99 to $4.99 per month, and the annual price changes from $34.99 to $39.99. Existing subscribers are grandfathered for 12 months, which means they keep the old price for that period rather than being switched immediately. The family plan is postponed to v2.1 because there is not enough time to test shared budgets safely before this release. Lee owns the pricing email, which should explain the change clearly and avoid confusion with the launch messaging in Marketing and Comms.

Support preparation is focused on the specific questions users are likely to ask after launch. Sam identified several new help-center articles that need to be published, plus canned responses for the most common problems. The team also wants an in-app "what's new" screen so users do not email support asking where the old reports tab went. Dana said that screen is feasible and would take 2 days. Support readiness is not just documentation work; it is part of reducing ticket volume during the first week, especially since the team already knows the previous staggered rollout caused confusion. The work here ties directly into Release Timeline and Freeze and the launch-week staffing plan below.

Sam needs new help-center articles for bank sync re-auth, CSV import, new budgets screen, and export to PDF. In addition, the team wants macros for the top 5 expected questions, with a draft due by Mar 10. The macro set should make it faster to respond to repetitive launch questions and keep response quality consistent across the support team. Because bank sync and CSV import are both mentioned in the known-issues list, these articles are especially important for deflecting ticket spikes if users hit edge cases. The articles should be ready before launch week so agents are not writing answers from scratch during the busiest period.

Sam asked for an in-app "what's new" screen to explain the UI changes, especially the removal of the old reports tab. Dana said it is doable in 2 days, so it appears to be a low-risk support aid compared with larger feature work. For launch week, the on-call plan is Marco plus one engineer, and the team will use Slack channel #launch-war-room to coordinate issues. That setup creates a clear escalation path for defects discovered after release and helps keep support, engineering, and PM aligned. It also complements the launch criteria in Decisions and Action Items by giving the team a place to act quickly if a blocker appears.

Marketing deliverables are focused on explaining what changed and making the app store presence match the new interface. Lee needs to produce a blog post, a changelog, and 3 short videos covering budgets, bank sync, and export. App Store screenshots also need to be redone for the new UI, and Dana owns those by Mar 7. The launch messaging is tied to the press embargo, which lifts on Mar 17 at 9am ET. One open question is whether to submit the launch to Product Hunt; Priya’s condition is that they should do it only if the crash-free rate reaches 99.5%. Those decisions are connected to the pricing email and launch sequencing in Pricing Changes and Release Timeline and Freeze.

The launch plan includes several known risks that could affect timing or scope. One risk is a possible Plaid API rate-limit change in March, which Marco is checking because it could break bank sync for larger accounts. Another is a repeat of the previous iOS review problem: last time the app was rejected for a missing privacy label for an analytics SDK. The team wants to double-check privacy labels to avoid a one-week slip. There is also a localization gap: es and de strings are 85% done, while fr is only 40% done. Because of that, French may ship in 2.0.1 instead of 2.0. The risks are operational, not hypothetical, so each one has a named owner or fallback path in the action list and launch gates.

Marco is checking whether Plaid API rate-limit changes in March will affect bank sync, especially for big accounts. If the rate limits tighten, the app could experience sync failures or degraded behavior in a core feature. Because bank sync is important enough to require its own help-center article, this dependency should be treated as a launch risk rather than a minor backend detail. The practical mitigation is to confirm current limits and model worst-case behavior before launch. If the issue turns out to be real, the team may need to communicate scope or behavior changes through support and marketing materials in Support Readiness.

The team is also guarding against another iOS review rejection, since the last one was caused by a missing privacy label for an analytics SDK. The instruction is explicit: double check privacy labels. If review fails again, the release could slip by a week. Localization adds a separate timing problem: es and de are 85% complete, but fr is only 40% complete, so French may be deferred to 2.0.1 if it is not finished in time. That decision keeps the launch from being blocked by a single lagging locale while still preserving a path to ship the missing language later.

The team made four formal decisions and assigned follow-up work to specific owners. The launch date is locked for Mar 17 on both platforms. The price increase applies only to new subscribers, while existing subscribers are grandfathered for 12 months. The family plan is moved to v2.1 because there is not enough time to test shared budgets. The final gate is the Mar 14 go/no-go meeting, which depends on crash-free quality, the absence of open P0s, and the help center being live. These decisions connect the technical, support, and marketing work described throughout Beta Quality and Launch Criteria, Support Readiness, and Marketing and Comms.

The go/no-go meeting is scheduled for Mar 14. The criteria are: crash-free rate >= 99.5%, no open P0s, and help center live. This creates a hard operational gate rather than an informal check-in. If any one of those conditions is not met, the team should treat launch readiness as incomplete and decide whether to delay or narrow scope. The checklist is intentionally simple because it needs to be actionable in a meeting, not debated at length. It also gives every owner a concrete target to verify before the meeting in Release Timeline and Freeze.

The action list assigns clear owners and deadlines. Marco will fix the CSV crash by Friday, check Plaid limits, and handle the branch cut on Feb 28. Dana will update the dark-mode color tokens, build the in-app "what's new" screen, and redo screenshots by Mar 7. Sam will create help-center content and macros by Mar 10. Lee will draft the pricing email, prepare the blog and videos, and decide on Product Hunt by Mar 12. Priya will write the go/no-go doc and run the Mar 14 meeting. These assignments should be tracked against the dates because several of them feed directly into the launch gate and embargo timing.