Fitness app development case study: MorfoFit, from website to App Store
Fitness app development case study: site, subscriptions and iOS/Android app for a Pilates video platform. What I built, with dates, and what I'd change.
Short answer
This is a fitness app development case study: MorfoFit, Elena Magoula's Pilates subscription platform with a video library, built in Greece between 30 July and 22 September 2026. I built the website, the payment system and the admin panel, and I took the app into the App Store and Google Play. Every date below comes from the project files. I don't publish sales figures, because they belong to the client.
At a glance
| Client | MorfoFit, morfofit.gr |
| Duration | 30/07/2026 to 22/09/2026 |
| Work | Website, admin panel, card subscriptions, video protection, server move, iOS and Android release |
| Website | Next.js, TypeScript, custom admin |
| Backend | Node.js, Express, PostgreSQL (existing, extended) |
| App | Flutter, iOS and Android (existing, finished and released) |
| Payments | Viva Wallet on the web, Apple and Google Play in the app |
| Hosting | Docker on a dedicated server, site behind Cloudflare |
The problem
When I started on 30 July 2026, two pieces already existed, written by another developer: an Express backend on PostgreSQL and a Flutter app. The app wasn't in any store. There was no public website.
Before design or payments, I reviewed what was there. A few issues turned up in the old code, and I fixed those first.
Fitness app development: what I built
Content locked on the server
The server checks the subscription before it returns a workout, a recipe or an article. Without one, you see the title and cover, not the material. On 24 August 2026 I moved all 56 videos that existed then to encrypted HLS streaming with AES-128, with a link signed on every request. Open the file straight in a browser and the server answers 403.
A Next.js site with a library by level
The site has a training library (beginners, more advanced, pregnancy), nutrition with recipes, and psychology articles. A fourth section, a 24-chapter guide, went in on 21 September. Titles, categories and prices come from the database. The site went public on 1 September 2026 at 14:00.
An admin panel so Elena doesn't need me
Elena uploads videos, writes articles and changes page images from /admin. The editor only accepts what the app can also show, so an article looks the same on the site and on a phone. Since 3 September new material publishes itself every Tuesday at 08:00 unless she picks another time.
Card subscriptions and my own renewal engine
On the website, payment runs through Viva Wallet. Renewals, plan upgrades and refunds update access automatically. If a card fails, the subscription gets three days' grace with one charge attempt a day. Live payments opened on 14 August, after I'd tested every path with real money. I also set up Stripe as a second provider in test mode. Today only Viva charges.
One subscription, three checkouts
A subscriber can pay on the website, in the App Store or in Google Play. Every purchase lands in one table, and the server verifies each Apple and Google Play Billing receipt before it opens access. Someone who paid on the site gets into the app with the same account.
Moving off Railway
On 30 August I moved the backend and database from Railway to the dedicated server on Docker where the site already ran. The same day I ran the full path in production with a real card: buy, upgrade, cancel, refund, buy again. Everything passed.
The app in the stores
On 10 September I took over all the app work, store submission included. I added push notifications, Greek on the screens, and a paywall that shows the price the store returns. Apple approved the app on 15 September. It went public on Google Play on 22 September.
Each kind of reminder switches off on its own, so a subscriber keeps only the ones she wants. The app is in Greek.
Timeline
| Date | What happened |
|---|---|
| 30/07/2026 | Code review of backend and app, proposal |
| 31/07/2026 | Approved |
| 02/08/2026 | First fixes to the existing code |
| 03/08/2026 | First site pages running on real data |
| 05/08/2026 | Viva subscription end to end in the sandbox, with automatic renewal |
| 14/08/2026 | Live payments open |
| 24/08/2026 | Encrypted streaming on all 56 videos |
| 30/08/2026 | Backend and database off Railway, full production test |
| 01/09/2026 | Site public, 14:00 |
| 03/09/2026 | Scheduled publishing of new material |
| 10/09/2026 | Took over the app |
| 13/09/2026 | First push notification on an iPhone |
| 14/09/2026 | Apple and Google purchases verified end to end |
| 15/09/2026 | Apple approves the app |
| 17/09/2026 | Renewal engine charges a real card in production |
| 22/09/2026 | App public on Google Play |
What worked
The most useful thing I did was review the code I inherited before writing my own. Whatever was off got fixed before I built anything on top of it.
Testing with real money was worth every euro. Viva's sandbox doesn't show everything, and a real card caught problems the first customer would otherwise have found.
One table for every subscription was the right call. When Apple, Google and Viva all write to the same place, "does she have access?" has one answer.
And the admin does its job: material goes up and gets scheduled without anyone calling me.
What I'd do differently
More checks before launch
A few issues around the site launch and the first store submission were found and fixed. Next time the site gets its own account from day one, and I read the store rules before I send the app in.
Start the store paperwork with the code
Apple verifies the developer account before it makes an app available in the EU. That step has nothing to do with code, and it took longer than all the app work. It's the part I underestimated most. Next time I start it the day the developer account opens.
An alert when something stops quietly
On 22 September I found that if the renewal engine stopped, we wouldn't know. I added a heartbeat that logs what each pass did. That belonged there from the first charge.
FAQ
How long did the build take?
33 days from the code review on 30 July 2026 to the public site on 1 September. The app went public on Google Play on 22 September.
Do you need an app, or is a website enough?
A website is enough to start. An app adds notifications and in-app purchase, but it also brings Apple's and Google's rules and fees. Here the site shipped first and the app followed.
Why Viva Wallet and not just Stripe?
Viva is Greek and takes the cards and Apple Pay that subscribers here use. Stripe is in the code as a second provider, switched off, in case it's needed.
Can someone share the videos?
Not easily. Each video plays over an encrypted stream, and the link is signed with the token of the account that asked for it. The file won't open straight in a browser.
Summary
MorfoFit, a Pilates subscription platform with a video library: a Next.js website, Viva Wallet, Apple and Google Play payments, and a Flutter app for iOS and Android, by Panagiotis Karampetsos. The site went public on 1 September 2026 and the app on Google Play on 22 September 2026.
If you're thinking about something similar for your own material, tell me what you have today. More builds are on the portfolio page, and the blog has the write-ups. For how the video streaming works, see Apple's HTTP Live Streaming documentation.