What 6 weeks of shipping FitForge in public actually looked like
I shipped FitForge — a fitness tracking app that adapts workouts and
macros to your training day. Free forever tier, $9/mo Pro. Solo dev.
Six weeks from idea to launch. Here is what those six weeks actually
looked like.
The first thing I built was the daily-view screen. Not the auth flow,
not the marketing pages, not even the workouts table. The thing a
real person would open first thing in the morning. That choice set
the tone for the rest of the project: every decision got filtered
through "would I want to look at this on a Monday?" Anything that
wasn't a yes got cut. About a third of what I planned never shipped.
The thing that almost killed the launch was the auto-deload algorithm.
When a user stalls on a lift for three weeks, the app is supposed to
drop the weight 10% automatically so they can break through the
plateau. Sounds simple. Took me six days of edge cases — stalls
during deload weeks, body-weight variations, travel weeks where gym
access was inconsistent. The first working version was less clever
than I planned, but it shipped.
I made the free tier the whole product. That's the bet. Most apps
in this category lock the useful features behind $9/mo. FitForge has
50 workouts, 30 meal days, macro tracking that rotates by training
day, and CSV export all free. Anyone who needs more can pay. Anyone
who doesn't can stay forever. This terrified me for the first month.
Turns out it was the right call — every person who's stuck around
for more than a week mentions the free tier when they email.
What I'd do differently: less copy in the launch screenshots, more
screenshot variety, less time on Product Hunt screenshot prep. The
screenshots I have aren't bad, but a one-day session would have made
them a lot better, and I spent a week.
Where I am now: ~0 active users. Learning in public. The blog got four
posts up this week. IndieHackers cross-posts are landing on warmer
threads than I expected. The free-tier message is what hooks people
— every startup advice I've gotten in the last month has been some
version of "have you tried letting people use the product?" Yes.
It works.
If you want to peek at the build, it's at fitforgehq.com. No email
required for the free tier.
I appreciate how much detail you put into these threads, it's rare that someone actually explains the reasoning instead of just the result. I'm building something too, an AI executive chief of staff for founders who are carrying too much operational context themselves. Since you've been generous with feedback here, I'd value your honest read on it if you're up for a quick look.
Thanks. Yeah, I can take a look. Drop the link in-thread and I'll give it an honest read. Caveat: my strong side is build and launch, not the AI architecture. If that's what you need eyes on, useful. If it's the AI modeling, less so.
Fair enough, that split makes sense. For FounderFlow there is no public link yet, I am still onboarding people one at a time so I can walk each person through it directly. A short live look would work well, or if you prefer written, I can send more over to hello@founderflowhq.ai whenever suits you.
Written works better for me honestly — same reason as with everyone else, I read better than I listen. Send what you've got to hello@fitforgehq.com and I'll reply in-thread here with notes. Or we can keep it in DMs if that's easier.
Here's the real version instead of making you wait on an email. FounderFlow is your AI Executive Chief of Staff. It watches your business, identifies what matters, protects your revenue, and tells you exactly what to do next. Concretely for me that means it catches the quiet stuff, a client gone quiet, a task nobody moved on, a number drifting the wrong way, and tells me what to do about it instead of just pinging me. Would love your take on whether that framing lands from a founder outside my exact audience. Happy to send more over to hello@founderflowhq.ai too if you want the deeper version.
Thanks for the reply, but I run my own ops/follow-up setup already — not the right fit on my end. Best of luck with FounderFlow though, sounds like it solves a real problem for founders without a system.
Makes sense, no need to switch something that already works. Appreciate you taking the time to look and give honest feedback either way. Good luck with FitForge.
I appreciated the honesty of this.
In particular, the first version’s not being as clever as you originally planned.
This is usually what real progress looks like but nobody talks about it.
Yeah, that's the part I wish more founders talked about ,The clever version lived on a whiteboard for two days. The shipped version was 30 lines that survived 100 lift session without complaint. Boring wins.
The free tier inversion you made here is the real differentiator. Most fitness apps use free as bait - show you 30% of value, lock the rest behind $9/mo. You flipped the model entirely: free is the whole product. That changes what signals you get when someone chooses to upgrade. When someone pays, it's not because they can finally access features - it's because they actively want to support what you built. That's the adoption signal that actually matters. The noise is stripped out. Five people willing to pay for a tool they can use for free teaches you more about product-market fit than 500 signups behind a paywall. This also explains why the auto-deload algorithm mattered so much - those edge cases expose where your model actually breaks. You can't ship "good enough" when everything is free tier. The testing has to be real. Six days for an algorithm sounds long until you realize that's where you earn the right to ask for money later.
The interesting part of building FitForge in public is that the journey itself creates attention — but the next challenge is turning that attention into a clear reason someone decides to try it.
Fitness is a crowded space, and users usually don’t wake up looking for another app. They’re looking for a specific outcome: staying consistent, seeing progress, or finally sticking with a routine.
The opportunity I’d be watching closely is how quickly a new visitor understands what makes FitForge the obvious choice for that person’s specific struggle.
The product story gets people curious; the positioning is what turns curiosity into users.
Appreciate you reading it.Yeah, the positioning question is real. That's the next
chapter — figuring out which specific struggle to lead with
so the choice is obvious instead of clever.
Curious what you build — is the consultant lens from working
with founders directly, or more of a content/strategy angle?
Great question. It comes from working through the messaging side with founders — looking at why a product that is genuinely useful can still struggle to convert visitors into users.
A pattern I see often is that founders build from the inside out: they know every feature and every reason the product is valuable. But a new visitor is deciding from the outside in: “Is this for my exact problem, and why should I care now?”
That gap between product value and user perception is where I focus — helping SaaS and digital products clarify positioning, messaging, and conversion flow.
For FitForge, I’d be curious to test a few different “entry points” around the strongest user struggle rather than trying to speak to everyone. Sometimes the winning message is hidden in the audience’s pain, not the product’s feature set.
The inside-out vs outside-in frame is sharp. Most of the
posts I see from solo founders fall into exactly that trap.
Where I'd push back: I think FitForge's positioning is
actually OK now. The bigger problem is distribution —
AI tools (ChatGPT, Perplexity) don't recommend FitForge
when buyers ask "best workout tracker." Recent audit
showed it doesn't appear in any of the AI-cited sources.
The message isn't hidden, it's just never seen.
That makes "test entry points" useful, but the test I'd
run first is whether FitForge shows up at all when the
ICP asks the question. Different problem, different fix.
What's the entry point test you'd run first?
One thing I'd like to validate is whether visitors understand the cost of not using FitForge, not just what FitForge does.
Right now the story is about adaptive workouts, macros, and a generous free tier. Those are strong features. But many people don't switch fitness apps because another app has more features—they switch because they're frustrated with something their current system keeps failing to solve.
For example:
If one of those frustrations becomes the dominant entry point, every feature starts reinforcing a single promise instead of competing for attention.
I also agree AI visibility is an important distribution problem. But once someone lands on the page, the message has to make them think, "This is exactly the app built for the problem I keep running into." That's the test I'd run first, because improving that understanding tends to lift every acquisition channel rather than just one.
The "one dominant entry point" framing is the part I want
to push on. You're right that everything should reinforce
a single promise. Wrong on which one to lead with for
FitForge.
Of the three you named, "recalculating nutrition" is the
differentiated one. Strong, Hevy, Boostcamp, MyFitnessPal
all claim "missed workouts" or "plateauing." Nobody else
automatically rotates macros by training day. If I lead
with "missed workouts," I'm Habitica. If I lead with
"rotating macros by training day," I'm the only one in
the category.
That's actually the test I want to run on the home page —
narrow the lead to one promise and see if conversion lifts.
The other two frustrations stay on the page as supporting
features, but the headline becomes the one that's
uncontested.
Will report back after I've shipped the change. Thanks
for the push on this — the framing sharpened the question.
That’s exactly the kind of test I’d want to see too.
Since you’re changing the homepage around that promise, there’s actually a useful conversion question beyond the headline itself: whether the rest of the page consistently proves that promise or starts drifting back into a generic fitness-app pitch.
That’s the part I’d be interested in auditing — headline → supporting copy → feature hierarchy → CTA → proof — because a differentiated headline can still lose its advantage if the page underneath doesn't reinforce it.
If you want a second pair of eyes before you ship it, I can do a focused homepage conversion audit and give you the specific changes I'd make rather than just general feedback.
Yeah, I'd actually want that. Two constraints so it stays useful: written only — no calls, I do my best thinking reading. And scope to the headline → supporting copy → CTA chain. The feature hierarchy and proof sections are fine where they are; the part I'm worried about is exactly what you flagged, the page drifting back into generic-pitch territory under the new headline. Send it in-thread or via DM, whichever's easier.
Perfect — that scope makes sense, and I’ll keep it exactly there.
I’ll focus on:
Written only, no call.
The focused audit is $10. You can send me the homepage link here on my email at quratulaincreatives@gmail.com
Thanks for the offer, but not looking for a paid audit right now — appreciate the context though.
"6 weeks from idea to launch — that's serious speed. I'm building Rallynex and taking longer than that, so this is motivating to read.
The 'free tier = whole product' bet is bold. How are you planning to convert free users to paid?"
The retention problem may be smaller than “build native push notifications.”
Before adding a native app, I’d test whether making the next workout explicit changes the return rate.
After someone logs a session, ask one question:
“When do you plan to train next?”
Then offer either an add-to-calendar action or a single email reminder. You could measure:
how many users choose a next date
how many return within 24 hours of that date
whether they log workouts in a second and third week
how often they ignore or reschedule the reminder
That separates “I forgot FitForge existed” from “I consciously decided not to continue.”
If users who make a commitment still do not return, reminders probably are not the main problem. If they do return, you have evidence for investing in a stronger notification layer later.
I’d also postpone the leaderboard until there is enough user density. For the first users, progress against their own previous week may feel more alive than an empty social feature.
Would you consider testing a next-workout commitment before building any native notification infrastructure?
This is the kind of thinking I came to IH hoping to find.
The commitment-gating test is exactly the shape I want
to try. Two things I'd push on:
First, "when do you plan to train next" might land wrong
right after a session — that's when people are closing the
app, not sticking around. The natural moment is probably
the night before, when they're already thinking about
tomorrow. Push notification the prior evening, ask the
question then, then calendar + reminder at the chosen time.
Second, the leaderboard-vs-self-progress point is the
stronger half of your comment and I don't want it to get
lost. You're right that empty leaderboards make the social
feature feel dead. "Did you beat last week" is the
honest version of "compare yourself to others" when n=5.
Will try the commitment-gating test. If users who commit
still don't return, the problem is the workout itself, not
the reminder. That's the data I actually need.
What are you shipping?
That timing point makes sense — the evening before may be a much more natural moment to ask for commitment than immediately after a workout.
And yes, I think “beat last week” gives you a much better early feedback loop than trying to manufacture social proof before there’s enough density.
I’m shipping SoloOps Dock — a lightweight changelog, incident/status, and in-app notice tool for solo SaaS founders.
The thing I’m validating right now is less “do founders want another status page?” and more “can one communication workflow remove the duplicated work of updating a public page, an in-app notice, and incident status separately?”
I’ve been using these IH conversations to pressure-test the workflow before adding more features.
SoloOps Dock is a sharp niche — solo SaaS founders are
exactly the people who'd pay for "one place to update all
the things."
One thing I'd flag on the IH-as-research method: the people
who answer IH threads are a self-selected sample. They're
founder-curious, public-builders, time-rich. That skews
what "validation" tells you about the broader ICP — the
non-IH-reading founder who just wants the tool to work.
Your question of "can one workflow replace three" is the
right question to pressure-test in IH though, because
that's a process question, not a discovery one. Process
questions generalize; discovery ones don't.
That’s a very useful distinction.
I agree that IH is a biased sample, so I’m treating these conversations more as workflow research than proof of market demand. The stronger validation has to come from what founders actually install, keep using, and eventually pay for — especially founders who aren’t spending time discussing their process publicly.
“Process questions generalize; discovery ones don’t” is a good rule for keeping that boundary clear.
The next gap for me is reaching that quieter group of founders without turning the whole exercise into generic cold outreach.
Have you found a good channel or approach for getting feedback from founders who build and operate products but rarely participate in communities like IH?
Honest answer: I haven't fully cracked this either. The channels that have worked for me (Quora, IH) are the same biased ones you're describing. Reddit is the next test —
I'm banned from r/fitness but planning to check the 7
reachable subs you saw me flag.
Two things that have moved the needle more than I'd
expected:
One: comparison pages. /vs/strong, /vs/hevy, /vs/myfitnesspal
— these rank for "[competitor] vs [you]" queries, which is
where the quiet ICP is actually looking. They find you
because they're already in evaluation mode.
Two: free tools. I built a TDEE calculator and a macro
calculator on the site. People share those because they're
useful, not because they're FitForge. The shared URL
brings quiet founders.
Neither is cold outreach. Both are "build the thing they
find when they go looking."
What's your next move on SoloOps Dock — same play, or
something different?
I think I’ll use the same principle, but probably a different implementation.
IH is still useful for workflow research, but I don’t want it to become my only acquisition channel.
For SoloOps Dock, my next move is to put a few things in front of founders who are already looking for a solution — pages around problems like “simple status page for an indie SaaS,” “lightweight changelog for a solo founder,” or alternatives to heavier tools — and pair those with a live demo rather than just more explanatory content.
I also like the free-tool idea, but I’d keep it very small at first. Something like an incident communication checklist or a copyable first-response template could attract the right person without turning into another product I have to maintain.
Then the useful signal is whether those quieter visitors actually create a project, publish an update, or install the widget — not whether they leave a comment.
“Build the thing they find when they go looking” is a good framing. I’m going to keep that one.
Problem-specific pages + live demo over explanatory content is the right shape — that's the part I want to try on FitForge too. The "small tool first" instinct is sharp; my TDEE calculator started as a one-shot and became the most-shared thing on the site. Smaller surface, more useful,less to maintain. "Install the widget not leave a comment" is the right signal to track. Good luck with the build.
Building the daily view screen first instead of auth is the right call and most solo devs do the opposite because auth feels like real progress and the daily view feels like something you can procrastinate on. The free tier fear you mentioned is the part I relate to most, it is strange how making the product more generous feels riskier in the moment than making it stingier, even when the numbers say otherwise. Curious what the six day auto deload algorithm looked like before you cut it down, that sounds like the part that actually taught you the edge cases.
Glad the free-tier-as-the-product thing tracks for you too —
I think more solo founders feel that anxiety than talk about it.
For the auto-deload algorithm, here's what I cut:
The first version had 4 states:
• On track (no action)
• Watch list (1 stall week — reduce volume 10%)
• Deload (2 stall weeks — reduce weight 10%)
• Plateau (3+ stall weeks — full reset)
What I cut:
• Watch list. It sounded good but created "limbo" weeks — users
saw -10% volume applied but didn't know why, then bounced.
• Plateau detection required a 3-week window but most users
hadn't logged 3 weeks of data yet, so it never fired.
The shipped version: 2 states only.
• On track (no action)
• Deload (trigger: 2 consecutive sessions at <target reps)
The deletion of "watch list" was the lesson. Adding states
felt like progress, but fewer states shipped faster and
confused fewer users. The "less but shipped" pattern
won.
What's your project? Sounds like you've felt this build-vs-burnout
thing too.
Fair question. I am building FounderFlow, for founders running service based or multi location businesses who are tracking everything by memory and spreadsheets instead of one system. It watches the business, flags what actually needs attention, and tells you what to do next instead of adding another dashboard nobody opens. Still pre launch, onboarding a small group of early members directly right now rather than a public signup. Your build vs burnout line is basically the whole reason I am building it, most founders I talk to are doing the mental math you described but for their entire business instead of one lift.
Yeah, "tells you what to do next instead of adding another
dashboard nobody opens" is the bar. Most "insight" tools are
just charts that confirm what you already suspected.
Pre-launch direct onboarding is the right call too. You're
hearing the actual objections instead of building for a
persona. I shipped free and waited for signal that never
came — your path forces the signal.
The mental-math extension is generous of you — I hadn't
thought of it that way, but yeah, that's the shape of it.
Multi-location service founders are doing that math across
ten spreadsheets. Single founder doing it for one lift is
the easy version. What's the early-member onboarding look like — paid, free,
or something else?
Free for this first group in exchange for real feedback, onboarded one on one so I can watch how people actually use it before locking in pricing. Once this cohort ships I will figure out what paid looks like, still deciding between a flat monthly rate and something tied to number of locations.
Since you already asked how the onboarding works, might be easier to just show you than keep explaining it. You're describing the same multi-location math problem FounderFlow is built around. Want to jump on a quick call so you can see how the early group is actually using it? No pressure if FitForge has all your attention right now.
The free-tier feedback is interesting, especially alongside the ~0 active users.
Of the people who were initially pulled in by “the whole product is free,” have you seen where they tend to stop using FitForge, or is that part of the behavior still mostly invisible to you?
Great question. Mostly invisible to me right now.
What I do have is a small sample (~3 people who emailed or commented
during the launch week), and the pattern is roughly: they signed up,
hit the onboarding flow, logged 2-4 workouts, then stopped. Of those,
one told me directly: "I forgot I had it open in another tab." That's
a session-streak problem, not a feature problem.
The friend group + leaderboard I built was supposed to fix exactly that
— but the chicken-and-egg of social features is you need other humans
to make it work, and 0 users means no leaderboard feels dead.
I don't have enough data to know whether the issue is:
- Onboarding friction that I can measure once I add session analytics,
- Habit-loop failure that the streak feature wasn't strong enough to fix,
- A discoverability problem (people find FitForge but don't think of
it when they go to log a workout).
My current bet is the third one. If I could wave a wand I'd add
periodic push reminders on the day they normally train, but as a solo
founder I'm not building native apps yet.
Honest answer: I don't know yet, and "I'm building in public" is mostly
"this is what I'm trying next, here's what happens."
That’s helpful context. I appreciate the honesty around what you’ve observed versus what you’re still trying to understand.
I’d like to continue the conversation outside the thread. What’s the best email to reach you on?
Happy to continue the conversation outside the thread.
Best email: hogganrobbie@hotmail.com
Always open to talking about retention math, free-tier
behavior, or anything else shipping-related. Thanks
for pushing on the hardest part of the post.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
Quick tech-stack note for anyone curious: Next.js 15 (App Router),
Supabase, Stripe, Vercel, Sentry. Boring by design. Boring ships fast.