FitFlix

A gym-goer in Vilnius who wants variety needs an account with every studio they use. Studios on the other side of that want their timetable full, and a customer who only ever books one class is not worth building a booking system for.

FitFlix is the marketplace in between. One account, many studios, credits that work everywhere. I built it, I run it, and I onboarded the studios on it myself: Mindloom, Oro Yoga Loftas, Pilateson, Unity Fitness.

• Four kinds of user with genuinely different needs: people booking, studios managing their timetable, admins, and me.
• Real money moves. A booking takes payment from a customer and owes a payout to a studio, and those two numbers are not the same.
• Lithuania, so everything ships in English and Lithuanian from day one.
• No team. Every hour spent on infrastructure is an hour not spent on the product, so the architecture had to be boring on purpose.

The product is five Next.js applications (marketing, booking, studio, admin, auth) sharing six packages, against a single NestJS API. Separate apps because a studio owner and a customer want different things on screen and I did not want one codebase full of role checks. Shared packages because I only want to write the design system, the API client and the types once.

Sign-in happens in one place. Moving between apps uses a single-use handoff token: the auth app mints it, the destination app redeems it exactly once and drops it. Short lived, not replayable, and it keeps session state in one service instead of four.

Every amount is stored in cents, as an integer. No floats anywhere near a price. That decision is standard for a reason: it stops you finding a rounding error in a payout six months later.

Each booking carries two prices: what the customer paid and what the studio is owed. They differ by the commission, and keeping them as separate stored values (rather than deriving the payout at reporting time) means a change to commission never rewrites history. Revolut handles the payment, Resend handles the receipt.

Running this alone means the interesting events have to come to me. A grammY bot posts bookings, cancellations and payment failures into a channel, and takes a few commands back. It replaced the admin dashboard I would otherwise have had to build, and it means I find out about a failed payment on my phone rather than the next time I look at a database.

The schema is 1,471 lines across 58 migrations, all of them applied to a live database with real data in it. That makes you write the migration that can run while people are using the thing.

• Live at fitflix.lt with studios onboarded. Public booking has not opened yet.
• Five applications in production plus the API, 797 backend and 1,001 web commits, 154 spec files.
• Full English and Lithuanian translation, including transactional email.
• A public demo repository at github.com/Rorrschach/fitflix-v1, with a SECURITY.md that explains what was removed from it and why.

Fifty-eight migrations against a live database is the honest record of a schema I did not think hard enough about before launch. Most are small. The ones that hurt are the ones that moved live data, and they clustered around money, which is exactly where you least want to be reshaping tables in production. The worst single one renamed the money columns to integer cents on a database that was already running.

If I started again I would spend a week on the payment and payout model before writing a single endpoint. Everything else in the product tolerated being wrong for a while and getting fixed. That part did not.