Tokens, Reps, and Roadmaps: Can Open Source Build a Better Gym?

In The New Bottleneck: You, I wrote about building FitApp in a weekend using AI. The tl;dr: AI didn't remove the bottleneck — it moved it. The new bottleneck is you: your ability to direct, evaluate, and continuously feed the system.

That post was about what one person can do with AI. This one is about a different question: what happens when it's not just one person?

---

The Weekend Is Over. Now What?

I built FitApp to solve a real problem — the communication loop between me, my trainer, and my workout data. It works. It's live. I use it.

But I also know exactly where it breaks down:

• The coach view needs serious work
• Analytics are minimal — I log everything but surface almost none of it
• The sharing flow is clunky for trainers who work with multiple clients
• Revenue sharing between coaches and the platform doesn't exist yet

None of these are AI problems. They're product problems. And I could build them — but I'm one person, with consulting work and other projects. The queue is long.

So I did something that felt a little crazy: I opened the source code.

FitApp is now AGPL-3.0 on GitHub. And I'm still figuring out what that means.

---

What Open Source Actually Changes

Here's the thing about open source that I keep coming back to: it's not just about free code. It's about decentralized decision-making.

When I'm the only one on the roadmap, I decide what gets built. My priorities, my blind spots, my bandwidth. But what if a coach who uses FitApp cares deeply about sharing? They could build that. What if a strength-and-conditioning nerd wants better analytics? They could contribute that. What if someone wants to fork the whole UI for powerlifters while someone else optimizes the flow for yoga?

The protocol layer — Firebase, Stripe billing, the MCP integration — can stay shared. The ideas that get explored don't have to be mine.

This is what I mean by decentralized token consumption. With AI, "tokens" are literally the currency of building. A contributor who can prompt effectively, who has opinions about a feature, who is willing to bring their own compute to a problem they care about — that's real leverage. You don't need to be a full-time engineer to move a roadmap.

The question is whether that model actually works.

---

Flexible Pathfinding Instead of a Fixed Roadmap

Traditional product development has one team making all the UX calls. They pick a direction, execute it, ship it, and watch what happens. Then they pick the next direction.

What an open protocol enables is something different: multiple paths explored in parallel.

Maybe someone builds a powerlifting variant of the session UI that's table-heavy and rep-max focused. Maybe someone else builds a minimalist yoga version that strips out sets and reps entirely. The Firebase schema underneath stays the same. The auth stays the same. The AI integration stays the same. The UX layer diverges — and the best ideas get merged back.

This isn't theoretical. It's how good open source projects evolve. The difference here is that AI lowers the contribution floor dramatically. You don't need to deep-dive the whole codebase. You need to understand your corner, prompt well, and submit a PR.

I don't know which direction FitApp should go next. Honestly, I'd rather see what people who actually use it think it should be.

---

The Hard Problems Ahead

I want to be honest about what's actually hard here, because the weekend build story can make it sound easy. It's not.

Performance at scale is unsolved. FitApp works great for me and a handful of people. Firebase's real-time architecture is excellent for small datasets and live updates. It becomes a different conversation at thousands of users with millions of workout entries. Pagination, indexing, cold reads — none of that is done.

Coach marketplace revenue sharing is thorny. If a coach builds their practice on FitApp and it grows, what do they owe the platform? What does the platform owe them? This isn't a technical problem — it's a business model problem. And the answer has to exist before anyone's going to bring serious clients onto it.

Contributor compensation is the most interesting and most unresolved. If someone builds a feature that significantly improves the product — and that improvement drives growth — is there a mechanism to recognize that? In a traditional company, the answer is equity or salary. In open source, the answer is usually... nothing. And that's part of why open source burns out maintainers.

These are problems that benefit from more minds, not just more tokens.

---

Is This a DAO? Honest Answer: I Don't Know

I've been reading about models that try to solve the contributor compensation problem. tea.xyz is building a protocol that rewrites open source incentives at the package level. Drips Protocol lets you stream money to the software you depend on. Open Collective gives projects a transparent fiscal container without requiring a legal entity.

None of these are perfect fits for what FitApp is. But they're pointing at something real: the old model of "use open source, give nothing back" is breaking down, and people are experimenting with what comes next.

So here's the honest question I'm sitting with: if you have tokens — AI tokens, development time, product thinking — and you want a better fitness tracking experience, could you contribute to the roadmap and share in the outcome?

I don't have a clean answer. I'm not announcing a token. I'm not pitching a DAO. I'm just asking the question out loud because I think it's worth asking, and because the people who should be part of the answer are the people who would actually use the product.

There's a version of this where contributors are recognized. Where the coaches who build their practice on FitApp have a stake in its direction. Where someone who ships a killer analytics feature gets something more than a thank-you in the changelog. I don't know what that structure looks like yet. But I don't think the traditional VC-backed startup model is the right one, and I don't think "pure open source, no economics" is either.

I'm learning in public. That's the most honest framing I have.

---

What I'm Actually Asking For

If any of this resonates:

Check out the repo on GitHub and read the CONTRIBUTING.md. The codebase is Flutter + Firebase + Claude's MCP integration. The issues list has real problems, not placeholder tickets.

If you're a coach who uses fitness apps and has opinions about what they get wrong — I want to hear it.

If you're a developer who's curious about the AI-assisted contribution model — try it. Pick something small. See how much you can move with a few focused hours.

If you're someone thinking about open source economics, contributor incentives, or decentralized product development — I'd genuinely like to talk.

The app exists. The code is open. The problems are real. The question is who shows up.

---

Nick Stoddart is a fractional CTO who helps companies build and ship AI-integrated software. He writes about the practical, unresolved edge of building with AI — not the polished version, but the version with open questions. FitApp is his current experiment.