The GainFrame Roadmap for the Next 90 Days

I’m spending the next 90 days trying to reduce realized paid churn by 30–50% and improve paid retention by about 25%. This GainFrame roadmap starts there. I still need to establish the exact baseline, define the retention window, and separate somebody turning off renewal from a subscription reaching its expiration date.

The public numbers I have are still rough. In June, 27% of GainFrame installers returned during week one, up from 20.1% in May. Week-four retention stayed between 8% and 12%. I wrote about that in my last retention update.

That post also said the app gets good on check-in five. I need to correct the certainty in that sentence. GainFrame is designed to unlock better comparisons and trends after several check-ins, and I want that history to become the reason people stay. I do not have data proving that people value the accumulated history or that it improves paid retention yet.

That is the point of this roadmap. I have a clear picture of the product I want to build. The first part of the work is finding out which parts are true.

What is the GainFrame roadmap trying to build?

GainFrame is a progress-photo tracker first. The camera roll is good at storing photos and bad at showing what changed across three months, six months, or a year. GainFrame organizes the photos by pose and date, lines them up for comparison, and attaches useful context to the day.

The second part is physique coaching. The app should help you see changes you may miss in the mirror, explain how confident it is that the change is real, and show which training or recovery signals may be related. The measurements are AI estimates. They need to be stable and understandable before they can carry the weight I want to put on them.

I’m designing for two groups. A beginner needs a clear result and an obvious next step. An experienced lifter or bodybuilder may want the workout, weight, recovery data, confidence, and muscle-level detail behind it.

The rule is simple by default, detailed on demand. The four tabs each get one job:

• Today: What should I capture or act on now?
• Photos: Where is my organized visual history?
• Compare: What changed between two check-ins?
• Trends: What is changing across several weeks?

Coach supports those jobs when a check-in creates a question. It should not feel like a separate product competing for attention.

What do I know, and what am I still guessing?

I know paid retention is the priority. I know I want a couple of check-ins a week, with one to three total visits. I know the first completed check-in is the early action I care about. I also know the first session has to produce something personal and impressive because a new account has no history to analyze.

Most of the proposed explanations for churn are still guesses.

• I suspect photo upload is the largest onboarding drop because people are understandably uncomfortable sharing a physique photo.
• I suspect unstable scores and body-fat estimates damage trust.
• I suspect price and insufficient recurring value are major cancellation reasons.
• I suspect experienced lifters retain better because they already understand the data.
• I hope attached workout and recovery history becomes useful after several weeks.
• I have no clean evidence that streaks, rewards, notifications, Coach, Trends, or monthly Chapters improve retention.

There are older analytics reports in the repository, including some I wrote myself. I’m using them to find event names and implementation history. I’m rerunning the analysis from the current raw data before I let any of their conclusions drive a large build.

What am I doing first?

The first package is an analytics and subscription audit across PostHog and RevenueCat. It starts with identity because every cohort is suspect if an anonymous install, a signed-in person, and a RevenueCat subscriber can look like three different people.

I need one defensible answer for each of these:

• Where onboarding and the first photo flow lose people.
• Which first-week actions are associated with paid retention.
• When paid entitlements expire and revenue is really lost.
• What people do during the seven days before cancellation.
• Whether people keep using the product after turning off renewal.
• Which features were eligible, shown, tapped, and used again.
• Whether cancellation surveys are reaching the people they are supposed to reach.

App opens are too weak to count as the retained behavior. A useful retention definition should include a completed check-in, comparison, relevant trend review, or another action tied to the product’s core job.

How will a check-in become more useful?

The AI result has to become more trustworthy before I build a bigger story around it. I’m going to run repeated tests with the same image and controlled changes to lighting, crop, angle, scale, and pose. That gives me a variance benchmark for GainFrame Score, body-fat estimates, and the smaller physique dimensions.

The product can then distinguish a physical trend from a capture-quality problem. A result may say the photos are highly comparable, the change is likely real, or one more check-in is needed before calling it a trend. That is more useful than showing a precise number with no explanation.

