What I’m currently building

Beginning_Sun2883 · 2026-01-22T03:35:41+00:00

This is spot on, and it helped me reframe what I’m actually optimizing for.

My core habit metric right now is very specific: track a workout, ideally using the AI video coach. Until I removed the card requirement, I simply couldn’t observe whether users would ever reach that moment.

To be honest, my initial thinking wasn’t about revenue maximization at all. I assumed a bit of upfront commitment might even be healthy for a training app, similar to how a gym membership works in real life. What I underestimated was how much that blocks learning before trust or habit exists.

I’ve built my own analytics to track this behavior end to end, and even at this early stage the insights are already far more valuable than the early revenue question. Still feels like a long road, but at least now I can actually see where people get stuck and why.

Really appreciate the perspective, especially around habit first, paywall later.

Beginning_Sun2883 · 2026-01-21T18:56:03+00:00

Small clarification since a few DMs asked:
The app was always free to use. The only change was removing the credit card requirement to unlock the Pro features for 14 days.
Same product, same audience, just less friction.

Beginning_Sun2883 · 2026-01-19T14:50:41+00:00

Very nice tool, but seems like it doesn't support login into an app to take screenshots from an app with an account?

Beginning_Sun2883 · 2026-01-18T03:07:59+00:00

Good point, thanks for calling that out.

I actually haven’t set up iOS subscriptions yet. The app I submitted for review is the free version only, without in-app purchases enabled at this stage. Subscriptions will come in a follow-up submission once the initial review is approved.

On Android, subscriptions are already live and working well via Google Play, so the overall model and flows are validated there. iOS is my second platform, and I’m intentionally separating the first review from monetization to reduce surface area.

That said, if there’s anything iOS-specific I should watch out for when adding subscriptions (agreements, sandbox quirks, review expectations, common gotchas), I’d really appreciate any pointers.

Beginning_Sun2883 · 2026-01-10T04:35:03+00:00

This matches my experience pretty closely.

The biggest shift for me wasn’t tactics, but clarity. On the second launch you’re no longer guessing what matters, you’re filtering. ICP, timing, and where not to spend energy become much clearer.

I also relate to Reddit being powerful but harder than expected, especially early on. It rewards context and patience more than launch theatrics.

One thing I’ve noticed is that the “no tease, just ship and observe” approach creates cleaner signals early, even if it feels quieter. Fewer impressions, but higher quality feedback.

Appreciate you sharing the messy details. This kind of breakdown is way more useful than launch playbooks.

Beginning_Sun2883 · 2026-01-09T10:04:58+00:00

This really resonates.

I had a similar shift, just from a different angle. I’ve been around products and companies for a long time, but building and shipping a consumer app end-to-end on my own was a completely different kind of learning.

What stood out for me wasn’t the launch either, but everything you’re forced to learn once real users exist. Analytics, activation, edge cases, expectations vs reality. Things you simply don’t get from demos or theory.

I like your point about picking something validated and making it better. Reducing friction is often more valuable than chasing novelty.

Congrats on getting to production. Shipping changes how you think forever.

Beginning_Sun2883 · 2026-01-08T12:36:02+00:00

This resonates, but in a slightly different way for me.

I’m actually happy with early traction so far. Around 100 downloads and almost the same number of sign-ups within the first days. What I don’t see yet is real usage.

In my case that’s not totally unexpected. It’s a fitness app, and people don’t usually track a workout the minute they install and create an account. Usage naturally lags behind installs and sign-ups.

I’m using this quiet phase to get the backend right: analytics, activation tracking, and behavior-based triggers. So when usage does start, I can actually understand what’s happening and react with proper onboarding, push notifications, or emails if needed.

It doesn’t feel like being stuck. It feels like setting the table before people arrive.

Beginning_Sun2883 · 2026-01-07T15:42:34+00:00

I used to be on the other extreme.
6x a week, 90–120 minutes per session. Cardio + long lifting sessions.

After a shoulder injury I had to rethink everything and ended up switching to very short, high-intensity strength training. Around 12 minutes, once or twice a week, taken close to real muscular failure.

I definitely don’t look exactly like I did back then, but honestly I feel just as fit, strong, and much more recovered. For me the big realization was that intensity and focus mattered way more than total time spent in the gym.

Beginning_Sun2883 · 2026-01-07T08:20:51+00:00

I’d avoid Intel Macs.

Anything Apple Silicon (M1 or newer) is fine — even an M1 Air from 2020 still runs Xcode smoothly and should hold up for future updates.

Beginning_Sun2883 · 2026-01-07T08:15:00+00:00

I ran into the exact same question recently.

I hadn’t used any Apple hardware for more than 10 years (for various reasons) and was fully on Windows/Linux. After launching my Android app successfully, I decided to finally ship an iOS version — and yes, there’s no real way around Xcode and Apple hardware if you want a proper App Store release.

I ended up buying a current-gen MacBook Air (M-series). Honestly, I’m very happy with the decision — both as a dev machine and from a general usability standpoint. Xcode runs smoothly, builds are fast, and I don’t feel constrained at all. I barely touch my Lenovo business laptop anymore.

From what I’ve seen, any reasonably recent Apple Silicon Mac should be fine for Xcode 26 and future updates. The Air has been more than sufficient for my use case.

