AI Accountability Platform

The situation

The product was a subscription accountability app doing $12K a month. Members signed up motivated, logged a few sessions, and then a good share of them stopped. The drop-off clustered around day three.

The founder was the retention system. He noticed who had gone quiet, wrote the reminder himself, and sent it. That works at small numbers and quietly fails as the list grows.

The second leak was on the billing side rather than the behaviour side. Half of all trials lapsed before the first billing cycle ever ran, so those members were lost at the payment layer, where a motivational text never reaches.

What was broken

• Silence was invisible until the subscription had already gone, so intervention always arrived late.
• Every reminder was written and sent by hand, which capped retention work at whatever the founder had time for.
• A missed session and a long stretch of inactivity were treated the same way, because there was no mechanism to treat them differently.
• Trials lapsed before first billing with nothing watching the subscription lifecycle.
• Nobody could tell which nudge had actually moved a member, because no touches were logged.

Constraints

• The retention work had to run on the member's real behaviour, not on a fixed drip, because the app already knew who was active.
• Anything sending SMS had to be opt-out aware, since a retention system that keeps texting an unsubscribed member is a compliance problem.
• Billing state lives in Stripe and behaviour state lives in the CRM, so the two paths had to work independently rather than as one funnel.
• The founder needed to see and tune what the system was doing, not just trust it.

What I built

I built two independent entry paths into one retention system. The public version of this build reads as a single funnel. It is actually two, and that is the design.

The behaviour path

Three signals start the behavioural side: a member going silent, a scheduled session not completed, and a longer stretch of low engagement across the account. Each is a distinct trigger, because a missed session is a different problem from a member who has stopped opening the app.

Decision AI reads the member's current state and classifies what kind of intervention they need, then branches them into a crisis-recovery track or a motivational track. That replaces the founder sorting members by hand. The two tracks are first-class destinations in the system, and I am not going to describe internals of them here that the build record does not support.

The cadence tiers

The chosen track and the signal that fired decide the send rhythm: daily, hourly, or instant. One cadence for every situation is either ignored or experienced as spam, so the tier is picked rather than fixed. If the member stays silent, the cadence tightens rather than the sequence simply ending.

The billing path

Stripe lifecycle triggers watch for failing and lapsing trials and attempt recovery before the first billing cycle closes the member out. This path bypasses the AI branch entirely. It exists because the members lost here were never going to be saved by a behavioural nudge, and nothing was watching them.

Suppression and logging

Two governance components sit under both paths. An opt-out guard stops every further send for a member who has opted out. A touchpoint log writes every touch to a record the founder can read and tune against. Neither is a feature anyone asks for, and both are the reason the system can be improved rather than merely trusted.

Edge cases and failure handling

• A member who opted out: the guard stops every subsequent send, including the ones a retention sequence would otherwise consider urgent.
• A member who stays silent through the first nudge: the cadence escalates through the tier selector instead of the sequence quietly ending.
• A trial that is about to lapse: it is caught on the payment side, where messaging never reached, rather than being counted as churn afterwards.
• A missed session versus general inactivity: each fires its own trigger, so the member is classified on what actually happened.
• A member who comes back: the outcome is written to the touch log, which is what makes it possible to tell which nudge moved them.

How I verified it

Honest answer: the verification evidence for this build is thin. There is no QA suite, no test count and no read-back record in the material I hold for it, and I am not going to invent one. What exists is the touchpoint log. It was built in precisely so the founder could see every send and its result, and tune the flows against real member behaviour instead of a hunch.

What changed

+40% member re-engagement after going silent, measured. Sessions completed doubled. The founder reclaimed roughly 15 hours a week that had been going into manual reminders.

That last number is the one I would lead with. The percentages describe members behaving differently. The hours describe work that no longer exists, which is a different and more durable kind of result. The billing path also gives the business something it did not have before: lapsing trials get caught before the first cycle rather than discovered after it.