The second piece is durable context. GainFrame already attaches some weight and workout information to photos. I want one versioned snapshot for each check-in day containing the smallest useful set of derived data: weight, workout summary, recent training load, sleep, HRV relative to the person’s baseline, resting heart rate, recovery availability, and optional notes about soreness, stress, or energy.

I do not want to copy a person’s entire HealthKit history into the app. Each field needs a user-facing reason to exist, plus clear deletion and source-revocation behavior. The payoff is a historical record that still explains what was happening on that day if a data permission changes later.

The question I want GainFrame to answer is very concrete: this is what you looked like, what you were doing, how you were recovering, and what changed afterward.

What will change in the first session?

I’m not interested in chopping onboarding in half just to report fewer screens. The first session should prove the product promise before asking somebody to form a habit.

The working idea is a Baseline Brief that packages the existing pieces into one result:

• The person’s starting point.
• What GainFrame notices in the photo.
• Estimated body composition with confidence and limitations.
• Visible strengths and areas to watch.
• Capture quality and photo comparability.
• A clearly labeled Future Me scenario.
• A Coach interpretation grounded in the result.
• One or two signals GainFrame will monitor.
• The next useful check-in date and what it could confirm.

If somebody has an older photo, the app can offer a privacy-respectful way to create a real comparison during the same session. If they only have one photo, the Baseline Brief still needs to stand on its own.

I also decided against the early subscription disclosure I had mocked up. The useful disclosure at the photo step is why the image is needed, what it produces, how it is processed, how it is stored, and how to delete it. Subscription terms belong with the subscription decision.

What is the social bet?

The working concept is called GainFrame Timeprint. It is not built. I’m going to mock up three visual directions and test whether people understand them before committing to the full engineering work.

The basic format is a short 9:16 visual story for Instagram or TikTok. It pose-locks a baseline and current check-in, shows time passing, highlights a credible area of change, adds one personalized AI insight, and includes the timeframe and check-in count behind the result.

The share needs to work when the physical change is subtle. Consistency, posture, proportion, a confirmed trend, or an emerging change can still be interesting. A dramatic transformation cannot be the entry requirement.

Privacy is part of the format. The export should support original photos, face blur, background removal, and a stylized AI representation for someone who does not want their raw body photo on a public account. The default should be safe to share with minimal editing.

The response I’m looking for is straightforward: “I want to run that scan.” If the mockups only earn “nice before-and-after,” I have not found the feature yet.

How will I decide what ships?

Each package has a decision gate.

• I will quantify score variance before marketing trajectory-based projections as accurate.
• I will measure feature exposure before ranking a feature by taps.
• I will separate correlation from causation when retained people use a feature more often.
• I will test three Timeprint directions before building the complete generator and editor.
• I will wait for fresh cancellation reasons before choosing a discount, pause, recalibration, or habit-restoration flow.
• I will ship each change so it can be measured and rolled back on its own.

This is also how I plan to keep the UI simpler. A card, prompt, or feature earns a prominent place by helping someone capture, compare, interpret, return, or share. Everything else can move deeper or leave the default path.

What counts as success?

The business targets are a 30–50% reduction in realized paid churn and roughly a 25% improvement in paid retention. I will publish the exact definitions and baselines after the audit rather than reverse-engineering a flattering metric at the end.

The nearer signals are easier to observe: more completed baseline check-ins, more second comparable check-ins, lower score variance, more people accepting a specific next-check-in action, and more evidence-driven Coach or Trends visits between photos.

For Timeprint, an export count is only the beginning. I care whether somebody sees one, starts their own scan, completes a baseline, and becomes the kind of customer who stays.

This plan will probably change. That is fine. The first version of the plan was built from my assumptions, and the first phase is designed to remove as many of them as possible.

If you use GainFrame, I’d like to know where the value becomes clear for you, where you stop trusting it, and what would make the next check-in feel worth doing. Those answers are more useful to me right now than another list of feature requests.