More Reminders Were Not the Answer: Lifecycle Messages With Restraint

A person can revisit an app several times without understanding its core flow. Calling them “engaged” because requests reached the backend hides that problem. Calling them “inactive” because they have not logged a task also misses that they are trying to use the product.

The engagement analysis makes this distinction useful for design. A never-activated person needs a clear first action and an explanation of its value. Someone with an established routine may need help resuming it. The same reminder copy is unlikely to fit both. Segment definitions should reflect the task, not merely how many days have passed since signup.

If onboarding creates a measurement record, an eligibility query that checks for any health record may decide the person has already started a habit. Another query may interpret the same record as proof that they deserve a momentum message. Both can be wrong for the intended product question.

Define the meaningful action consistently across jobs. A shared definition reduces the chance that one system congratulates someone while another tells them they have never begun. The purpose is not to expose private query logic. It is to explain that lifecycle targeting depends on the same careful metric definitions as a founder’s dashboard.

Email can reach someone without a push token, but that does not automatically make every push campaign suitable for email. The channel changes expectations, timing and the cost of interruption. A weekly review, a transactional invitation and a generic engagement nudge serve different purposes.

I would define why the message is useful, when it stops and which event makes it irrelevant. If the person already completed onboarding, a delayed reminder should not continue merely because it was queued earlier. Channel expansion should preserve the reason for the message rather than multiply an already confusing experience.

The outbound-email design moves blocking transport work away from asynchronous request handlers into a database-backed queue. That gives the application a place to track attempts and terminal outcomes, while keeping a slow mail connection out of the immediate user request.

This is a sensible engineering boundary for the documented scale, but it does not decide whether a message should exist. A perfectly drained queue can send irrelevant emails. Keep the eligibility policy separate enough to review. “We built retries” and “the reminder helps users” are different claims requiring different evidence.

Queued means stored for processing. Transport accepted means a mail service accepted the attempt. Delivered, opened and acted upon require other evidence and may be imperfectly observable. The UI and dashboard should not flatten those stages into “sent successfully, therefore engaged.”

A worker also needs a policy for transient and permanent failure. Retrying a temporarily unavailable connection is different from repeatedly targeting an invalid recipient. Recovery after a crash needs attention to ambiguous external effects. A database queue does not automatically make email exactly-once, and a public write-up should not promise that guarantee casually.

Scroll the table horizontally to see all columns.

The reminder records describe limited sequences rather than an endless loop. A cap is useful because the system should not interpret silence as permission to keep escalating indefinitely. Completion, deletion, changed eligibility and channel preferences can all make a queued message inappropriate.

I would check eligibility as close to sending as practical and define what happens to already queued work when the account state changes. The exact strategy depends on the workflow. The principle is that the message exists to support a task, not to satisfy the schedule of an automated campaign.

A push that says “log your meal” but opens a generic dashboard creates extra work. A deep link can help, provided the destination handles cold start, authentication and missing state. The existing Expo article covers the mobile side of that boundary.

The destination should remain useful if the task is already complete or the underlying record changed. A brittle link can turn a well-targeted reminder into confusion. I would test the whole experience from notification tap to meaningful action, not stop at a provider receipt or a screenshot of the notification itself.

A report can show whether recipients returned or completed onboarding after a message. That association is useful, but people might have completed the task anyway. For causal claims, use an appropriate controlled comparison and account for timing and eligibility.

I would also inspect adverse signals such as disabling notifications or repeated visits without completion, where legitimately measurable. A reminder that increases opens while leaving people frustrated may not be a success. The product should optimise for useful outcomes and trust, rather than whichever interaction count moves first.

Before enabling a sequence, I would also simulate an account completing the task between enqueue and delivery. The expected result should be explicit: suppress an obsolete message or send only content that remains relevant. That one transition tests whether the campaign follows the person’s current state rather than an outdated snapshot.

Should every inactive person receive the same campaign? No. First identify whether they ever reached value, what action is missing and whether the message can help them take it.

Is AI-written copy automatically better? It may be more contextual, but relevance, factual grounding and timing still matter. A personalised wrong message can feel worse than a generic one.

What would I improve before adding another reminder? Inspect the first-use state, the destination action and the definition of completion. If the interface does not help a returning person succeed, another interruption may simply repeat the problem.