Fitwave

• 

Inspiration

The idea for Fitwave didn't start with a business plan. It started with a Pilates class. A year ago, I joined an online Pilates program. The instructor had her own branded platform, and every detail felt calm and elegant. It felt like I had stepped into her world.

Later, I discovered that she paid almost 100,000 euros to build it.

A couple of months ago after training I wonder: "Why should that level of quality be reserved for only a few? Why should only trainers with large budgets be able to create a premium experience that truly reflects their brand?"

Many trainers are still sending clients from one platform to another, sharing video links, using outdated websites, or relying on tools that looked more like bodybuilding apps than the premium wellness experience they want to deliver.

And I realized something. People don't just buy workouts. They buy the experience. Because the way people feel while using a product is part of the product itself. This is what FitWave is about... not to build just another fitness platform. But to make premium wellness experiences accessible to every trainer. Premium digital experiences shouldn't be a luxury

What it does

FitWave gives fitness trainers the infrastructure to launch their own premium fitness webapp: branded pages, structured programs, subscriptions, progress tracking, and protected video content, without building a custom app from scratch

How we built it

When I started this journey, I was not an experienced software engineer.

To be completely honest, I did not even know what “mock data” meant.

Over the following two months, I worked alongside ChatGPT and Codex to turn the idea into a real full-stack product. I learned how to break a large problem into smaller systems, inspect an existing codebase, question architectural decisions and rebuild parts that were not good enough.

FitWave now includes a React and TypeScript frontend, a FastAPI backend, PostgreSQL through Supabase, authentication, subscriptions, trainer and client flows, progress tracking, protected media delivery, and a separate video-processing worker that generates HLS streams and thumbnails.

What we learned

One of my biggest lessons was the power of abstraction.

My first backend design contained too many repetitive tables and duplicated concepts. It technically worked, but it was becoming difficult to maintain and would have required unnecessary database queries.

So I rebuilt the backend.

That process taught me how to design cleaner data structures, reduce duplicated logic, make Supabase tables more efficient, and think about the entire flow before adding another endpoint or table.

Challenges we ran into

One of the hardest challenge (apart from rebuilding the backend and fixing all the bugs that surfaced afterward) was separating what the trainer is editing from what the client is allowed to see.

A trainer needs to update a program privately without changing the client experience immediately. But once the program is published again, clients should receive the new version while keeping the progress they have already completed.

Supporting drafts, publishing, and republishing required separate trainer and client data flows, careful API boundaries, and changes across both the frontend and backend.

Video processing was another challenge, and honestly a small nightmare. I had no idea video streaming could involve so many moving parts. Uploads, processing states, a separate worker, ffmpeg, HLS generation, thumbnails, storage, and protected playback and other things all had to work together in the right order.

There were also many many moments when fixing one issue revealed three others. I have learned that this is apparently a feature of software development.

Accomplishments that we're proud of

I’m proud that I turned an idea I once thought was far beyond my technical abilities into a real full-stack product. I rebuilt the backend, designed trainer and client flows, integrated subscriptions and video processing . I’m most proud that I learned how to make architecture decisions myself, instead of simply giving Codex large prompts and letting it work without understanding the result. I also learned to break problems into smaller steps, inspect the code, question decisions, and use AI as a technical partner, not as a replacement for thinking.

What's next for Fitwave

Next, I’ll finish the webapp translation, review every core flow once more, and begin testing FitWave with the first trainers and clients. Their feedback will shape the next iterations before an international launch. I truly believe in this project

Built With

• cloudflare-r2
• cloudflare-workers
• docker
• fastapi
• ffmpeg
• hls
• node.js
• postgresql
• python
• react
• redis
• sqlalchemy
• stripe
• supabase
• tanstackquery
• typescript
• vite