FitForge: first real users, a database wipe, and a Jan launch date
Two things happened this week.
- FitForge has its first real users. I was digging through Clarity session recordings on Tuesday and found two signups I didn't know and didn't make. Both signed up Sept 13. One of them has come back three times and is actually using the app, hitting /today and /progress like a person who intends to keep going. My total marketing spend to get them: $0. I'd tell you exactly where they came from, but honestly I can't say for sure, which is a lesson in itself about analytics attribution.
This is the first time in ~3 weeks of building that FitForge has users I didn't personally beg. I sent both a short founder email asking what they used before and what confused them. No replies yet, but it's been a day.
- The site had a real risk and it's fixed. I ran a full audit this week: every page, SSL, forms, 404s, JS errors. Everything passed except two things: my email addresses had a hole (one address silently dropped mail), and there was an admin link visible in the footer. Both fixed, plus nightly database backups are now running, which matters because earlier this month a cleanup script wiped my entire user table and I had no backups. That was the worst day of the project so far. Now it can't happen the same way twice.
What's next: FitForge is confirmed to launch on Smol Launch on Jan 4, 2027, and it's in the queue on a couple of other directories. Between now and then the job is turning these first two users into actual retained lifters and doing 5 user interviews.
If you lift and your current setup means one app for workouts and a different one for macros:
https://fitforgehq.com/?utm_source=indiehackers&utm_medium=thread
update: shipped a new post today — why i built FitForge after watching lifters run Hevy and MacroFactor side by side. full disclosure: i never used the two apps myself. i found the gap in other people's workflows, not my own. https://fitforgehq.com/blog/hevy-macrofactor-alternative?utm_source=indiehackers&utm_medium=thread
The repeat user is the strongest signal here. Do you see anything they’re doing differently from the other signup that might explain the early retention?
Honest answer: not conclusively yet. What the session recordings show: the repeat user keeps coming back to /today and /progress — the daily check-in pages — while the other signup did one session and never returned. What I can't see yet is whether that turns into a logged workout, which is the activation event I actually care about. Working theory: they arrived already knowing what problem they wanted solved, so onboarding was a door, not a wall. But my attribution data is thin enough that I'm calling this a hypothesis, not a conclusion. Watching whether the streak holds past week one before I say 'retained.' What's your angle — building in fitness, or living the two-app juggle?
Just sent you a note by email on this — when you get a chance, take a look there and let me know what you think.
Hasn't landed on my end yet — which address did you use? Try hello@fitforgehq.com."
Sent it to hello@fitforgehq.com just now.
I’d originally sent it to the Hotmail address you gave me when we first moved the conversation off IH, so that’s the address I used this time as well. Thanks for giving me the current one — should be in your inbox now.
The returning user is the stronger signal here. Three visits to
/todayand/progresssuggests they may already understand the intended loop, even without replying to an interview email.One thing I’d add after the database incident is a restore drill. A nightly backup proves a file was created; restoring it into a clean environment and checking users, workouts and progress proves the product can actually recover. I’d also write down how much data you can afford to lose between backups.
For those first interviews, an optional one-question prompt inside the app may work better than email: “What brought you here?” Ask while the reason is still fresh.
Update: ran the restore drill today. 8 profiles + 2 workout logs recovered in 1.44 seconds, RPO ~1 hour. Also caught a bug where RLS was silently capturing zero rows in the nightly backup — backups were empty for two days and we had no idea until the drill. This is why you test the restore, not just the backup. 🙏
That RLS bug is exactly why the restore result matters more than a green backup job.
I’d make zero rows or missing expected tables a hard failure now, then run the clean restore on a schedule rather than treating today as a one-off. One small clarification: did you increase the backup frequency from nightly to hourly to reach the one-hour RPO?
agreed on both. the check is moving from "script exits 0" to a hard failure if any expected table comes back with 0 rows a green job means nothing if the restore doesn't. and the restore drill goes on a weekly schedule rather than staying today's one-off.
on the RPO: backups are already hourly, so no frequency change was needed — the 1-hour RPO is the current backup cycle. The fix was the RLS bug that had the job silently dumping 0 rows; frequency was never the problem.
Restore drill: you're right, and I'll admit the gap. Nightly backup's automated but I've never actually restored one into a clean environment. Adding that to this week's list — if I can't get users, workouts and progress back from the backup file, it's not a backup, it's a hope. Same with the RPO: writing down how much data I can afford to lose between snapshots. Cheap insurance after paying the expensive lesson.
The one-question in-app prompt is also going in. Email's easy for me but it's clearly not where users are — the repeat user has come back three times without replying to anything. 'What brought you here?' at the moment they land makes more sense than my cold email weeks later. Thanks for both.