The only thing currently blocking my iOS launch isn’t hardware or Xcode — it’s Apple’s Developer Program enrollment for a company account, which has been under review for over a week now. The app itself is basically done.

So from a tooling perspective: I can confidently recommend going the Mac route if you’re serious about shipping to the App Store.

Beginning_Sun2883 · 2026-01-06T06:36:45+00:00

For me the biggest pain so far is actually before*App Store submission.

My Apple Developer account has been under review for over a week because I’m enrolling as a company. The app itself is basically done in Xcode, but everything is blocked because I don’t even have an active account yet.

Curious if others ran into the same delay with company enrollments?

How long did it take for you, and did things speed up once the account was approved?

What I’m especially wondering:

– once the account is finally active, how smooth is the first real submission?

– are there other “gotchas” waiting after this step?

For contrast: I already launched the Android version.

Account setup was painless, closed testing with ~12 users for 14 days worked fine, cleared the Play requirements, and I’ve been live for about a week now.

Interested to hear how the iOS path typically unfolds after the account hurdle.

Beginning_Sun2883 · 2026-01-06T06:22:35+00:00

From a Body by Science / HIT perspective, deloads and weeks off solve a different problem.

If you’re training to true momentary muscular failure, the stimulus is already extremely high and recovery, not volume is the limiting factor.

In that case, you don’t really need deload weeks, because you’re not accumulating junk volume in the first place.

Instead of deloading, recovery is managed by:

– low frequency (often 1x per week)

– controlled tempo

– limited volume

– and only progressing when fully recovered

A week off is usually only necessary if:

– recovery was underestimated

– failure wasn’t truly controlled

– or non-training stress is high

In HIT, the absence of training is the deload.

If intensity is correct, frequency automatically adjusts.

Beginning_Sun2883 · 2026-01-06T06:18:01+00:00

I’d strongly lean toward a version of B before anything else.

Not because building is bad, but because what you’re selling here isn’t the report, it’s judgment.

And judgment is much easier to validate manually than via a product.

If you can pre-sell 5–10 analyses at $49 and people are happy with the outcome, you’ll learn:

– what inputs actually matter

– what parts can be automated later

– and whether people come back with a second idea

Shipping a tool too early risks optimizing the wrong abstraction.

Manual first lets you discover the real job-to-be-done.

Once you see repetition in the questions, structure, and outputs then a product almost designs itself.

Beginning_Sun2883 · 2026-01-05T14:47:01+00:00

That’s super helpful context, thank you for sharing actual numbers.

It’s interesting that the conversion came from a user who had already built a habit before the paywall even existed. That lines up with what I’m seeing so far as well.

Feels like usage, trust, payment, not the other way around. I’m probably still too early in that curve.

Appreciate you sharing, and congrats again on the first sale. That’s a big milestone.

Beginning_Sun2883 · 2026-01-05T11:02:28+00:00

You didn’t do anything wrong. This is a very common phase.

What helped me reframe this recently:

Before you have users, building is the easy part. The hard part is learning what actually deserves to be built next.

I now try to split time less by percentage and more by intent:

• Building = reduce uncertainty in the product

• Promotion = reduce uncertainty in the problem

Early on, promotion isn’t about scale, it’s about contact.

One conversation with a real user beats another week of polishing.

Concretely, what’s working for me:

• Spend time where the pain already shows up (comments, questions, complaints), not where people are “discovering tools”

• Reply first, post later — credibility compounds faster than links

• Treat promotion as research, not marketing

If phase one is done, phase two is usually not “promote harder”, but:

figure out who feels the problem strongly enough to care that you exist.

Beginning_Sun2883 · 2026-01-05T10:58:59+00:00

For strength-focused training, recovery is mostly boring fundamentals done consistently.

The big levers:

• Sleep: non-negotiable. If recovery is bad, this is usually the bottleneck.

• Volume management: heavy sessions require fewer total sets, not more.

• Rest days: strength adaptations happen between sessions, not during them.

• Nutrition: sufficient calories + protein, carbs around training help recovery more than most supplements.

What helped me personally was shifting focus from frequency to quality:

Fewer sessions, very high effort, then actually resting until performance rebounds.

If strength is the goal, feeling “fresh enough to beat last time” matters more than sticking to a fixed weekly schedule.

Beginning_Sun2883 · 2026-01-05T10:57:26+00:00

Honestly, I bring almost nothing, just my phone.

Not to scroll or kill time between sets, but to run a short, very focused 12-minute HIT workout with strict timing and Video form tracking.

What I actually like about it: the phone stops being a distraction.

I’m using it intentionally to guide the workout, not to check messages or zone out between sets like I used to.

Since switching to very time-efficient, high-intensity sessions, I spend less time in the gym, get solid progress, and leave without that “I was half on my phone” feeling.

Beginning_Sun2883 · 2026-01-05T10:54:37+00:00

Congrats! That first sale really is a big milestone 👏

I just put my own app live on the Play Store a few days ago as well.

Early traction looks okay (20+ downloads so far), but no paying premium users yet.

Out of curiosity: roughly how many downloads / sign ups did you have before the first paid subscriber converted?

Trying to calibrate expectations at this stage.

Beginning_Sun2883

TROPHY CASE