u/Business_Evidence982

Short version: I had access to social accounts with real audiences and assumed that was a head start. It was worth almost nothing, and I have the side by side numbers.

My app went live three days ago. Paid consumer product, $9.99/month, one free run before you pay, no card up front.

The accounts I borrowed from are all mine, but they are about other things. Dashcam and trucking video, a Spanish gossip account, a couple of paranormal channels. Between them a few thousand followers and subscribers. The plan was the obvious one: post the app there, get a head start, skip the cold start.

Same day, same posting tool, same person clicking publish:

• Dashcam clip on one of the Instagram accounts: 4,447 views.
• My app's best ever post, on a sibling account: 52 views, 3 likes, reach 42.
• YouTube channel with 2,920 subscribers, app video: 1 view after 21 hours.
• Brand new TikTok made specifically for the app, 0 followers, nothing posted before: 22 views in the first 2.5 hours.

So the zero follower account beat the 2,920 subscriber account by 22x on the same content.

Then, and this is the part I only checked this morning, the new account flatlined. Still 22 views 14 hours later. It got one small test push and then nothing. So I am not claiming the new account is working either. I am claiming the old ones are worse than nothing.

What I think is going on, and I am open to being wrong: follower count was never the asset, topic match was. An account the algorithm has learned means trucking gets shown to people who want trucking. When it posts a fitness app, distribution does not fall back to its follower count, it collapses to near zero. The followers are permission to reach an audience about one specific thing, and that permission does not transfer.

The numbers that actually matter, since view counts are not revenue:

Three days live, roughly 2,000 impressions across everything, 8 rows in my users table. As far as I can tell 4 of those are mine: three throwaway addresses from launch night when I was testing my own free tier abuse fix, plus my own account. So four strangers. All four confirmed their email and logged in. Two of them completed a run. Zero have paid.

I spent most of those three days on engineering. A double charge caused by a double click. A service worker cache that evicted my own app shell so the installed app cold started to an offline screen. A rate limit I had put above the auth check, so it could have blocked paying customers on shared IPs. All real, all worth fixing, none of them the reason there is no revenue. There is no revenue because four people have tried it.

Two things I would tell anyone about to do the same:

Do not count an existing audience as distribution unless it is an audience for the thing you are launching. Mine was worth less than an empty account, and I would have been better off spending that time making the empty account post twice a day.

If you check one number in your first week, make it how many strangers reached your core action, not how many signed up. Mine are four and two. That is a small enough sample that I cannot conclude anything about the product yet, which is itself the finding. It took me three days to stop mistaking activity for progress.

Happy to answer anything about the numbers or how I got them.

Disclosure as required by rule 3: I am the solo founder of the product these numbers come from, FlexScan, at flexscan.app. That is the only mention and the only link in this post, and I am not asking anyone here to sign up.

flexscan.app - runs in the browser on any phone, no install, no app store. Tested mostly on iPhone Safari and Chrome desktop.

What it does: upload 3 photos (front, side, back). GPT-4o vision grades 8 muscle groups A+ to D. If a group isn't clearly visible it returns "not visible" instead of inventing a grade, and you can grade that one yourself. Then it builds a 7 day workout around the weakest groups, filtered by the equipment you have and any injuries you list, with a demo on every exercise. Meal plan with calories and macros on top.

What I actually want tested:

1. Try to make it flatter you. Bad lighting, baggy shirt, weird angle, only one photo. Does it hand out grades it shouldn't be able to see? That's the thing I care most about and the thing I'd most like to be proven wrong on.

2. Put a real injury in during setup (knees, lower back) and check the plan respects it. There is no fallback that quietly relaxes it, so a squat variation on a knee injury is a bug, tell me.

3. Android. I've tested iPhone far more than Android and I know that's a blind spot.

4. Break the onboarding. Wrong units, absurd height, back button halfway, reload mid flow.

Getting in: sign up with a real email (needs confirming), first scan is free and takes no card. After that it's $9.99/mo, saying it up front so nobody feels tricked. No discount codes, I don't do them.

Privacy: photos go to the model and are never stored, only the text grades are saved. Deleting the account wipes everything, from settings.

Context: solo, not a developer, shipped 3 days ago. 4 real users and 0 paying so far, so I'd rather find what's broken now than after I spend money sending people at it. Not medical advice, it's a coaching opinion on muscle development.

I'll answer everything in the comments.

Web app only, so I think this is on topic. FlexScan: you upload 3 photos, GPT-4o vision grades each muscle group A+ to D, and it builds a 7 day workout around whatever came out weakest. Runs in a browser tab on any phone, installable, no app store.

I went PWA because I'm one non-technical person and there was no way I was surviving two native codebases plus a review queue. Two days live now. What that decision actually cost me:

1. The service worker cache is a loaded gun pointed at your own app. I had one cache with oldest-first eviction once it hit a size cap. My app shell files were the oldest thing in there, so they were the first thing evicted, and the installed app cold started to "You're offline". A native app gets its bundle managed for it and this failure mode doesn't exist. Fix was three separate budgets inside one cache instead of one global cap.

2. Cache versioning is manual and nothing warns you when you get it wrong. The only thing that clears my pinned shell cache is a version string I bump by hand in sw.js. Miss it on a deploy and every dead JS and CSS chunk stays pinned on people's phones indefinitely, and they are quietly running old code with no signal that anything is off. That should be generated at build time. Mine still isn't.

3. "Install" is not a concept normal users have. There is no button that means what the App Store button means. On iOS it's a share sheet item a few taps deep that nobody goes looking for. I have almost no users yet so I'm not going to pretend I have conversion numbers, but everyone I've actually watched try it just used it in the tab and never installed it.

What it bought, and why I'd do it again: I push a fix and everyone has it on next load. No review queue, no version fragmentation, no users stuck three releases back, one codebase, and nobody taking 30% of a $9.99/mo subscription. For a solo person that tradeoff isn't close.

First scan is free with no card if anyone wants to poke holes in it: flexscan.app. Photos are processed in memory and never stored, and the output is a coaching opinion, not medical advice.

Happy to go deeper on any of the service worker stuff, that's where all the real pain was.

Posting this because it took me embarrassingly long to find and it's the kind of thing that only bites installed PWAs.

Setup: fitness app, standalone display, service worker precaches the seven app shells at install, then caches things at runtime. Runtime cache had one cap, evicting oldest-first. Textbook.

The bug: after a long session of using the app normally, a cold start would land straight on my offline fallback page, with a full cache and a working connection. Reloading fixed it. It never happened on a fresh install, which is exactly the tell.

Why it happened: Cache.keys() returns insertion order. The shells go in first, at install. So they are permanently the oldest entries in the cache. Every workout day pulls down demo images for the exercises, maybe 50 of them in a normal week, and each one pushed the cap over and deleted the oldest entry. Which was always a shell. Browse enough workouts and the eviction walks straight through all seven shells one by one, in order. Then the next cold start has no cached navigation to serve, and the offline HTML is what's left.

So the cache was doing precisely what I told it to. My eviction policy quietly outranked my precache.

What I changed:

1. Three separate budgets inside the one cache, keyed by what the entry is: navigations (24), demo images (60), everything else JS/CSS/fonts (80). Trim runs per bucket, oldest-first within a bucket only. Images can now only evict other images.
2. The install list is a pinned bucket the trimmer never considers at all, since those are exactly the routes the offline fallback looks up.
3. Shell-referenced JS and CSS moved into their own cache that the trimmer doesn't touch. Same failure one level down: a cached navigation that renders a blank screen because its bundle got evicted is arguably worse than the offline page, because it looks like your app is broken rather than offline.
4. Install uses per-asset puts instead of addAll, so one flaky route can't fail the whole install and leave someone with no offline support at all while reporting success.

Takeaway I'd give my past self: a precache and an LRU in the same cache are in direct conflict, and insertion order means the LRU wins every time. Bucket by role, or keep them in separate caches.

App is flexscan.app if the context matters, a physique-scan and workout thing, launched two days ago. Happy to paste the trim function if anyone wants it. Curious whether people here separate caches by role from the start or also learned this the hard way.

FlexScan (flexscan.app). It runs in the browser on any phone, no app store and no install, though you can add it to your home screen if you want.

What it does: you upload 3 photos, and GPT-4o vision grades eight muscle groups A+ to D the way a coach would. If a group isn't clearly visible in your photos it returns "not visible" instead of inventing a grade, and you can self-grade those yourself. From that it builds a 7-day workout around your weakest groups, filtered by the equipment you actually own and any injuries you list, with a demo for every exercise, a swap button and a plate calculator. There's also a meal plan with calories and macros, food photo logging and a barcode scanner.

What I actually want tested:

1. Does the grading feel honest, or does it flatter you? That's the part I care most about.
2. Does the "not visible" behaviour trigger for you, or does it grade something it clearly can't see?
3. Does the workout respect the injuries and equipment you selected? There is deliberately no fallback that quietly ignores an injury, so if you see one that's a bug.
4. Anything broken on your phone, Android especially. I have tested that far less than iOS.

Straight about the money and the limits: the first scan is free and never asks for a card, but you do have to confirm an email address. After that it's $9.99/mo or $79.99/yr, cancel anytime. I don't do discount codes, so please don't ask. Photos are processed in memory and never stored anywhere. And it's a coaching opinion, not medical advice.

Solo founder, non-technical, first real product. Blunt is more useful to me than nice.